An agent connected to an MCP gateway just ran a delete against your production database at 2am. The MCP server logged that it called a tool named run_sql. It did not log which row was deleted, which database user ran it, or whether anyone approved it. That gap is the whole problem, and it is why your audit trail needs to come from somewhere the MCP server does not control.
This is the operational take, not the theory. An MCP gateway exposes tools to a model. Those tools reach databases, clusters, and internal services. The question for anyone responsible for the audit trail is simple: when the agent acts, what survives, and can you trust who wrote it.
Why the MCP server's own logs are not an audit trail
A process that can take an action should not be the only thing that records the action. The MCP server runs the tool calls, formats them, and decides what to write to its own log. If it is compromised, misconfigured, or just optimistic about what counts as an event, the record bends with it. You end up with a log that says a tool was called, not a record of what hit the infrastructure.
An audit trail has to answer three questions after the fact: who connected, what command executed, and what data came back. Tool-call telemetry from inside the MCP layer answers none of these at the level an auditor or an incident responder needs. The model said query the orders table. The actual statement, the bound database identity, and the rows returned live one layer down, on the connection.
Record at the connection, outside the server
The reliable place to capture an audit trail is the point where the tool call becomes a real command on real infrastructure. That boundary sits below the MCP server and the model. hoop.dev is an identity-aware proxy that sits there. Every query and command an agent issues through it passes at the wire-protocol level, where hoop.dev records the session command by command, tied to the authenticated identity that opened it.
That gives you a record the MCP server cannot edit, because it is captured by a different process on the connection itself. The agent does not handle the target credential and cannot reconfigure the recorder. Practically, the audit trail you keep stops being the agent called a tool and becomes this identity ran this exact statement against this database at this time, and here is the result that was returned.
What to capture for each agent action
- The authenticated identity behind the session, not just the tool name.
- The exact command or query that reached the infrastructure.
- Approval status when the action was routed for human review.
- What data was returned, with sensitive fields masked inline before they left the boundary.
Notice that this is one integrated record, not four logs you stitch together later. The point of putting the gateway on the connection is that attribution, the command, the approval, and the masking all happen in the same place, so the audit trail is coherent by construction. When you go to assemble evidence for an audit, you are reading one stream, not correlating a tool log against a database log against an approvals spreadsheet and hoping the timestamps line up.
It also means the record does not depend on the MCP server staying honest. If someone swaps the MCP server, points the agent at a different gateway, or the server stops emitting telemetry, the connection-level record keeps capturing what reached the infrastructure. The recorder and the actor are different processes, so one failing or lying does not erase the other. That separation is the property that turns a log into an audit trail you can actually defend.
The operational difference
One model logs that a tool fired. The other records what the command did and who is accountable for it. When a regulator or an on-call engineer asks who ran this and what did it touch, only the second answer holds up. An MCP gateway makes agent access fast. Keeping the audit trail outside the MCP server is what keeps that access accountable.
The same record does double duty. During an incident it is the timeline you replay to scope what an agent reached. During an audit it is the per-identity evidence of who accessed which system and whether risky actions were approved. You are not building two systems, you are reading the one continuous record the connection produced. hoop.dev is open source, so you can read exactly how the recording works rather than trust a black box, and the model behind it is laid out in the getting-started docs.
FAQ
Does the MCP server already provide an audit trail?
It provides tool-call telemetry, which is not the same thing. It does not reliably capture the executed command, the bound identity on the target, or the data returned, and it reports on itself. An audit trail captured on the connection by a separate process does.
Where should the audit trail for agent activity live?
On the infrastructure connection, outside the process that issues the actions. That is the layer that sees the real command and the authenticated identity, and it cannot be reconfigured by the agent it is recording.
How does hoop.dev fit with an MCP gateway?
hoop.dev governs the infrastructure connections the MCP tools use. It records at the command level, scopes access just in time, and masks sensitive data inline, without inspecting the model's prompt or output. See how hoop.dev approaches runtime access governance.
Read the code and run it against your own connections: the hoop.dev open-source repository on GitHub has the gateway and agent you would deploy to put a real audit trail under your MCP tools.
