Proposal: Agent Identity and Delegation for MCP Tool Calls

[dreynow]

Problem

MCP has a robust authorization spec for the human-to-server relationship: OAuth 2.1 handles "which human authorized this client to access this server." This works well for the HTTP transport.

But there is no standard mechanism for agent-to-agent authorization in tool calls. When Agent A delegates a task to Agent B, and Agent B calls an MCP tool, the server has no way to answer:

• Who is this agent? (not the human - the specific agent instance)
• What is it authorized to do? (which tools, what cost limits, what resources)
• Who granted that authority? (the delegation chain back to a human or root)

This gap is especially acute for:

1. stdio transport - The auth spec explicitly says stdio should "retrieve credentials from the environment." There is no per-call authorization.
2. Multi-agent systems - When agents delegate to sub-agents (CrewAI crews, LangGraph subgraphs, AutoGen teams), the sub-agent's authority should be verifiable and narrower than its parent's.
3. Tool approval propagation - Discussion #1203 describes nested agents needing approval from the original user. A delegation chain solves this - the proof carries the approval.

Today, MCP servers must fall back to API keys, environment variables, or custom headers. None of these support delegation, attenuation, or cryptographic verification.

Proposed Extension

Add an optional auth field to params._meta on tools/call requests:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search_contacts",
    "arguments": {
      "query": "Alice Smith"
    },
    "_meta": {
      "auth": {
        "type": "delegation-proof",
        "version": "1",
        "invoker_did": "did:agent:4a1b2c3d...",
        "invoker_public_key": "a1b2c3d4e5f6...",
        "proof": "<base64-encoded invocation proof>"
      }
    }
  }
}

Design principles:

• Optional - Clients may omit _meta.auth. Servers choose whether to require, accept, or ignore it.
• Transport-agnostic - Works on stdio, HTTP, and SSE because the proof travels with the message.
• Self-contained - The proof includes the full delegation chain. No external lookups needed. The server verifies using only the data in the proof and its own root public key.
• Complementary to OAuth - OAuth handles human-to-server auth. This handles agent-to-agent delegation. They work together.
• Backward compatible - _meta is already part of the spec. Servers that don't understand auth ignore it. Clients that don't support it send calls without it.

How It Works

Setup (one-time)

A human or organization creates a root authority (Ed25519 keypair) and delegates to agents with constraints:

Root Authority (Human)
  |
  +-- delegates to Manager Agent: [search, resolve, merge], expires 2026-04-01
      |
      +-- delegates to Worker Agent: [search, resolve], max_cost: $5
          |
          +-- calls MCP tool with proof

Each delegation is signed by the issuer. Caveats (action scope, expiry, cost limits, resource patterns) accumulate and can only narrow - never widen.

Per-call flow

1. Agent creates an invocation proof containing: the action, the arguments, and the delegation chain
2. Agent signs the proof with its Ed25519 key
3. Client attaches the proof to params._meta.auth
4. Server extracts the proof, verifies every signature in the chain back to the root, checks all caveats, and executes or rejects

Server verification (5 lines)

TypeScript:

import { verifyMcpCall, McpProof } from "@kanoniv/agent-auth";

const { proof, cleanArgs } = McpProof.extract(args);
if (proof) {
  const result = verifyMcpCall(proof, rootIdentity);
  // result.invoker_did, result.chain, result.depth
}

Python:

from kanoniv_agent_auth import verify_mcp_call, extract_mcp_proof

proof, clean_args = extract_mcp_proof(args_json)
if proof:
    invoker_did, root_did, chain, depth = verify_mcp_call(proof, root_identity)

Rust:

use kanoniv_agent_auth::mcp::{McpProof, verify_mcp_call};

let (proof, clean_args) = McpProof::extract(&args);
if let Some(proof) = proof {
    let result = verify_mcp_call(&proof, &root_identity)?;
}

Caveat Types

Delegation proofs support constraints that are checked at verification time:

Caveat	Example	Description
action_scope	["search", "resolve"]	Restrict to specific tool names
expires_at	"2026-04-01T00:00:00Z"	Time-limited delegation
max_cost	5.0	Cost ceiling per invocation
resource	"entity:customer:*"	Glob pattern on resource
context	{"session_id": "abc"}	Must match specific context
custom	{"org": "acme"}	Arbitrary key/value

Caveats accumulate through the chain. A sub-agent inherits all parent caveats plus any additional restrictions. This means delegation can only narrow authority, never widen it.

Security Properties

