Audit & Observability

You cannot secure what you cannot see. The Model Context Protocol provides no built-in observability — on its own, a sprawl of clients talking directly to servers offers no single place to record what AI did, with which tool, on whose behalf. Because every request flows through the MCP Manager gateway, MCP Manager is that place: it writes a structured, attributable log entry at every hop, turning otherwise invisible MCP traffic into an audit trail you can search, forward, and report on.

​

Why MCP has no audit trail without a gateway

Without a control point in the middle, every client connects to every server directly, and there is no vantage point from which to observe the traffic. A single tool call can read a customer record, export it, and trigger a workflow — all invisibly. That blind spot is exactly what makes shadow MCP dangerous: usage you can’t see is usage you can’t audit, and you cannot prove a sensitive record was never exfiltrated if nothing recorded the call. Routing all traffic through one gateway restores the central observation point the protocol leaves out.

​

What every call records

A request through the gateway is logged at each hop. Rather than repeat the full schema, here is what matters for audit; the complete column reference lives in Viewing Logs.

• The full message — the request and response headers and body are captured when available, so you can see exactly what was sent and returned.
• Identity attribution — user_name, user_email, and user_guid, plus the originating ip_address, the org_guid, and the team_guid, alongside the gateway, host, server, and the identity used for the upstream call.
• The feature involved — feature_type and feature_name (the tool, prompt, or resource), and the JSON-RPC method.
• Performance and size — duration_ms for each leg, and an estimated token_count so you can see which calls are heavy.
• Policy and governance outcomes — rule-engine activity (rule_engine_type, e.g. pass, modify, or block) and feature-governance decisions (gateway_feature_filtered, gateway_feature_blocked).
• Trace correlation — trace_id, span_id, and traceparent on every entry, so a request reconstructs as one distributed trace and each log can pivot to its span. These are minted for every request, with or without a traces collector.

​

The four-leg correlation model

A single MCP message travels four legs through the gateway, and each leg is logged as its own entry sharing one correlation_id: the client’s request arriving (proxy_request_success), the gateway’s request to the server (mcp_request_success), the server’s response back (mcp_response_success), and the gateway’s response to the client (proxy_response_success). Filtering on the correlation_id reconstructs an entire exchange end to end. See Log types and the correlation model for the full set, including the error and policy-enforcement types.

​

Attribution and non-repudiation

An audit trail is only as good as the identity behind each entry. Because the gateway brokers a specific identity on every upstream call, each log entry names the real user the call acted as — not a shared, anonymous service account. Pair a server with a per-user identity scheme and every read and write is attributable to an individual end to end: the downstream system sees the real person, and so does your log. This is what makes the record stand up as evidence rather than just telemetry.

​

Integrity, retention, and performance

• Ordering and precision. Entries are stamped with a microsecond-resolution created_at, so even rapid bursts sort deterministically and a sequence can be reconstructed exactly.
• Logging never blocks a call. Log writes happen out of the request’s critical path — a logging failure does not slow or fail the underlying MCP request. Observability is always on, but it is not a single point of failure for traffic.
• Retention is an organization-wide setting tied to your plan. How far back stored logs reach — and therefore the maximum age you can view or export — is governed by a single retention period that applies across your whole organization, not per gateway. It starts at 14 days and extends to a year or more at higher plan levels, and retention periods longer than 12 months can be configured, subject to your plan and agreement with your MCP Manager contact. (Gateway-level policy such as rules and identity schemes is configured per gateway instead.) Generated export files have their own, separate availability window. Both are surfaced in the product. For retention beyond your plan’s window — including indefinite, compliance-grade retention — forward logs to your own store (below).

​

Forwarding to your SIEM

For long-term retention, correlation with other security data, and your team’s existing tooling, MCP Manager forwards structured MCP logs — and request traces — over standard OpenTelemetry (OTLP/HTTP). Any collector that accepts OTLP works — a self-hosted OpenTelemetry Collector, or a managed backend such as Datadog, Grafana Cloud, New Relic, Honeycomb, or Splunk — as OTLP destinations rather than pre-built connectors. You set a logs collector URL, a traces collector URL (or both) and the request headers, and MCP Manager streams the records downstream; an export failure raises a deduplicated alert rather than disrupting traffic. See Export to SIEM for setup and the per-destination guides. To retain logs for any duration — for example writing them to object storage such as Amazon S3 for compliance — run your own OpenTelemetry Collector and route the logs into your store. The self-hosted Collector guide has a worked example.

​

Reporting: the security and usage lens

The Reporting page is built from the same log data, aggregated into charts: feature-call volume over time, server and tool popularity, latency percentiles, and response-code distribution. Read security-first, these surface the things worth noticing — a spike in call volume, a tool suddenly in heavy use, an unusual error rate — and point you back to the underlying logs for the per-message detail. Logs are the evidence; reporting is the lens that tells you where to look.

​

Logs as compliance evidence

Frameworks such as SOC 2 and HIPAA require attributable, reviewable records of access to sensitive systems — exactly what the gateway produces and the raw protocol cannot. MCP Manager’s logs give you that evidence layer: who did what, with which tool, under whose identity, and when, retained or forwarded to meet your obligations. MCP Manager supplies the audit trail your controls depend on; it supports your compliance program rather than replacing the program itself.

​

Further reading

​

External sources