If an agent calls a tool in production, a security team should be able to answer a simple question: why was that call allowed?

Most systems can eventually reconstruct something from logs. That is useful, but it is not the same as proving that a specific policy authorized a specific tool call at the time it happened.

Logs are after-the-fact evidence

Logs usually tell you that something happened:

  • A request arrived.
  • A tool was called.
  • A response was returned.
  • An error occurred.

After an incident, teams search across logs, traces, tickets, alerts, and application state to rebuild the story. That is forensic reconstruction. It can work, but it is slow and incomplete when agents act across multiple tools.

Receipts are authorization evidence

A receipt is created as part of the authorization path. It records the fact that a policy decision allowed or denied a tool call before the tool action completed.

A useful MCP tool-call receipt should bind:

  • User or workload identity.
  • Agent or session identity.
  • MCP server identity.
  • Server package, version, or binary identity.
  • Tool name.
  • Tool input class.
  • Target system.
  • Credential class.
  • Policy rule.
  • Allow or deny decision.
  • Timestamp.
  • Result category.

The receipt should be tamper-evident enough that it can support audits, investigations, and customer questions.

The hard case is a valid but unauthorized call

Many failures are not malformed.

The tool call can be perfectly typed. The schema can validate. The MCP server can behave exactly as implemented. The backend request can succeed.

The problem is that the call should not have been allowed for that identity, tool, credential, target, or environment.

That is not a dependency scan problem. It is a runtime policy problem. Installed-tree scanning answers whether the server runtime is acceptable to run. A pre-call policy decision answers whether this specific action is acceptable now.

What should happen before the tool call

Before a sensitive tool executes, the system should check:

  • Who is asking?
  • Which agent or session is acting?
  • Which MCP server will handle the call?
  • Is the server version allowed?
  • Is the tool allowed for this identity?
  • Is the requested action allowed?
  • Is the credential scope acceptable?
  • Is the target resource allowed?
  • Is this environment allowed?

Only then should the action proceed. The receipt is the record of that decision.

What this changes operationally

Without receipts, the question after an incident is:

Can we assemble enough logs to infer what happened?

With receipts, the question becomes:

Which policy allowed this exact call, and what evidence did it use?

That is a better position for security, compliance, and engineering operations.

The takeaway

MCP makes agent actions useful. Receipts make them governable.

Logs are still necessary. They help debug and investigate. But for production agent tool use, logs should not be the only proof. The system should produce evidence at the same moment it decides whether the tool call is allowed.