MCP Audit Logging SOC 2 EU AI Act: What a Data Agent Audit Trail Must Record
The MCP protocol does not give you an audit trail, so here is what to build for auditors and regulators
The Model Context Protocol does not specify an audit trail, so MCP audit logging for SOC 2 or the EU AI Act is something you build around the protocol, not something you switch on. The MCP specification defines how clients and servers exchange tools, resources, and prompts, and it includes a logging utility for sending diagnostic messages to the client. That is debugging output, not evidence. Article 12 of the EU AI Act separately requires high-risk AI systems to technically allow automatic recording of events over their lifetime, which is the standard an audit trail has to meet in that jurisdiction.
Key Takeaways
- •MCP gives you transport and tool semantics, not a compliance-grade audit log. The server operator has to produce the evidence.
- •A usable agent audit record answers who (human and agent identity), what (tool, arguments, result summary), when, on what data, and under whose approval.
- •SOC 2 Type II auditors test controls over an observation period, so logs need to exist continuously and be tamper-evident, not reconstructed at audit time.
- •EU AI Act Article 12 applies to high-risk systems. In our opinion most data engineering agents are not high-risk by default, but the same schema satisfies both regimes cheaply.
- •Log metadata and hashes of payloads, not raw PII. An audit trail that leaks the data it protects is a new liability.
MCP audit logging SOC 2 EU AI Act: what each regime asks for
SOC 2 and the EU AI Act do not mention MCP. They ask for outcomes, and you map your MCP deployment onto them. SOC 2 is an attestation against the AICPA Trust Services Criteria, assessed by an independent auditor. The EU AI Act is a regulation with obligations that depend on how your AI system is classified. The table below is our reading, not legal or audit advice, so confirm scope with your auditor or counsel.
| Requirement area | SOC 2 (Trust Services Criteria) | EU AI Act | What it means for an MCP data agent |
|---|---|---|---|
| Access and identity | CC6 logical access controls | Traceability of system operation (Art. 12) | Log the human principal and the agent identity on every tool call |
| Monitoring | CC7 system operations and anomaly detection | Logs support post-market monitoring and risk identification (Art. 12) | Keep logs queryable so unusual tool use can be detected and reviewed |
| Change control | CC8 change management | Documentation and record-keeping duties | Record schema, permission, and pipeline changes an agent proposed or applied |
| Human oversight | Evidence of approval for sensitive actions | Human oversight design (Art. 14) | Log who approved a write, when, and what they saw |
| Retention | Defined by your policy, tested by the auditor | Providers and deployers keep logs for at least six months (Arts. 19 and 26) | Set retention by policy and make deletion itself an audited event |
The retention floor comes from the Act's text on provider and deployer log keeping, and longer periods may apply under sector rules or your own SOC 2 policy. High-risk obligations also phase in on a published timeline that has been the subject of revision proposals, so check the current dates before you plan around them.
Why the default MCP setup falls short
A typical local MCP setup has an editor such as Claude Code or Cursor launching a server over stdio. The client may keep a transcript, but the transcript lives on a developer laptop, is not tamper-evident, and does not record what the server actually did against your warehouse. Three gaps show up in nearly every audit conversation we have seen described:
- •Identity collapse: the warehouse sees one service account, so the question "which engineer asked the agent to do this" has no answer in the database logs.
- •Argument opacity: a tool call like run_query appears as a query in warehouse history but without the prompt, the approval, or the agent that issued it.
- •Mutable storage: plain log files can be edited or rotated away, which an auditor treats as no control at all.
The MCP authorization model, covered in the MCP specification, helps with the first gap for remote servers by letting you tie requests to an authenticated principal. It still leaves the audit record itself to you.
The audit record schema we recommend
We treat every MCP tool invocation as one immutable event. This is our opinion on a sensible minimum, drawn from the criteria above rather than from any standard that prescribes field names.
- •event_id and timestamp (UTC, from the server, not the client)
- •principal: the authenticated human, plus the agent or client identity (for example Claude Code or Cursor) and session ID
- •tool name and a hash of the arguments, with the arguments themselves stored only where policy allows
- •resource targets: warehouse, schema, table, and columns touched, including any columns classified as PII
- •outcome: success, denied, or error, plus rows affected for writes
- •policy decision: which RBAC rule allowed or blocked the call, and the approval reference for gated actions
- •previous_hash: the hash of the prior event, which chains records so tampering is detectable
The hash chain is the cheapest tamper-evidence control available. Each record includes the hash of the one before it, so altering or deleting an entry breaks every later hash. Periodically anchoring the latest hash in a separate system, such as object storage with write-once retention, gives your auditor something independent to verify against.
Step by step: build the trail without logging PII
The tension in data work is that the thing you are auditing often is sensitive data. A query result can contain exactly the customer records you are trying to protect. Our approach is to log the decision and the footprint, not the payload.
- •Put the logging in a wrapper or gateway in front of every MCP server, so no tool can be called without producing an event.
- •Resolve the human identity before the call using your SSO provider, and reject calls that arrive without one.
- •Classify columns before agents touch them, so the event can say a call read a PII column without storing the value.
- •Store argument hashes and row counts by default, and keep full arguments only for write operations that need replay.
- •Write events to append-only storage, hash-chained, with a separate role for reading logs and no role that can edit them.
- •Test the trail the way an auditor will: pick a random week, pick an agent action, and trace it from prompt to warehouse change.
Our Governance Agent does this classification and RBAC policy work as part of the Data Workers platform, including PII detection and audit trails, and it runs as an MCP server like the others. If you build your own, the same sequence applies. We covered how to constrain what agents can do in the first place in a separate post on MCP security for data agents, and our Catalog Agent posts explain how column-level classification feeds the policy decisions logged here.
Where a logging layer is not enough
Logging records what happened. It does not prevent it. SOC 2 expects preventive controls alongside detective ones, which means read-only defaults, least-privilege credentials, and approval gates on writes. Our OSS edition, dw-claw, is read-only by default for this reason, and write access with approval workflows is a Pro feature. In our opinion, an agent that can write to production with only a log to catch mistakes is a finding waiting to happen.
There is also a scoping question. The EU AI Act classifies systems by use case, not by technology. A pipeline-debugging agent is a long way from the high-risk categories in the Act's annexes, such as employment or credit decisions. If an agent's output feeds decisions in those areas, the log requirements and the human oversight duties become mandatory rather than good practice. Get that classification from counsel, not from a blog post.
Frequently Asked Questions
Does MCP have built-in audit logging? No. The protocol includes a logging utility that lets servers send log messages to clients, but it is meant for diagnostics. An audit trail for compliance has to be implemented by the server operator or a gateway in front of the servers.
Will a SOC 2 auditor accept agent logs as evidence? An auditor accepts evidence that shows a control operated consistently over the observation period. Complete, time-stamped, access-controlled, tamper-evident records of agent actions, tied to named human principals, are the kind of evidence they sample. Confirm the specifics with your own auditor.
Does the EU AI Act require audit logs for every AI agent? No. Article 12 record-keeping applies to high-risk AI systems as defined by the Act. Other systems face lighter obligations, though logging is still sensible practice. Whether your agent is high-risk depends on its intended use, so check with counsel.
How long should we keep MCP agent audit logs? The EU AI Act sets a floor of at least six months for high-risk system logs held by providers and deployers. SOC 2 retention is whatever your documented policy says, and auditors test that you follow it. Many teams align on twelve months or more; that is a policy choice, not a rule.
Should we log the full query results an agent returns? In most cases no. Store a hash, the row count, and the columns touched. Keeping result payloads in your audit log copies sensitive data into a second system that now needs its own controls.
Can we run this locally with Claude Code or Cursor? Yes. The logging wrapper sits between the client and the MCP servers, so it works with any MCP-compatible client. Data Workers agents are MCP servers, so the same pattern applies to them.