Signed MCP Receipts Create Evidence After the Call. They Do Not Make the Call Safe

A useful new MCP project makes an important correction to the current trust story.

Most tool-call logs are still self-reported.
The agent says it called a tool.
The server says it returned a result.
Maybe the proxy wrote a trace.
But unless another layer can verify what was sent, what came back, and in what order the calls happened, a lot of that record is still just a claim.

That is why signed MCP receipts matter.

If a proxy issues an Ed25519-signed, hash-chained receipt for each tool call, you get something much stronger than ordinary logging.
You get a piece of evidence that can survive later review without requiring everyone to keep trusting the runtime that generated it.

That is genuinely useful.

But it solves a narrower problem than some people will be tempted to claim.

Signed receipts improve evidence after execution. They do not solve authority before execution.

That distinction matters because a perfectly documented bad tool call is still a bad tool call.

1. Why ordinary MCP logs are weak evidence

Most current MCP traces answer only one question well:

What does this system say happened?

That helps with debugging.
It does not always help with proof.

In shared, regulated, or unattended agent systems, operators often need more than a debug trail:

• what exactly did the caller send?
• which tool was invoked?
• what result came back?
• what was the order of events?
• can another party verify the record later?
• can you distinguish a reconstructed narrative from a tamper-evident execution record?

Ordinary logs are often too soft for that.
They are mutable, fragmented, or dependent on trusting the same runtime that is now under review.

That weakness gets sharper as tool calls start carrying real consequences.
Once an agent can file a ticket, mutate a repo, approve an action, send a message, touch customer data, or spend money, “the logs say it happened” stops feeling like enough.

2. What signed receipts improve

A signed receipt layer does something valuable.
It turns a tool call into a verifiable execution artifact.

That is useful because it can preserve things like:

• caller identity or proxy session identity
• tool name
• request arguments or their digest
• response body or result hash
• time ordering across calls
• tamper evidence through chaining

Now the system can support stronger questions:

• did this call actually pass through the audited path?
• was this the argument set that was really sent?
• was this the response that came back?
• was this action before or after another action?
• can another reviewer validate the record without trusting the runtime's current story?

That makes receipts attractive for:

• incident review
• forensic reconstruction
• compliance evidence
• dispute resolution
• multi-agent accountability
• postmortem analysis when tool side effects matter

Put simply, signed receipts can close the gap between logging for operations and evidence for review.

That is a real improvement.

3. The trap: confusing evidence with permission

This is where the line needs to stay sharp.

A receipt can prove that a call happened.
It cannot prove that the call should have been allowed.

That is not a bug in receipts.
It is just the wrong layer.

Receipts do not answer questions like:

• should this caller have seen this tool in discovery at all?
• was the caller in the right trust class for this action?
• did auth establish identity only, or actual authority for this tool?
• was the side-effect class acceptable for the current workflow?
• should the runtime have blocked this call because the capability boundary was too broad?
• was the downstream backend credential mapped correctly to the caller's intended authority?

Those are admission-control and policy questions.
They exist before the first byte of the tool call is ever sent.

A signed receipt recorded after a bad authorization decision does not repair the authorization decision.
It just makes the mistake easier to prove later.

That is still useful, but it is not safety.

4. Authority failures happen before the receipt layer can help

This matters most in MCP because the dangerous failures are often upstream of execution evidence.

The biggest problems usually look more like this:

• the runtime exposed too many tools to the wrong caller
• a write-capable surface was presented as if it were operationally equivalent to a read-only helper
• server auth was treated as if it implied per-tool authorization
• a gateway flattened read, write, execute, and egress into one trust blob
• backend credentials were shared too broadly behind an otherwise clean front door
• a local workflow was silently promoted into a shared unattended workflow without changing the control model

In all of those cases, signed receipts are helpful for review.
They are not the thing that prevents the incident.

The incident is prevented by a better boundary before execution:

• scoped discovery
• trust-class-aware exposure
• principal-to-tool mapping
• clear side-effect classes
• bounded capability surfaces
• pre-request governors
• typed denials when a caller crosses a boundary

So the right mental model is not “receipts make MCP safe.”
It is:

bounded authority makes the call safer, and signed receipts make the call more accountable afterward.

5. The stronger architecture is three layers, not one

The cleanest operator model has three separate layers.

Layer 1: Pre-call control

Before execution, the runtime needs to answer:

• what tools should this caller see?
• what trust class does this workflow belong to?
• what authority is actually being delegated?
• what write or side-effect boundaries apply?
• what budget, policy, or escalation rules apply before execution?

This is where the safety story lives.

Layer 2: Execution evidence

Once the call is allowed, the runtime should make the execution trail verifiable.
That is where signed receipts are strongest.

This is where you want:

• signed records
• stable ordering
• caller binding
• tool binding
• argument / result integrity
• effect metadata when available

This is where the accountability story gets stronger.

Layer 3: Post-call audit and review

After execution, operators need a way to inspect what happened and decide what it means.
That is where verification, incident handling, dispute resolution, and compliance review sit.

This is where the governance story becomes usable.

The mistake is collapsing all three layers into one and pretending that a strong audit artifact replaces weak admission control.
It does not.

6. Why this distinction matters for MCP specifically

MCP systems are making this more urgent for one reason.

The same runtime often carries multiple authority classes side by side.
A caller might interact with:

• a read-only search helper
• a repo-writing tool
• a browser automation surface
• a support-action tool
• a cloud admin control
• a finance or ticketing workflow

If those surfaces are all flattened into one generic “tool call” model, then even perfect receipts can become misleading.
They tell you what happened, but not whether the visible capability boundary made sense for that caller in the first place.

That is why receipts become much more valuable when paired with richer context:

• trust class
• side-effect class
• caller identity
• policy decision
• backend principal mapping
• environment or tenant boundary

The best evidence trail is not just a signed blob.
It is a signed execution record that can be joined back to the policy and trust context that made the call admissible.

7. What a better MCP auditability standard should include

If signed receipts become part of the MCP trust stack, the useful question is not just “does this server emit receipts?”

It is also:

• are receipts bound to the actual caller, or only to a proxy session?
• do they preserve enough detail to support forensic review?
• do they distinguish read-only from write or execute effects?
• can they be joined to policy decisions and scope boundaries?
• do they survive multi-tenant and multi-agent operation cleanly?
• can an operator verify not just the call, but the authority context around the call?

That is the difference between receipts as a cool debugging feature and receipts as part of a real trust architecture.

8. The right conclusion

Signed MCP receipts are a meaningful improvement.
They close a real evidence gap.
They make tool-call history more verifiable.
They strengthen post-call accountability.

That matters.

But the useful claim is narrower than “receipts solve MCP trust.”

The better claim is:

receipts make it easier to prove what happened after the runtime decided to allow the call.

That is important.
It is just not the same thing as deciding whether the runtime should have exposed or admitted the call in the first place.

So the strongest MCP systems should aim for both:

• bounded authority before execution
• verifiable evidence after execution

Because a signed receipt is not permission.
It is proof.

And proof matters most when it is paired with a control plane that was careful about authority before the call ever ran.