When the Deadbugz campaign was published in August 2026, the first question most teams asked was "were we affected?" Most could not answer it. The malicious MCP server behaved like a text formatter for its first three tool calls and only then changed the instructions it sent to the agent. A team that had logged nothing but "server connected" had no record of what the server said, what the agent did next, or which files it touched. This guide is the logging setup we wish we had had before our own MCP audit: what to record, where, and how long to keep it.
What should an MCP audit log contain?
An MCP audit log should record every server launch with its exact command and version, every tool definition the server sends and any change to it, every tool call with its arguments and result size, the identity and token scopes behind each call, and outbound network requests. Together these let you rebuild what an agent did and who it acted for.
Why ordinary application logs miss MCP attacks
An MCP server has two channels into your systems. It runs code, and it sends the agent text, such as tool names, descriptions and prompt templates, that the model treats as instructions. Most logging only covers the first channel, if that. The Deadbugz payload arrived through the second: new instructions in later tools/list and prompts/get responses, after a counter reached three calls. Nothing at install time looked wrong. Only a log that stores what the server said, and when it changed, would have shown it.
The protocol's own security best practices point the same way in several places. Proxy services that spawn local servers should "log all stdio transport usage for security monitoring". Servers should log scope elevation events "with correlation IDs". Clients should "log suspicious authorization URLs". And the document warns that token passthrough breaks the audit trail, because the server can no longer tell clients apart and downstream logs show the wrong identity.
The events worth logging
| Event | Fields to record | What it catches |
|---|---|---|
| Server launch | Full command and arguments, package version or commit hash, config file it came from, user it runs as | Unpinned launches, servers added by a pull request, a changed command |
| Tool definitions | Hash and full text of each tools/list and prompts/list response, per session, with a timestamp | Descriptions that change after approval or after a few calls |
| Tool call | Tool name, server, arguments (secrets redacted), result size, duration, error | A formatter that suddenly reads files, unusual argument patterns |
| Identity and scopes | Human user, agent session ID, token audience and scopes, correlation ID | Over-broad tokens, token passthrough, calls nobody can attribute |
| Scope elevation | Scope requested, subset granted, which tool triggered it | Privilege creeping up during a session |
| Outbound requests | Destination host, port, bytes sent, which server or tool made it | Quiet exfiltration, calls to metadata addresses like 169.254.169.254 |
| File access outside the project | Path, read or write, process | Reads of ~/.ssh, cloud credential files, shell history |
Log tool definitions, not just tool calls
This is the one most teams skip. Save the full output of tools/list and prompts/list each time a session starts, and again after several calls, then compare hashes. A changed description on a server you already approved should raise an alert and need a person's approval again; that is the recommendation Pillar Security gave MCP client builders after Deadbugz. Storing the full text, not only the hash, matters for the investigation afterwards, because the changed description is the evidence.
Where the logs should live
Not on the same machine as the agent, and not anywhere the agent can write. If an agent can be steered into deleting files, it can be steered into deleting its own log. Ship the events off the host as they happen. A practical pattern: have the MCP client or a small local proxy write one JSON line per event to stdout, and let your existing log shipper collect it, the same way container logs should go to stdout, not files. Network events come more reliably from an egress proxy than from the agent itself, since a compromised process will not report its own exfiltration.
Redact before you store
Tool arguments and results carry exactly the things an attacker wants: tokens, file contents, customer records. Redact known secret patterns before writing, store result sizes instead of full results by default, and keep full payloads only for tools you have marked sensitive, in a store with tighter access. An audit log that leaks credentials becomes the next incident.
How long to keep MCP logs
Keep them at least as long as your other security logs, and long enough to cover the gap between an attack and its public disclosure. Deadbugz pull requests were opened on 10 August and the write-up came out on 12 August; other campaigns surface months later. If your incident response policy already sets a retention period for authentication and endpoint logs, use the same one rather than inventing a shorter one for AI tools.
A minimal setup for a small team
- Inventory every MCP server and pin its version, as in our audit checklist.
- Wrap launches so the exact command, version and user are logged once per session.
- Snapshot tools/list and prompts/list at session start and after the third call, and alert on any hash change.
- Log every tool call with redacted arguments and result size, tagged with the human user and session ID.
- Route agent traffic through an allow-listed egress proxy and keep its logs off the host.
The same principle shapes how we build internal assistants: an assistant should not hold more power than the person it works for, and every answer should be traceable to a source. We covered the access side in scoping an internal AI assistant to the person asking. In FanMind, our document assistant, outbound calls go through one allow-listed tunnel and confidential documents are excluded from AI indexing by default, which keeps both the attack surface and the log volume small.
Logging tells you what happened. Scoping agent permissions limits how much can happen; see AgentCorruption and AI agent permissions.
Frequently asked questions
What should I log for MCP servers?
Log each server launch with its exact command, version and user, the full text and hash of every tools/list and prompts/list response, every tool call with redacted arguments and result size, the human user, session ID and token scopes behind each call, scope elevation events, and outbound network requests made by the server or agent.
Why log MCP tool definitions?
Because tool names, descriptions and prompt templates are instructions the model follows, and they can change after you approve a server. The Deadbugz server only changed what it sent after three tool calls. Comparing snapshots of tools/list and prompts/list over a session is the only way to see that change and prove what the agent was told.
Does the MCP specification require audit logging?
It does not define one audit log format, but its security best practices recommend logging in several places: proxies should log all stdio transport usage for security monitoring, servers should log scope elevation events with correlation IDs, and clients should log suspicious authorization URLs. It also warns that token passthrough damages the audit trail.
Where should MCP audit logs be stored?
Off the host where the agent runs and out of the agent's write access, so a steered agent cannot delete them. Emit events as JSON lines to stdout and ship them with your existing log pipeline, and take network events from an egress proxy, because a compromised process will not reliably report its own outbound traffic.
