Proposal: Optional authority and evidence_anchor fields for MCP request/response — verifiable agent authorization #2724

matt-dean-git · 2026-05-14T23:58:27Z

matt-dean-git
May 14, 2026

Motivation

MCP gives agents access to tools and data through servers. Today, every MCP server has to answer the same question from scratch: was this agent authorized to make this call, under whose policy, with what scope? The current model is "trust the transport-layer auth" — typically an API key or OAuth token. That proves possession; it doesn't prove authorization under a specific delegated policy with a verifiable artifact.

For the agent economy to extend beyond demos into regulated, enterprise, and financial domains, MCP needs an authority and accountability extension that:

Lets a human or platform principal delegate scoped capability to an agent — with budget, expiry, route allow-list, and policy version.
Lets an MCP server verify that delegation independently — without trusting the client at runtime.
Produces a signed, externally verifiable artifact of every allow/deny decision that any third party can later audit offline.
Is rail-neutral — works whether the downstream action is a tool call, a payment on x402/L402/Stripe, an upstream API request, or a delegation to another agent.

Proposal sketch

Add two optional fields to MCP request and response envelopes:

// Request
{
  "method": "tools/call",
  "params": { /* existing */ },
  "authority": {
    "profile": "satgate.authority.v1",      // open profile id
    "capability": "<opaque capability ref or inline capability>",
    "issuer": "<https URL>",
    "issuer_kid": "<key id in issuer JWKS>"
  }
}

// Response
{
  "result": { /* existing */ },
  "evidence_anchor": {
    "profile": "satgate.evidence_pack.v1",
    "evidence_url": "https://<issuer>/v1/evidence/<opaque_id>",
    "evidence_pack_hash": "sha256:<...>",
    "receipt_hash": "sha256:<...>"
  }
}

Both fields are optional. MCP servers that don't care about authority ignore them. Servers that want to extend higher trust, lower rate limiting, or differentiated pricing to anchored agents can require them on specific routes.

Reference profile

We propose satgate.authority.v1 and satgate.evidence_pack.v1 as the first published profiles, with:

Ed25519 signatures over RFC8785-canonicalized payloads
Public JWKS discovery at <issuer>/.well-known/jwks.json
Receipt schema at a public $id URL
Open verifier, currently Python with TypeScript planned, dual-licensed Apache-2.0/MIT: https://github.com/SatGate-io/evidence-pack-verifier

The profiles are open and not SatGate-specific. Other authority issuers can publish their own profiles under the same envelope shape.

What this enables

MCP servers can publicly grant preferential terms to anchored agents (higher rate limits, lower fraud holds, gated higher-trust scopes).
Enterprises can deploy agents into MCP ecosystems with cryptographic proof of authorization for audit.
Payment-bearing MCP flows (x402, L402, Stripe Agent Toolkit) get a recourse trail that survives outside the rail's own logs.
MCP marketplaces and registries can score / filter / surface anchored agents.

What this is not

Not a new auth scheme replacing OAuth / API keys / transport auth.
Not mandatory.
Not SatGate-specific — the spec is profile-keyed so any authority issuer can participate.
Not a payment standard — it's about authority before value moves, regardless of which rail moves it.

Prior art / inspiration

W3C Verifiable Credentials (richer model, much heavier; we want JSON-native MCP-shaped)
OAuth 2.0 Rich Authorization Requests (RAR) — scope expression, but no signed decision artifact
DKIM (authenticity primitive) — closest in spirit; small, optional, became infrastructure
3-D Secure 2 (recourse trail in card payments) — analog for what this provides for agent flows

Asks for the working group

Is the envelope shape acceptable? Open to renaming authority / evidence_anchor.
Do we want a registry of profile IDs (like JWS alg values) maintained by MCP?
Should the optional fields live at the protocol layer, transport layer, or both?
Would the working group welcome a community reference verifier? SatGate is happy to ship and maintain Python + TypeScript implementations, dual-licensed Apache-2.0/MIT, under whatever repo/name the MCP community prefers.

We'll follow up with a formal spec PR once the working group signals shape.

yudin-s · 2026-05-15T07:19:55Z

yudin-s
May 15, 2026

I like the direction, but I would keep three concepts separate in the envelope:

transport authentication: who opened the connection
delegated authority: what this agent is allowed to attempt
per-call policy decision/evidence: why this specific call was allowed or denied

The proposed authority field seems strongest as a reference to a delegation artifact, not as the policy decision itself. The server should still make a local decision for the concrete call:

capability says: agent may call tool X with budget Y until time Z
request says: call tool X with arguments A
server policy says: allowed / denied / allowed-with-limits
evidence_anchor records: decision + policy version + hashes

That distinction matters because a valid delegation can still fail a per-call policy check. For example: expired budget, disallowed route, risky argument shape, tenant mismatch, or local incident-mode policy.

I would also avoid putting too much raw context into evidence_anchor. A small signed receipt with hashes is safer than a full prompt/tool payload:

{
  "decision": "allow",
  "policy_version": "2026-05-15",
  "capability_hash": "sha256:...",
  "request_hash": "sha256:...",
  "result_hash": "sha256:..."
}

So my vote would be: optional protocol-layer fields are useful, but make the profile define the delegation artifact and evidence receipt separately. That keeps MCP transport auth, agent delegation, and auditability from becoming one overloaded field.

0 replies

nullcb · 2026-06-06T11:54:04Z

nullcb
Jun 6, 2026

+1 to a first-class evidence_anchor, and to @yudin-s's three-way separation (transport auth / delegated authority / per-call decision+evidence) — collapsing those is where most designs go wrong.

Two suggestions on evidence_anchor specifically, so it's verifiable by a party that trusts neither the client nor the server:

Define it to reference a canonical decision record (a content-addressed digest), not a vendor URL or log endpoint — otherwise "externally verifiable" still reduces to trusting whoever hosts the endpoint. Pin the canonicalization (RFC 8785 / JCS + SHA-256) in the spec so server, auditor, and regulator all recompute the same hash independently.
Keep the anchor (proof the record existed at time T) separate from the signature (who issued it): a signature proves authorship; a public timestamp anchor (e.g. OpenTimestamps) proves existence-in-time without trusting the issuer's key. So evidence_anchor is strongest as a reference to {record_digest, anchor_proof}.
Disclosure: I maintain Determs, an open spec doing exactly this shape (profile-agnostic record, JCS+SHA-256, public-infra anchoring) — happy to align the evidence_anchor field with it as a concrete reference. https://github.com/Determs-com/determs

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Proposal: Optional authority and evidence_anchor fields for MCP request/response — verifiable agent authorization #2724

Uh oh!

{{title}}

Uh oh!

Replies: 2 comments

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Proposal: Optional authority and evidence_anchor fields for MCP request/response — verifiable agent authorization #2724

Uh oh!

matt-dean-git May 14, 2026

Motivation

Proposal sketch

Reference profile

What this enables

What this is not

Prior art / inspiration

Asks for the working group

Replies: 2 comments

Uh oh!

yudin-s May 15, 2026

Uh oh!

nullcb Jun 6, 2026

matt-dean-git
May 14, 2026

yudin-s
May 15, 2026

nullcb
Jun 6, 2026