MCP Audit Logging: What to Record

MCP audit logging means keeping a reliable record of what AI agents did through MCP: which person or agent called which tool, on which server, with what inputs, when, and with what result. Good logs let you answer "what happened?" after a mistake or an attack. Without them, you are guessing.

The MCP tools specification says clients should "Log tool usage for audit purposes." OWASP lists "Lack of Audit and Telemetry" as one of its ten MCP risks. Neither tells you exactly which fields to keep, so this guide does.

It covers the fields to record, the events beyond tool calls, what to mask, and how to protect the logs themselves. Sources were checked on 28 October 2026.

What the spec and OWASP say

The MCP tools specification lists logging among client SHOULDs: "Log tool usage for audit purposes." It also says there should be a human able to deny tool calls, which makes approval decisions worth logging too.

The MCP Security Best Practices add three specific logging points:

• Servers should "Log elevation events (scope requested, granted subset) with correlation IDs."
• Clients should "Log suspicious authorization URLs for security monitoring."
• Proxies that spawn local servers should "Log all stdio transport usage for security monitoring."

OWASP's MCP08 entry goes further. It lists essential fields (timestamp, agent ID, session ID, tool invoked, parameters, response summary and user identity) and recommends structured formats such as JSON or OpenTelemetry. The OWASP project is in beta as of October 2026.

The fields to record for every tool call

Use one structured format across all servers. That makes searching and alerting far easier than mixed text logs.

Events beyond tool calls

Tool calls are only part of the picture. Also record:

1. Approvals and denials. Who approved a risky call, and which calls were refused.
2. Scope changes. When a token gained new scopes, as the best practices recommend.
3. Server changes. Installs, removals, version upgrades and config edits.
4. Tool-list changes. When a server's tools or descriptions change. Servers can signal this with a notifications/tools/list_changed message, per the tools spec. Unexpected changes may point to a rug pull.
5. Authentication events. Sign-ins, failures, token refreshes and revocations.
6. Blocked actions. Requests stopped by a gateway, sandbox or policy.

What not to log in clear text

Logs are a target. If they hold tokens, anyone who reads them can reuse those tokens.

Two 2026 advisories show how this goes wrong. OpenPanel accepted MCP credentials in a URL query string and wrote the full URL to logs, per its GitHub advisory. Its logger redacted sensitive keys but not tokens embedded inside a URL. A Meta Ads MCP server returned request URLs containing the operator's access token in error responses, per its advisory.

Mask or remove:

• Access tokens, refresh tokens, API keys and client secrets, including inside URLs and error messages.
• Passwords and one-time codes.
• Personal data you do not need for the investigation, such as full email bodies.
• Full prompts and tool outputs, unless you have a clear reason and a retention limit.

The token passthrough section of the best practices adds another reason to get identity right. When servers forward tokens, downstream logs "may show requests that appear to come from a different source," which makes investigations harder. See why MCP servers must not pass tokens through.

Protect the logs themselves

OWASP's MCP08 entry recommends:

• Hashing log files and storing them in "append-only or write-once media."
• Restricting log access, with dual authorization for deletion.
• Forwarding logs to a SIEM (security information and event management) system and alerting on high-risk activity.
• Setting retention to meet your compliance needs; it cites PCI DSS's one-year minimum as an example.

A practical rule: no AI agent should be able to read, edit or delete its own audit logs. Keep them outside every MCP server's reach.

For general logging practice beyond MCP, the joint guidance Best Practices for Event Logging and Threat Detection, published on 21 August 2024 by Australia's ASD with CISA, the FBI, the NSA and other partners, sets a baseline.

Check what your AI client records

Client defaults vary, so read the docs. For example, Claude Code's monitoring docs describe OpenTelemetry events including claude_code.tool_result and claude_code.tool_decision.

By default, the same docs say, prompt text is redacted. Names of user-configured MCP servers and tools are replaced with "custom" on several metrics and events. Setting OTEL_LOG_TOOL_DETAILS=1 records tool parameters and the real MCP server and tool names. Decide deliberately: real names help investigations, and full parameters may need masking downstream.

Other clients and gateways have their own settings. Our guide to MCP governance for IT leaders covers central controls.

A short logging rollout plan

1. List where tool calls can be logged: the client, a gateway, the server, or all three.
2. Pick one structured format and the fields in the table above.
3. Add masking before logs leave the machine or service.
4. Send logs to one central store the agents cannot reach.
5. Write three alerts: a denied call on a write tool, a new server installed, and a tool-list change.
6. Test it. Run a known tool call and confirm you can trace it end to end.

Next step

Want to know whether your current logs would answer "what did the agent do?" Our MCP readiness audit tests that with you. Building your own server? Our MCP development team builds structured, masked logging in from day one.

Frequently asked questions