Every MCP server we have operated at scale eventually produces the same telemetry question: "where is all of this going and who can see it?" The answer, at first, is always worse than we would like. Prompt text ends up in APM traces. Tool arguments land in logs that a contractor can query. Response payloads are retained for ninety days because a default was never overridden. The telemetry that is supposed to help us run the service safely has become a secondary data store we never signed up to govern.
MCP telemetry is unusual because it mixes three high-sensitivity data types in a single stream: user prompts, model-generated arguments, and tool responses. Treating this stream the same way you treat web server logs is a compliance hazard. This post walks through a governance framework that has held up across several production MCP deployments.
What MCP Telemetry Actually Contains
The first exercise is enumerating what the telemetry pipeline is collecting today. For a typical MCP server, the inventory includes:
Tool invocation records — the tool name, the arguments passed, and the response returned. Arguments often contain user input and model-generated content. Responses often contain retrieved data, customer records, or the output of downstream APIs.
Protocol metadata — the invocation context identifier, client identity, tenant, server version, and timing. Usually low-sensitivity individually, but can enable re-identification when joined.
Error traces — stack traces from tool failures, which routinely include argument values, partial responses, and configuration snippets. Error traces are where high-sensitivity data most often leaks into shared observability systems because they are verbose by default.
Model interaction records — when the MCP server wraps an LLM-backed tool, the telemetry may include full prompts, completions, and embeddings. These are the highest-sensitivity items in the stream and the ones most often captured without sufficient controls.
Performance metrics — request counts, latencies, token consumption. Generally safe to aggregate and share broadly, but need tenant-scoping for per-tenant analyses.
The inventory is usually larger than expected on first pass. Build it once and keep it current; decisions downstream depend on it.
Classification Before Collection
A serviceable classification scheme for MCP telemetry has four tiers: non-sensitive (version strings, feature flags), pseudonymous (identifiers that could re-identify an entity when joined), confidential (tool arguments, responses, tenant-specific content), and restricted (prompts containing end-user data, credentials, regulated data categories).
The value of the classification is that retention, access, and redaction policies attach to tiers rather than to individual fields. When a new tool is added, the team adding it maps its telemetry to a tier and inherits the policy. No custom governance conversation per tool.
The honest failure mode here is drift. A tool that started out producing non-sensitive telemetry and later changed to return customer data needs its classification updated. We run a lightweight quarterly review where tool owners confirm their classification is still accurate. It is unglamorous and it catches real issues.
Redaction as an Active Control
Redaction is one of those controls that looks easy until you try to do it properly. Regex-based redaction catches obvious patterns (emails, credit card numbers, known API key prefixes) and misses most interesting cases. Semantic redaction — understanding that a field is "user input" and treating it as sensitive by default — is what actually works.
The pattern we use: structured logging with explicit field classification, defaulting to "redact" for any field not declared safe. A tool emits an event with {tool: "read_document", doc_id: "abc123", content: "..."} and the telemetry library applies policy at serialisation time based on field names or schema-attached metadata. Unknown fields do not pass through by default.
For free-text fields that must be logged for debugging (error messages, tool responses), we apply a second layer: pattern-based scrubbing for well-known sensitive formats (tokens, keys, PII patterns) and truncation to a bounded length. Neither is perfect. Both materially reduce the volume of sensitive data reaching shared observability backends.
A practice we strongly recommend: run the redaction pipeline's output through a sampling audit. Take a random one percent of events per week, have a human review them, and confirm that nothing embarrassing made it through. This catches bugs that automated testing misses and keeps the team honest about what is actually being logged.
Tenant-Scoped Access Controls
Telemetry access controls are often built on the assumption that operators need to see everything. That assumption breaks in multi-tenant MCP deployments where tenant data is confidential and operators are not contractually or legally entitled to browse it.
The model we have settled on separates two classes of access. Aggregate access — seeing counts, latencies, error rates without any tenant-specific content — is broadly available to engineering and operations. Tenant-scoped access — seeing the actual content of a tenant's tool calls — requires explicit authorisation tied to a specific support ticket or incident, is logged, and is time-limited.
Implementing this cleanly requires the telemetry backend to support row-level access control with a tenant dimension. Many popular observability platforms do not, out of the box. The workaround is either a two-pipeline approach (aggregate pipeline open to everyone, tenant-scoped pipeline gated) or custom query tooling in front of a single backend. Neither is free; the latter is usually cheaper long-term.
Retention That Matches Risk
Retention policy is where compliance requirements, debugging needs, and storage cost meet. For MCP telemetry, the durations that have tended to hold up:
Non-sensitive and performance metrics: thirteen months, because year-over-year comparisons are useful for capacity planning.
Pseudonymous protocol metadata: ninety days, sufficient for incident reconstruction without becoming a long-term re-identification risk.
Confidential tool arguments and responses: thirty days, with an override mechanism to retain specific records longer when needed for a known incident.
Restricted prompts and model interactions: seven to fourteen days by default, and only in redacted form. Raw prompt text should almost never be retained long-term unless there is a specific compliance-driven reason and explicit tenant consent.
The retention system has to actually delete data when retention expires. This sounds obvious and is where we most often find gaps — backups that keep data past its retention horizon, derived tables that were never added to the retention pipeline, cold storage that nobody audits. Deletion verification needs to be a recurring test, not a one-time design.
Telemetry Exports and Third-Party Sharing
MCP telemetry frequently flows to third parties: observability vendors, APM providers, data warehouses, compliance tooling. Every downstream destination is an extension of the governance surface. A sensitive field redacted in the primary backend but shipped in the raw to a third-party APM has not been redacted in any meaningful sense.
The discipline we enforce: redaction happens at the point of emission, not at the point of storage. By the time telemetry leaves the MCP server process, sensitive fields are already redacted. Downstream destinations receive already-safe data. Storage-layer redaction is a backup, not a primary control.
Data processing agreements with third parties should explicitly call out the classifications of data they receive and the retention they apply to it. Where a third party cannot honour the retention and access requirements, they should not receive the data.
Auditing and Continuous Assurance
Governance is a continuous activity, not a one-time design. The audits we run on MCP telemetry pipelines:
Quarterly classification review with tool owners, as mentioned above. Continuous redaction sampling with human review. Access log audits looking for tenant-scoped access outside of ticketed support windows. Retention verification: for each classification tier, confirm that data older than the retention horizon is genuinely gone, including from backups and derived tables.
None of this is expensive in isolation. The cumulative effect is a telemetry pipeline that remains trustworthy as the service changes around it, rather than drifting into a compliance problem.
How Safeguard Helps
Safeguard applies data governance policy across MCP server telemetry end to end, classifying tool arguments and responses against a built-in sensitivity taxonomy and enforcing redaction at the point of emission. The platform continuously audits retention, access patterns, and third-party exports, flagging drift — new tools emitting unclassified fields, tenant-scoped data flowing to shared observability, retention horizons quietly extended — before it becomes a compliance issue. Tenant-scoped telemetry access is gated through Safeguard's policy engine with full audit trails, so support workflows do not require broad operator access to sensitive content. When governance reviews are due, Safeguard generates evidence-ready reports that show exactly what is collected, how long it is retained, and who can see it.