• Cryptographic identity - Agents have Ed25519 keypairs and did:agent: identifiers. No central registry required.
• Tamper-proof - Caveats are extracted from signed payloads, not outer fields. Modifying caveats after signing breaks verification.
• Chain depth limit - Maximum 32 delegations to prevent DoS via deeply nested chains.
• Revocation hook - Verification accepts a callback is_revoked(delegation_hash) -> bool. Implementations can plug in any revocation backend.
• No trust in intermediaries - Every signature in the chain is independently verified. A compromised intermediate agent cannot forge its parent's authority.
• Fail-closed - Missing required fields (e.g., cost when max_cost caveat is present) result in rejection, not silent bypass.

What This Does NOT Do

• Replace OAuth - OAuth handles the human-to-server relationship. This handles agent-to-agent delegation. Use both.
• Mandate a specific DID method - The reference implementation uses did:agent: but the proof format is DID-method-agnostic.
• Require server changes to MCP core - This uses the existing _meta field. No protocol-level changes needed.
• Force servers to verify - Auth is optional. Servers choose their enforcement level (required, optional, or disabled).

Reference Implementation

An MIT-licensed library implementing this proposal is available in three languages:

• Rust: kanoniv-agent-auth (v0.2.0, 137 tests)
• TypeScript: @kanoniv/agent-auth (v0.2.0, 80 tests)
• Python: kanoniv-agent-auth (v0.2.0, 48 tests)

All three produce byte-identical proofs and can cross-verify (sign in Python, verify in Rust).

Source: github.com/kanoniv/agent-auth

Related Discussions

• #64 - Authentication - Original auth discussion; mentions DIDs and cryptographic proofs
• #804 - Gateway-Based Authorization Model - JWT assertions for identity propagation (18 upvotes)
• #1203 - Tool Approval Propagation - Nested agent approval chains (unanswered)
• #234 - Multi-user Authorization - Multi-tenant auth patterns
• #1228 - Extra fixed parameters - Passing client context to servers without LLM involvement

[dreynow]

@pcarleton @pja-ant Would love your thoughts on this, it sits at the intersection of auth and the agents working group. Happy to answer any questions or iterate on the design.

[SonAIengine]

we've hacked around this before with manual allowlists, but it breaks down once you get deep nesting — you lose track of what each agent in the chain can actually do. revocation's the killer though: if a parent agent goes rogue mid-request, how do you unwind that delegation?

[dreynow]

Good questions, both are exactly what motivated the design.

On deep nesting: Each delegation in the chain can only attenuate (narrow) the parent's permissions, never widen them. So if Agent A delegates ["resolve", "merge"] to Agent B, and B delegates to C, C can get at most ["resolve", "merge"], but B could narrow it to just ["resolve"]. Verification walks the full chain and intersects caveats at each step, so you always know the effective permissions at any depth without tracking them manually. The chain itself is the audit trail.

A (root) -> B (resolve, merge, max $100) -> C (resolve only, max $25)

On mid-request revocation: Revocation is checked at verification time, not delegation time. Each proof includes the full chain, and verify_mcp_call() checks every link against a revocation list before returning a verdict. If you revoke B's delegation while C is mid-request, C's next tool call fails immediately, no unwinding needed because no action executes without a fresh verification pass.

The implementation is live across Rust, TypeScript, and Python if you want to try it: https://github.com/kanoniv/agent-auth

[tomjwxf]

Great proposal. Agent identity and delegation is one of the most critical missing pieces in MCP right now.

I've been working on a production implementation of exactly this. ScopeBlind Passport provides a portable, signed agent identity that works today:

• Identity: Each agent gets an Ed25519 keypair + a signed manifest (name, capabilities, trust tier)
• Delegation: The Passport supports DPoP proof-of-possession (RFC 9449), so an agent can prove it owns its key on every request — enabling delegation chains where Agent A can prove it was authorized by Operator B
• Verification: Any server can verify the Passport signature offline — no central auth, no OIDC dependency

For the "delegation" part specifically: we use a binding receipt that links the agent's Ed25519 identity key to a P-256 DPoP key. The operator signs this binding, creating a verifiable chain: Operator → Agent Identity → Per-Request DPoP Proof.

The enforcement layer is protect-mcp — a stdio proxy that evaluates the agent's Passport at session start and assigns tool-level access based on the trust tier. Every tool call produces a signed decision receipt.

Would love to align on the identity schema if there's interest in standardizing this at the spec level.

[ayshsandu]

