)
Last updated: November 4, 2026
What is MCP audit logging? MCP audit logging records every Model Context Protocol tool call, approval and configuration change. It keeps enough context to answer one question later: which agent did what, on whose behalf, with which tool, and was it allowed? For CISOs it is both a detection feed for the SIEM and the evidence auditors ask for.
TL;DR: Key Takeaways
- The MCP tools specification (version 2026-07-28) says clients should log tool usage for audit purposes and keep a human able to deny tool invocations (MCP specification, 2026).
- OWASP lists monitoring, logging and auditing as best practice 10 of 12 for MCP, with full parameters, user context and timestamps in every tool-call log (OWASP).
- Under the EU AI Act, providers and deployers of high-risk AI systems must keep automatically generated logs for at least 6 months (Articles 19 and 26).
- The AI Omnibus (Regulation (EU) 2026/1744) moved the high-risk rules to December 2, 2027 for Annex III systems and August 2, 2028 for Annex I products (EUR-Lex).
- 55% of 100 surveyed CISOs run MCP servers or other agent integrations in production, and 46% worry about agents exceeding permissions or being compromised (Andreessen Horowitz, 2026).
- The MCP logging utility has been deprecated since protocol version 2026-07-28, so build audit trails on clients or a gateway you control (MCP specification, 2026).
At a glance: what CISOs must track in MCP
Quick Answer
What should an MCP audit log contain?
For every tool call, log the end user, agent and client, plus the MCP server and version. Add the tool name and definition hash, the redacted arguments, the policy decision, any human approval, the result status and a timestamp with a trace ID. Also log server connections, tool definition changes and permission changes, and send it all to your SIEM.
| What to track | Why it matters | Who asks for it |
|---|---|---|
| Every tool call with user, agent and tool | Reconstructs who did what on whose behalf | Incident response, auditors |
| Policy decisions (allowed, blocked, masked) | Proves controls ran, not just that they exist | SOC 2 auditors, risk teams |
| Human approvals and denials | Shows oversight on sensitive actions | EU AI Act oversight, internal audit |
| Tool definition hashes and changes | Detects rug pulls and unapproved updates | Security engineering |
| New servers, clients and connections | Finds shadow MCP before it leaks data | CISO, governance teams |
| Credential and scope use per server | Spots over-privileged or shared tokens | Identity and access teams |
How we researched
On November 4, 2026 we reviewed the MCP tools and logging specifications (version 2026-07-28) and the OWASP MCP Security Cheat Sheet. We also read EU AI Act Articles 12, 19 and 26, the AI Omnibus regulation, the AICPA Trust Services Criteria and public descriptions of ISO/IEC 42001 Annex A. The field list and evidence map are our synthesis, not legal advice.
Why MCP audit logging is different from API logging
MCP audit logging needs its own design because the model, not a developer, decides which tool to call and with what arguments. Traditional API logs show that a service account called an endpoint. They rarely show which user asked, which agent chose the tool, which server answered, or whether a policy checked the call first.
According to OWASP's MCP Security Cheat Sheet, MCP lets models decide which tools to invoke, when and with what parameters. That mixes prompt injection, supply chain and confused deputy risks. Its key risks include data exfiltration through legitimate channels, where injected instructions hide sensitive data inside normal-looking tool calls. Only call-level logs with arguments can show that.
Ownership is also split. According to the MCP specification (2026), clients should log tool usage for audit purposes, while servers must validate inputs, enforce access controls, rate limit calls and sanitize outputs. With many clients and many servers, no single team sees the whole picture unless logs are collected in one place. For the fundamentals, start with our MCP security guide.
)
What to log for every MCP tool call
Log enough to rebuild the event without asking the agent what happened: identity, context, the action, the control decision and the outcome. Treat the record as evidence, with consistent fields, one trace ID across hops and no secrets in the payload.
| Field group | Fields to capture | Notes |
|---|---|---|
| Identity | End user, agent ID, client application, tenant | Log the human principal, not only the service account |
| Server | MCP server name, version, transport, endpoint or launch command | Lets you tie a call to an approved registry entry |
| Tool | Tool name, definition hash, annotations at call time | A hash mismatch is a rug pull signal |
| Request | Arguments (redacted), argument hash, size | Hash lets you prove integrity without storing raw data |
| Authorization | Token audience, scopes used, credential ID | Never log the token itself |
| Policy | Decision (allow, block, mask, require approval), rule ID, detector results | Shows that controls actually ran |
| Human oversight | Approver, decision, timestamp, parameters shown | Evidence of human-in-the-loop |
| Outcome | Result status, error type, latency, response size, redacted response summary | Supports anomaly and data loss detection |
| Correlation | Trace ID, session or conversation ID, parent call ID | Links multi-step agent chains |
Here is a simplified, illustrative audit record. Field names are examples, not a standard.
Also log the events around the calls: server connections, tool list changes, new tools, failed authorizations, policy edits and changes to who can approve what. They are often the first signs of trouble.
What not to log: secrets, personal data and noise
An audit log that stores tokens or customer data becomes a breach target of its own. According to the MCP logging specification (2026), log messages must not contain credentials or secrets, personal identifying information or internal system details that could aid attacks. OWASP adds the same rule for MCP audit trails: redact secrets and PII.
Investigators want full parameters and privacy teams want less data. Three patterns resolve most of that tension:
- Redact at the source: mask secrets, tokens and personal data before the record leaves the gateway or client, not later in the SIEM.
- Hash what you cannot keep: store a hash of raw arguments and responses so you can prove integrity without storing the content.
- Tier the detail: keep full metadata for every call and fuller redacted payloads only for sensitive tools, with stricter access controls on that tier.
The MCP logging utility is not a substitute. It lets servers send structured log messages to clients, with severity levels based on syslog (RFC 5424). The specification deprecated it in version 2026-07-28 and tells new implementations not to adopt it. It points to stderr for stdio servers and OpenTelemetry for structured observability. Either way, the server you are auditing controls those messages, so your audit trail should come from a component you control.
Getting MCP audit logging into your SIEM
Logs only become a control when someone acts on them. Stream MCP audit records to your SIEM in a structured format and map them to your identity and asset data. Then write detections for the patterns OWASP names: new tools being called, admin-level queries and abnormal call frequency.
| Detection | Signal in MCP logs | Typical response |
|---|---|---|
| Rug pull | Tool definition hash differs from the approved pin | Block the tool, open a review |
| Shadow MCP | Calls to a server or endpoint not in the registry | Block, identify the owner, assess data exposure |
| Data exfiltration | Secrets or personal data detected in arguments to external tools | Block or mask, alert the data owner |
| Cross-server leakage | Data returned by server A appears in calls to server B | Isolate servers, review prompts and tools |
| Privilege misuse | Admin-level tools or scopes used outside normal patterns | Step-up approval, revoke credentials |
| Approval bypass | Sensitive tool executed without a logged approval | Treat as an incident, fix the policy |
Normalize before you build detections: one schema across clients and gateways, timestamps in UTC, one trace ID per agent task and each server tagged with its registry status and owner. Our AI gateway observability guide covers how gateway telemetry feeds monitoring tools.
Finally, test the pipeline with a planned red team exercise that triggers each detection, and check that alerts reach the right queue.
Compliance evidence: EU AI Act, SOC 2 and ISO 42001
MCP audit logs map well to the record-keeping and monitoring duties in major AI and security frameworks. None of them mention MCP by name. They ask you to record system events, keep those records and show that you monitor them, which tool-call logs do directly for agents.
| Framework | What it asks for | MCP log evidence |
|---|---|---|
| EU AI Act Article 12 | High-risk AI systems must technically allow automatic recording of events (logs) over their lifetime | Gateway or client logs of every agent action and tool call |
| EU AI Act Article 19 and 26(6) | Providers and deployers keep automatically generated logs under their control for at least six months, unless other law says otherwise | Retention policy and storage for MCP audit records |
| EU AI Act Article 26(5) | Deployers monitor the operation of high-risk AI systems | SIEM alerts, review records and incident tickets |
| SOC 2 CC7.2 | Monitor system components for anomalies and analyze them to decide whether they are security events | MCP detections in the SIEM, triage records |
| SOC 2 CC7.3 | Evaluate security events to decide whether they are incidents and act on them | Incident tickets linked to MCP log entries |
| ISO/IEC 42001 Annex A, A.6.2.8 | Decide at which life cycle phases event logs are recorded, at minimum while the AI system is in use | A documented logging decision per agent, plus the logs themselves |
Three points to get right with legal and audit teams:
- Scope first: the EU AI Act logging duties attach to high-risk AI systems. An internal coding agent is not high-risk by default, but an agent used in hiring or credit decisions may be. Decide which agents are in scope before you design retention.
- Know the dates: according to Regulation (EU) 2026/1744 (2026), the high-risk rules apply from December 2, 2027 for Annex III systems and August 2, 2028 for Annex I products.
- Keep more than logs: SOC 2 auditors look for monitoring that operates, so store alert rules, owners and review records next to the logs.
For broader AI Act planning, see our EU AI Act enterprise compliance guide.
Detecting shadow MCP servers with your logs
Shadow MCP means servers that employees or teams connect to agents without security review. It is a form of shadow AI and hard to see, because a local server can run as a child process of an IDE or desktop app. Compare what you approved with what actually runs.
Use four data sources together:
- Gateway logs: traffic to a server that is not in your registry is shadow MCP by definition. Route remote MCP traffic through a gateway so this view is complete.
- Endpoint telemetry: MCP client configuration files and the processes that IDEs and desktop assistants launch for local servers.
- Network and DNS logs: outbound connections from developer machines to unknown remote MCP endpoints.
- Identity and OAuth logs: new OAuth grants to AI clients or MCP servers, showing who connected what, with which scopes.
Then triage it like any unknown asset: find the owner, check what data the server could reach, and onboard or block it. Our guide to shadow AI risks, detection and prevention covers the wider program, and our MCP registry and allowlist guide shows how to onboard approved servers.
Security and governance: one audit trail at the gateway
The hard part of MCP audit logging is coverage. Every client logs differently, local servers log nothing you control and remote servers belong to vendors. A gateway in front of MCP traffic records identity, policy decisions and tool calls the same way, whichever agent or server is involved.
According to Andreessen Horowitz (2026), 55% of 100 surveyed CISOs already run MCP servers or similar integrations in production, so coverage gaps are not hypothetical.
NeuralTrust approaches this as a Runtime Security Mesh. The Agent Gateway (TrustGate) forwards end-user identity through every hop and applies per-agent and per-tool RBAC. It keeps cryptographic audit trails designed to survive review by your security team and your auditor. Its MCP Gateway tracks which LLM accessed which tool, with clear permissions and purposes. NeuralTrust reports split-plane data residency, so sensitive data stays in your perimeter.
Agent Posture Management (TrustLens) supports the inventory side, and AI Red Teaming (TrustTest) checks that controls and detections hold. Plan limits matter for evidence: the Free plan keeps logs for 7 days and the Standard plan for 30, while SIEM and OTel integrations come with Enterprise. For a market view, see the best MCP gateways and our AI gateway vs MCP gateway comparison.
Where should you start?
Start with coverage, then detection, then evidence. A perfect schema means little if half your MCP traffic bypasses it. Once traffic flows through one control point, add detections, then shape retention and reports for auditors. Each phase depends on the one before it.
| Phase | Goal | Key actions |
|---|---|---|
| 1. Coverage | See every MCP call | Route remote MCP traffic through a gateway, inventory local servers, agree on one log schema |
| 2. Detection | Act on what you see | Stream logs to the SIEM, add rug pull, shadow MCP and exfiltration detections, assign owners |
| 3. Evidence | Prove it to auditors | Set retention per framework, document logging decisions per agent, keep review records |
Identity is the thread through every phase. If calls do not carry the end user, the logs cannot answer "on whose behalf." Our MCP authentication guide explains how OAuth and token handling preserve it.
Conclusion
MCP audit logging is how a CISO turns agent activity into something security teams can investigate and auditors can verify. Log every tool call with user, agent, server, tool hash, redacted arguments, policy decision and outcome. Keep secrets out, stream the records to the SIEM and write detections for rug pulls, shadow MCP and exfiltration. Then map the same records to EU AI Act, SOC 2 and ISO 42001 evidence. A single gateway makes that coverage realistic.
Secure MCP Audit Trails in Production with NeuralTrust
Record every agent and MCP tool call with identity, policy decisions and redaction, and stream the audit trail to your SIEM on the Enterprise plan.
)
Related Comparisons
FAQs about MCP Audit Logging
1. What is MCP audit logging?
MCP audit logging records every Model Context Protocol tool call, approval and configuration change with identity, context and outcome. It answers which agent did what, on whose behalf, with which tool and under which policy. Security teams use it for detection in the SIEM, and auditors use it as evidence that controls operate.
2. What should be logged for each MCP tool call?
Log the end user, agent, client, MCP server and version, tool name and definition hash. Add redacted arguments, scopes used, policy decision, any human approval, result status, latency and a trace ID. OWASP recommends full parameters, user context and timestamps, with secrets and personal data redacted.
3. Does the MCP specification require audit logging?
The MCP tools specification says clients should log tool usage for audit purposes, which is a recommendation, not a strict requirement. It also says a human should always be able to deny tool invocations. The separate MCP logging utility is for server diagnostics, must not contain secrets or personal data and has been deprecated since version 2026-07-28.
4. How long should MCP audit logs be kept?
It depends on your obligations. For high-risk AI systems, the EU AI Act requires providers and deployers to keep automatically generated logs under their control for at least six months. That floor applies unless other Union or national law says otherwise. Sector rules, contracts and SOC 2 commitments may require longer. Set retention per agent with legal input.
5. Do MCP logs help with SOC 2 and ISO 42001?
Yes. SOC 2 criterion CC7.2 asks you to monitor system components for anomalies, and CC7.3 to evaluate security events, so MCP detections and triage records are direct evidence. ISO/IEC 42001 Annex A control A.6.2.8 asks you to decide when event logs are recorded, at minimum while the AI system is in use.
6. How do you detect shadow MCP servers?
Compare what you approved with what runs. Gateway logs show traffic to unregistered servers, and endpoint telemetry shows local MCP configurations and processes. Network logs show calls to unknown remote endpoints, and OAuth logs show new grants to AI tools. Then find each owner and either onboard the server or block it.
About the Author
Roger Howroyd is Head of Global SEO and AI at NeuralTrust, where he leads the company's search strategy across SEO, AEO, GEO, and LLM optimization. He specializes in AI-powered search, content strategy, and SEM. Connect on LinkedIn.
NeuralTrust is the leading platform for securing and scaling AI agents. Named a Pioneer in the Gartner Emerging Market Quadrant for AI Application Security 2026, recognized across four Gartner Hype Cycle reports in 2026, and featured in the Gartner Market Guide for Guardian Agents 2026, the Gartner Market Guide for AI Gateways 2025 and the KuppingerCole Leadership Compass for Generative AI Defense 2025. Headquartered in Barcelona with offices in London and New York. ISO 27001 certified.
Sources
Accessed on November 4, 2026.
- Model Context Protocol, "Tools" (spec version 2026-07-28), 2026.
- Model Context Protocol, "Logging" (spec version 2026-07-28, deprecated feature), 2026.
- OWASP Cheat Sheet Series, "MCP Security Cheat Sheet".
- EU Artificial Intelligence Act, "Article 12: Record-Keeping", "Article 19: Automatically Generated Logs" and "Article 26: Obligations of Deployers of High-Risk AI Systems".
- European Union, "Regulation (EU) 2026/1744 (Digital Omnibus on AI)", Official Journal, July 24, 2026.
- AICPA, "2017 Trust Services Criteria (with revised points of focus, 2022)".
- ISO, "ISO/IEC 42001:2023 Artificial intelligence: Management system".
- Andreessen Horowitz, "The New Security Agenda", 2026.
)
)
)
)