Work contract layer: should MCP include signed authorization + execution receipts for tool calls? #3215

Context

MCP solves connectivity — agents can call tools across any server, any framework. That's working. But there's a gap between "agent can call a tool" and "someone can verify that the call was authorized, executed correctly, and is reproducible."

I've been hitting this gap in production multi-agent pipelines, and I want to float it here before going further — to see whether the MCP community sees this as something that belongs inside the spec, as a complementary layer, or not at all.

The gap

Today, when an agent calls a tool via MCP, three things are invisible after the fact:

1. Who authorized the call? An agent decided to run a tool, but was that decision within a scoped grant? Did a specific role (human or system) issue an authorization with constraints? Right now, there's no protocol-level answer — only middleware logs.

2. What actually happened during execution? The tool returned a result, but is there a signed record of the exact inputs, outputs, and side effects? If the agent later claims "tests passed," can a third party replay that claim without trusting the agent or its middleware?

3. Is there a causal chain? In multi-step workflows (agent reads repo → applies patch → runs tests → publishes evidence), each step depends on the previous one. If step 3 claims "I tested the patch from step 2," is there a cryptographic link — or just a string reference?

These questions matter in three scenarios I've encountered:

• Regulatory compliance: EU AI Act high-risk systems require "human oversight and traceability." The penalty isn't reputational — it's regulatory action. Audit trails that require trusting the agent's middleware don't satisfy this; you need proof that survives the agent disappearing.
• Multi-agent handoffs: When agent A's output becomes agent B's input, B needs to know what A was authorized to do. Without a protocol-level chain, B just trusts A's claim. In a 5-agent pipeline, that's 5 trust assumptions stacked on each other.
• Incident investigation: "Who authorized this destructive change?" In a system with 40+ sequential tool calls across multiple agents, answering this from logs is hours of manual work. If the authorization was signed at protocol level, it's a single lookup.

What I'm exploring (not proposing as MCP spec — yet)

I've been working on a separate protocol that addresses this gap. The design has three primitives:

1. PolicyDecision (pre-execution authorization)

Before a tool call executes, a signed authorization is issued:

PolicyDecision = {
  work_order_id: string,     // links to the overall task
  role: string,              // who authorized (Manager, Developer, etc.)
  tool: string,              // which tool
  arguments_hash: string,    // JCS-canonicalized args, hashed
  scope: object,             // constraints (quota, expiry, permissions)
  expires_at: timestamp,     // authorization window (e.g., 300s)
  signature: Ed25519sig      // signed by the authorizing role's key
}

The execution node checks the signature, checks the expiry, checks the scope — then executes. If any check fails, the tool call never happens.

2. ExecutionReceipt (post-execution proof)

After the tool runs, a signed receipt is emitted:

ExecutionReceipt = {
  policy_decision_id: string,  // links back to the authorization
  tool: string,
  inputs_hash: string,         // what was actually passed
  outputs_hash: string,        // what came back
  evidence_refs: string[],     // diffs, test reports, benchmarks
  parent_receipt_ids: string[],// causal graph — exact parent set
  quota_consumed: object,
  signature: Ed25519sig        // signed by the execution node
}

The causal link is critical: each receipt references its exact parents. If receipt #5 claims receipt #3 as a parent but #3 doesn't exist or wasn't signed, verification fails at the protocol level. You can't fabricate history.

3. Offline verification (zero-trust replay)

Anyone — a third party, an auditor, a downstream agent — can verify the entire chain with just the bundle of receipts + public keys:

verify(work_order, receipts[], public_keys[]) → {valid: bool, breaks: [step]}

No API calls. No access to the execution node. No trust in any participant. If the chain is internally consistent and all signatures check out, it passes. If not, it tells you exactly where it broke.

Three questions for the MCP community

I'm not suggesting MCP should become a compliance framework. But I want to understand whether there's appetite for lightweight authorization + receipt primitives at the protocol level:

Q1: Does this belong in MCP, or as a layer above it?

Arguments for inside MCP: every tool call would benefit from signed authorization and receipts. Making it part of the spec means it works across all SDKs automatically.

Arguments for outside MCP: MCP's job is connectivity, not accountability. Adding signing + verification to the core spec increases complexity for server implementers who don't need it. A complementary layer (like OAuth sits above HTTP) might be cleaner.

I lean toward "outside" — but I want to hear from people who've implemented MCP servers.

Q2: Is the PolicyDecision → ExecutionReceipt model the right abstraction?

The alternative I considered was a single "WorkReceipt" that combines authorization + execution. I split them because:

• Authorization and execution happen at different times (and potentially by different roles)
• You might want to inspect authorizations before execution (deny early)
• In multi-agent flows, one PolicyDecision might authorize multiple receipts

But maybe that's over-engineered. If you're building an MCP server, would you want to emit both, or just one combined record?

Q3: What about tools with side effects?

repo_read is easy — the output is deterministic. But apply_patch mutates state, and run_tests has environmental dependencies. The receipt design above captures inputs_hash and outputs_hash, but for side-effecting tools, "outputs" is ambiguous (is it the patch result? the repo state? the test report?).

Has anyone thought about how MCP should model side effects in a way that's verifiable after the fact? This feels like the hardest unsolved part.

What I'm NOT proposing

• Not suggesting MCP should require Ed25519 or any specific crypto — that's an implementation detail
• Not proposing a governance model for who holds which keys — that's deployment-specific
• Not asking MCP to solve the "completeness" problem (proving no receipts were deleted) — that's a harder problem I'm still working on, likely requiring a Merkle root or transparency log

I'm asking whether the shape of these primitives — signed pre-authorization, signed post-execution receipt, causal chain — resonates as something MCP could eventually benefit from, either by adoption or by incorporating into the spec.

Background

I've been developing this as a standalone protocol (Ed25519 signatures, RFC 8785 JCS canonicalization, offline replay verification). It's working end-to-end on two real open-source bug fixes (Rich #4196, Dify #33013), with ~2,300 tests. But I'm posting here because the question of "inside MCP vs. outside MCP" is one I can't answer alone — it depends on how the community thinks about the protocol's scope.

Would love input from maintainers, SDK implementers, and anyone deploying MCP servers in production or regulated environments.