> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Audit & Observability
> Why the MCP Manager gateway is the only place an organization can get a complete MCP audit trail, what every call records (full request and response, identity attribution, latency, token estimate, and the four-leg correlation model), how attribution and non-repudiation work, how logging stays non-blocking and is retained, and how to forward logs to a SIEM over OpenTelemetry as compliance evidence.
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.
Viewing and exporting logs is gated by the **View and export logs** capability; configuring downstream log forwarding uses **Manage OpenTelemetry collector**; and the Reporting page is gated by **View reports**. If the **Logs** or **Reporting** links — or a per-entity **Logging** tab — aren't in your navigation, your role lacks the relevant capability. Capabilities are assigned per role and fully configurable, so access depends on the capability, not on any fixed role name. See the [capabilities reference](/deployment/rbac-and-roles/capabilities).
## 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](/features/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.
**Gateway rules shape what the client receives — they are not a log-redaction control.** A [gateway rule](/features/gateway-rules/overview) that redacts, masks, or blocks content changes the response the MCP **client** sees; it does not switch logging off or scrub the stored entry. The original client request is recorded on the inbound `proxy_request_success` leg **before** any request-side rule runs, so request-side redaction never removes the original from the audit log — and the rule's own activity is logged regardless (the `policy_enforced_mutation` and `policy_enforced_abort` types and the `rule_engine_*` columns). On the response leg, a rule that modifies or blocks the server's result is stored as the modified or blocked content rather than the original. Either way, by default applying a redaction rule produces an audit record; it does not keep sensitive values out of the stored trail. If your compliance posture requires that sensitive payloads not be written to the audit log at all, that can be configured for your workspace — discuss it with your MCP Manager contact.
### 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](/features/viewing-logs#log-types-and-the-correlation-model) for the full set, including the error and policy-enforcement types.
The `correlation_id` is also forwarded to the upstream server as the **`x-correlation-id`** header, so a single exchange can be followed across services — not just within MCP Manager's own records. MCP Manager forwards the OpenTelemetry **logs** and **traces** signals (not metrics): every log record carries `trace_id`, `span_id`, and `traceparent` columns, the gateway mints one **span** per proxied request (plus a child span per rule-engine evaluation) whether or not a traces collector is configured, and W3C `traceparent` propagates into downstream MCP servers — so a single request reconstructs as one distributed trace across client, gateway, and upstream. See [Export to SIEM](/enterprise/export-to-siem#traces-and-trace-correlated-logs).
## Attribution and non-repudiation
An audit trail is only as good as the identity behind each entry. Because the gateway brokers a specific [identity](/security/authentication-and-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](/enterprise/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](/enterprise/export-to-siem/self-hosted-collector#long-term-retention-to-object-storage) has a worked example.
## Reporting: the security and usage lens
The [Reporting](/features/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
Inline inspection of live traffic — injection defense, DLP, and kill switches.
The full log model — every column, the correlation model, scoped views, and export.
The dashboards and charts derived from your log data.
Forward MCP logs to any OpenTelemetry collector or SIEM.
## External sources
The open standard MCP Manager uses to forward logs downstream.