AI Audit: How to Audit AI Systems & Agent Activity
You can audit AI systems by capturing every agent-to-tool interaction, attributing each action to a named user, and exporting that record to your existing monitoring stack.
Most organizations already audit human-initiated actions. Agent traffic breaks those practices in a specific way: one prompt can fan out into dozens of tool calls across several servers in seconds, and the protocol carrying them records almost nothing you can audit. The Model Context Protocol (MCP) defines how a client and a server talk. But it gives an organization no way to see, secure, or govern what happens across many clients and many servers. What’s left can’t answer what a regulator will ask: who triggered this, what data did the agent reach, and was any of it sensitive?
This guide covers what an AI audit should include, how to capture audit logs for MCP tool usage, and how to get that data into a SIEM.
Key Takeaways
- An AI audit must cover identity attribution, tool-level access logs, data classification, and policy enforcement evidence.
- MCP’s Logging utility was never an audit channel: it’s an opt-in, request-scoped debug stream the spec forbids from carrying PII, and it was deprecated in protocol version 2026-07-28 in favor of stdio or OpenTelemetry.
- That revision also removed protocol-level sessions, so nothing at the transport layer ties a burst of tool calls together.
- MCP Manager writes four entries per message under one correlation_id, each naming the acting user and the identity used upstream.
- Export over OpenTelemetry (OTLP/HTTP) to any collector: Datadog, Grafana Cloud, Splunk, or your own.
What Should an AI Audit Cover?
A complete AI audit answers four questions per call: who acted, what they touched, what data moved, and which policy was in force. Native protocol logging answers none of them.
Identity Attribution
Every action an agent takes needs to resolve to a specific person. Agents commonly authenticate downstream through a shared service account, collapsing thousands of calls into one indistinguishable principal.
The regulatory requirement is narrower than “don’t use service accounts.” Article 20 of DORA’s RTS on ICT risk management requires unique identification of the natural persons and systems reaching a financial entity’s information. Its recitals then permit shared accounts in specified circumstances, provided accountability for actions taken through them is maintained. The obligation is to be able to say who was behind the call.
An MCP gateway reconstructs that, because it authenticates the caller at its own layer regardless of how the server authenticates. MCP Manager writes user_name, user_email, user_guid, and ip_address onto every entry, onto every entry, alongside org_guid, team_guid, and the identity used upstream. Under a per-user identity scheme the downstream system sees the real person too. Under a shared scheme your log still names the individual but the server doesn’t. Set that per server, not once per gateway.
Tool-level Access Logs
You need which server was contacted, which tool ran, what went in, and what came back: the JSON-RPC method, the feature_type and feature_name, full headers and body where the storage policy allows, duration_ms per leg, and response_code.
Don’t derive read-versus-write from the server’s own account of its tools. The spec instructs clients to treat tool annotations as untrusted unless they come from trusted servers. Classify against the allowlist you control in feature provisioning. And tool names are unique only within a server, so a line naming only the tool is ambiguous.
Data Classification and PII Tracking
Did the interaction involve personal data? Your trail needs to answer per call, not as a standing assumption about the server: a CRM tool can return aggregate counts on one call and full profiles on the next.
Classification happens inline. Gateway rules fire on the request leg, scanning params.arguments, or on the response leg, scanning the result before it reaches the client. Detection is a regex, Microsoft Presidio, or a custom engine, and the verdict lands in rule_engine_type as pass, modify, or block. One scope limit: rules run on tools/call only, not prompts or resources.
Policy Enforcement Evidence
Auditors want proof the control was live when the call happened. A blocked message is logged as policy_enforced_abort and a modified one as policy_enforced_mutation. Block entries record the specific detection that fired, the Presidio entity or regex pattern, not just the rule name.
What makes that evidence rather than noise is knowing whether the engine evaluated anything. MCP Manager separates the alert codes: policy_triggered.tool_response means a verdict came back, while rule_engine_error_verdict means the engine was unreachable and the rule’s failure mode decided. A block you can’t tell apart from a timeout proves nothing.
How to Get Audit Logs for MCP Tool Usage
Two things need to be true before you have an audit trail: the protocol has to produce a usable record, and something has to attach identity and policy context to it. MCP’s 2026-07-28 revision removed the session state and deprecated the one logging mechanism it had. So both jobs now fall to whatever sits between your clients and your servers.
Why Native MCP Logs Fall Short
MCP does specify a Logging utility, and it’s worth being precise about it, because it isn’t an audit trail. Servers send notifications/message to clients at RFC 5424 syslog severity levels. Three properties disqualify it:
- It’s opt-in and request-scoped. A server MUST NOT emit a log notification for a request that didn’t set io.modelcontextprotocol/logLevel in _meta.
- It terminates at the client. The stream ends in whatever app made the call, not in a system your security team runs.
- The spec forbids the content you need. Log messages MUST NOT contain credentials or personal identifying information.
It’s also on the way out, deprecated in protocol version 2026-07-28 alongside Roots and Sampling. New implementations shouldn’t adopt it; the recommended migrations are stderr for stdio servers or OpenTelemetry for structured observability.
That revision also removed the other thing teams reach for. Protocol-level sessions and the Mcp-Session-Id header are gone from Streamable HTTP: every request carries its own version and client identity in _meta and can land on any instance behind a load balancer. Good for scaling, awkward for auditing: no transport-level identifier binds a sequence of calls into one session.
Using an MCP Gateway for Forensic-grade Logging
An MCP gateway supplies what the protocol dropped, and the current spec makes that position easier to hold: Mcp-Method and Mcp-Name are now required headers on Streamable HTTP POSTs, so an intermediary can route and authorize on headers without parsing bodies.
One MCP message travels four legs, each logged under a shared correlation_id:
- The client’s request arriving (proxy_request_success)
- The gateway’s request out (mcp_request_success)
- The server’s response back (mcp_response_success)
- The gateway’s response to the client (proxy_response_success)
Filtering on that ID reconstructs the exchange, and it’s forwarded upstream as x-correlation-id so the trail continues past the gateway.
Local servers get the same treatment. A workstation server stays on the laptop and reaches the gateway over a WireGuard-based encrypted tunnel, with a local router validating an access key before forwarding. No inbound port opens, and calls are logged and rule-checked like a remote server’s.
Setting Up Audit Logging
Logging is on by default, and writes happen outside the request’s critical path, so a logging failure won’t slow or fail the call.
Attribution comes from your IdP. Sign-in is OpenID Connect federated through Auth0 — there are no SAML endpoints — and SCIM 2.0 provisions users and syncs IdP groups to teams. Okta, Entra ID, Google Workspace, and Keycloak all work.
Two settings then decide whether the logs stand as evidence.
- The workspace-wide log storage policy sets what gets written: All data, Metadata only, or Zero data retention, with All data locked out under a HIPAA designation.
- The retention period is organization-level and plan-tied, starting at 14 days and reaching a year or more.
How to Export AI Audit Data to a SIEM
Audit logs that live only inside the tool that generated them have limited value. Your security team works in Splunk, Datadog, Sentinel, or Grafana. The data needs to be there too.
OpenTelemetry Export
MCP Manager forwards logs and request traces as JSON-encoded OTLP/HTTP records; metrics aren’t sent. Two notes save most of the setup pain: URLs are used verbatim with nothing appended, so paste the complete signal path (/v1/logs, or a vendor prefix like Grafana Cloud’s /otlp/v1/logs). Each organization forwards to one collector, so fanning out means running your own.
Correlation is real distributed tracing, not just a shared ID. The spec now documents the OpenTelemetry convention of carrying W3C traceparent in _meta. The gateway continues an incoming trace or mints a root, then propagates context downstream. So a SOC analyst can pivot from an MCP tool call to a network event and an identity event in one waterfall.
What Gets Exported
By default the export mirrors what MCP Manager stores. Export content can override that to Full data, Metadata only, or Do not export.
Three limits to build around:
- Gateway rules don’t filter forwarded records. If a rule masks PII for the client, the unmasked record still reaches your collector — so treat that collector as in scope, or set Metadata only.
- There’s no buffering and no replay. A record emitted while the collector is unreachable isn’t delivered.
- Filtering is all-or-nothing per record. Splitting auth events from tool calls into separate indexes is a job for your collector’s pipeline.
Best Practices for AI Auditing
Turning MCP Manager’s audit logs into evidence a security review or regulator will accept comes down to five choices: sequencing identity before server connections, logging guardrail enforcement alongside access, scoping gateway rules per team, treating the audit trail as a continuous SIEM feed, and matching log retention to whichever rule binds you — HIPAA, the EU AI Act, or DORA.
1. Start with Identity, Not Tools
The common sequencing mistake is inventorying servers before solving identity. If you can’t attribute actions to people, the inventory is a list of things you can’t audit. Connect the IdP, map users to teams, set the identity scheme per server, then connect servers — the order MCP Manager’s safe rollout sequence uses, so governance lands before data moves.
2. Log Guardrail Enforcement, Not Just Access
“User A called Tool B” is incomplete. “User A called Tool B, a Presidio rule replaced two email addresses on the response leg, the response was delivered” is what an auditor needs. Rule activity is recorded every time a rule runs, not only when it blocks.
One consequence catches teams out: a rule shapes what the client receives, not what the log stores. The original request is written on the inbound leg before any request-side rule runs, so redaction produces an audit record rather than scrubbing one.
3. Use Per-team Policies
Marketing’s HubSpot access doesn’t need the same guardrails as finance’s billing access. The mechanism matters: rules attach to a gateway, and teams grant access to gateways. So per-team policy means a gateway per team or use case, not a per-team setting on a shared one. One org-wide gateway means one rule set.
4. Don’t Treat Audit as a One-time Exercise
AI auditing is a continuous feed, not a quarterly review. Put the standing detections in your SIEM: unusual write volume from one user, a server reached outside business hours, a rule blocking above baseline.
MCP Manager’s Alerts page is in-app only today, so treat it as a feed you check rather than a channel that pages you. Anything that needs to wake someone up should route to your SIEM instead.
5. Match Retention to the Rule That Binds You
Set retention from the obligation, not the default. HIPAA’s audit controls standard, 45 CFR §164.312(b), is a Required standard. It requires you to record and examine activity in systems that use ePHI, but it doesn’t set a log retention period. That period comes from a separate rule, the six-year documentation requirement at §164.316(b)(2)(i). The EU AI Act sets its own floor: Article 26(6) requires deployers of high-risk systems to keep automatically generated logs for at least six months. Against either floor, a 14-day-default is short.
Conclusion: Build the Audit Trail Before You Need It
An audit trail isn’t a compliance tax you pay after adoption. It’s the artifact that lets a security review say yes. Without one, every new MCP connection is an open-ended risk conversation with no evidence on the table. With one, the review has something specific to check, and the answer can be scoped to a server, a team, or a tool rather than to AI in general.
If your setup can’t answer “who accessed what, when, and under what policy” for every agent interaction, that gap surfaces somewhere: a compliance review, an incident nobody can reconstruct, or the time it takes to approve the next use case.
See how MCP Manager’s audit logging works, or book a demo to walk through a proof of concept against your own stack.
FAQ
What is an AI audit?
An AI audit is a structured review of how AI systems operate in an organization: which tools agents access, what data flows through those connections, who initiated each action, and whether governance policies were enforced.
What should an AI audit trail include?
An AI audit should include per-user identity attribution, access logs naming both the server and the tool, data classification records, PII detection and redaction events, the outcome of every policy evaluation, and timestamps for each leg of the interaction.
How do I get audit logs for MCP tool usage?
Use an MCP gateway between your AI clients and MCP servers. Because every request passes through it, it records the identity, team, and policy metadata the protocol doesn’t carry, and mints the correlation and trace IDs the transport no longer provides.
Can I export AI audit data to Splunk or Datadog?
Yes, over OpenTelemetry, provided the destination accepts OTLP/HTTP logs. Datadog, Grafana Cloud, New Relic, and Honeycomb do. Splunk Observability Cloud has no OTLP logs intake, so it needs a Collector in front to translate to Splunk HEC — the fallback for any backend that can’t take OTLP logs natively.
How does AI auditing help with HIPAA compliance?
45 CFR §164.312(b) requires mechanisms that record and examine activity in systems containing ePHI. Gateway logs supply that record for agent traffic, and rule activity in the same entries evidences that PHI redaction was active. Note that redaction shapes what the model receives; keeping payloads out of the stored log is a separate decision.
Do MCP servers provide sufficient audit logs on their own?
No. MCP’s Logging utility is an opt-in, request-scoped debug channel that reports to the client, is specified not to carry PII, and was deprecated in protocol version 2026-07-28. It carries no user identity, no data classification, and no policy outcome.
How do I audit local MCP servers running on developer laptops?
Register them as workstation servers. The server stays on the machine and reaches the gateway over a WireGuard-based encrypted tunnel with no inbound port exposed, and a local router validates an access key on each request. Once tunneled, calls are logged, attributed, and rule-checked like remote ones.
Is an AI audit only relevant for regulated industries?
No. Internal legal review, customer security questionnaires, and the operational need to know what your agents are doing all create audit requirements independent of any regulator.