This proposal raises an important gap worth highlighting. Even in human-in-the-loop scenarios, today's agent or MCP Host is largely identity-less. While the MCP client can be clearly identified in authorization flows, the host or agent running above it remains mostly invisible. This is a real problem since a single host can orchestrate multiple MCP clients connecting to different tools, yet none of that host-level context surfaces in the authorization layer.

This is something we've been thinking about for a while. We proposed an OAuth extension to address it through dynamically delegated access:
📄 https://www.ietf.org/archive/id/draft-oauth-ai-agents-on-behalf-of-user-00.html

There's also a session walking through how agent identity can be layered on top of MCP authorization, if useful for context:
🎥 https://www.youtube.com/watch?v=beEqa8_fNUQ

When an agent inside an MCP host invokes a tool requiring elevated authority, the MCP server challenges the host (HTTP 401/403 with required_scope). The host initiates a PAR flow carrying:

requested_actor — the stable agent identifier (not the host's client_id)
actor_token — cryptographic proof of the agent's identity, validated upfront at the AS a real-time consent screen showing the user which agent is asking for which tool at which scope

The issued token carries sub (user), azp (client), and act.sub (agent), giving MCP servers a full, auditable delegation chain and enabling actor-aware policy.

Would be great to discuss how this host-level identity gap gets addressed, whether through extensions like the above or as a first-class consideration in the spec.

[aleksandarperak33-hub]

Strong thread — agent identity + delegation is one of the most-discussed primitives in the MCP community, and ship-ready implementations are rare. I've been building TokenRip (tokenrip.com) as a collaboration layer with this as a first-class concern: contacts bind human-readable labels to cryptographically-verified agent IDs, which makes delegation chains auditable.

A few implementation notes from what we've shipped:

1. Delegation tokens need scope + expiration. A raw "delegate full capability" primitive is too coarse for any production use case. TokenRip delegations carry allowed_intents and expires_at.

2. Identity verification is strictly more useful when paired with message typing. A verified identity saying {intent: "propose", payload: ...} is far more tractable to audit than the same identity saying free-form prose.

3. Kill-switch UX matters. When an agent misbehaves, operators need a one-line revocation that propagates to every thread the agent is in. TokenRip surfaces this as a thread-level "close" with a resolution artifact.

Happy to contribute the spec we use if helpful for the MCP working group.

[itisparas]

This thread maps closely to a protocol draft I have been working on: the Agent Identity Protocol using the did:aip DID method.

Naming note up front: I saw #2122 also used "AIP" for a JSON-RPC sidecar / policy manifest proposal. The mechanism I am referring to here is different: a DID- and token-based agent identity layer intended to compose with MCP authorization, not a client-side policy proxy.

The gap described in this discussion seems to have three separable parts:

1. Agent identity — which specific agent is calling this tool?
2. Delegation provenance — which human or organizational principal authorized it, through which parent agents, and under what narrowing constraints?
3. OAuth bridge — how does an MCP server that already speaks OAuth receive an access token that preserves agent and principal context without inventing a new MCP auth flow?

The current AIP draft tries to address those as a substrate rather than as a replacement for MCP OAuth:

• Agents have stable did:aip:<namespace>:<id> identifiers derived from their public key material.
• A Credential Token is a JWT signed by the agent. It carries sub / iss, aip_scope, aip_version, and an aip_chain.
• aip_chain is an ordered chain of Principal Tokens from the root human or organization principal to the acting agent. Each delegation step can only narrow authority.
• Relying parties validate the token deterministically against registry state: DID resolution, key material, scope-to-manifest checks, revocation, delegation depth, DPoP for sensitive scopes, and optional approval-step binding.
• For MCP/OAuth integration, AIP defines an RFC 8693 token exchange path: the agent presents an AIP Credential Token as subject_token, the target MCP server is the RFC 8707 resource, requested scopes use urn:aip:scope:*, and the resulting RFC 9068 access token is DPoP-bound with sub = agent AID and act.sub = root principal DID.

That lets MCP keep the current OAuth model for client/server authorization while adding a composable agent identity layer:

Agent Credential Token
  -> proves did:aip agent identity and delegation chain
  -> exchanged via RFC 8693 for MCP-server-specific access token
  -> MCP server receives normal OAuth-style JWT with agent + principal context

[pinialt]

Just submitted SEP-2672 for per-call passkey-verified approval on MCP tool calls: #2672

This proposal covers agent identity/delegation; mine covers “did the human approve this specific call with these specific arguments?” Both live in the same tools/call evidence space and compose with OAuth. Worth reviewers thinking about the layering.