PaperlayerView exact revision on arXiv

Source-linked AI summary

AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A

Sunil Prakash

arXiv:2603.24775v1cs.CRcs.AI

TL;DR

AI agents use MCP and A2A without jointly verifiable identity and delegation, leaving authority chains and outcomes difficult to authenticate and audit. The paper introduces IBCTs within AIP, combining identity, attenuated authorization, and provenance in compact JWT and chained Biscuit formats. Across deployment and adversarial evaluations, AIP reports low overhead and 100% rejection of 600 attack attempts, while acknowledging that completion claims are self-reported by default and production deployment remains limited.

  • Problem

    MCP and A2A enable tool invocation and agent collaboration but do not verify agent identity, delegation authority, scope, or provenance.

  • Method

    AIP introduces IBCTs, append-only tokens that combine identity, attenuated authorization, and provenance in compact JWT and chained Biscuit formats.

  • Results

    100% of 600 adversarial attempts were rejected, while AIP added 2.35 ms, or 0.086% of total latency, in a Gemini 2.5 Flash deployment.

  • Takeaways & Limitations

    AIP’s chained delegation model uniquely detects delegation-depth violations and empty-context audit evasion that plain JWT deployments miss.

  • Takeaways & Limitations

    Completion blocks are self-reported by default, and the evaluation did not include production multi-agent traffic, cross-datacenter networking, or sustained load.

Abstract

from arXiv · show

AI agents increasingly call tools via the Model Context Protocol (MCP) and delegate to other agents via Agent-to-Agent (A2A), yet neither protocol verifies agent identity. A scan of approximately 2,000 MCP servers found all lacked authentication. In our survey, we did not identify a prior implemented protocol that jointly combines public-key verifiable delegation, holder-side attenuation, expressive chained policy, transport bindings across MCP/A2A/HTTP, and provenance-oriented completion records. We introduce Invocation-Bound Capability Tokens (IBCTs), a primitive that fuses identity, attenuated authorization, and provenance binding into a single append-only token chain. IBCTs operate in two wire formats: compact mode (a signed JWT for single-hop cases) and chained mode (a Biscuit token with Datalog policies for multi-hop delegation). We provide reference implementations in Python and Rust with full cross-language interoperability. Compact mode verification takes 0.049ms (Rust) and 0.189ms (Python), with 0.22ms overhead over no-auth in real MCP-over-HTTP deployment. In a real multi-agent deployment with Gemini 2.5 Flash, AIP adds 2.35ms of overhead (0.086% of total end-to-end latency). Adversarial evaluation across 600 attack attempts shows 100% rejection rate, with two attack categories (delegation depth violation and audit evasion through empty context) uniquely caught by AIP's chained delegation model that neither unsigned nor plain JWT deployments detect.

1 Introduction

MCP and A2A enable tool use and agent collaboration but do not verify agent identity, delegation authority, scope, or audit provenance. AIP addresses this gap with IBCTs and evaluates them through interoperable implementations and security and performance measurements.

  • 1 Introduction: MCP and A2A define communication but not agent identity, leaving delegated authority and provenance unverifiable.The survey of approximately 2,000 MCP servers found that every scanned server lacked authentication.
  • 1 Introduction: Existing approaches address fragments of agent delegation but do not provide a jointly implemented solution spanning identity, attenuation, policy, transport, and provenance.Prior work includes macaroons, IETF drafts, and verifiable-intent proposals, but the paper reports no single implemented protocol combining these requirements.
  • 1 Introduction: AIP introduces IBCTs, unifying identity, attenuated authorization, and provenance binding in an evolvable token chain.Compact mode uses signed JWTs for single-hop calls, while chained mode uses Biscuit and Datalog policies for multi-hop delegation.
  • 1 Introduction: Reference implementations in Python and Rust demonstrate cross-language interoperability, sub-millisecond compact verification, low deployment overhead, and complete rejection in adversarial testing.The reported evaluation covers 0.049 ms Rust verification, 0.189 ms Python verification, and 100% rejection across 600 attack attempts.

2 Related Work and Gap Analysis

Existing identity and authorization systems each cover only part of the requirements for verifiable agent delegation. AIP positions itself as a protocol layer that combines the missing properties while complementing discovery and transport-authentication mechanisms.

  • 2.2 OAuth 2.0/2.1: OAuth remains the simpler choice for single-domain human-to-service authentication, whereas AIP addresses delegation-chain authentication that OAuth tokens do not preserve.OAuth provides client-to-server transport authentication but no delegation chain, holder-side attenuation, or provenance binding.
  • 2 Related Work and Gap Analysis: Macaroons, UCANs, SPIFFE, and emerging IETF drafts each leave deployment-relevant gaps involving shared secrets, DID or infrastructure dependencies, token immutability, or multi-hop delegation.These approaches target useful subproblems but do not jointly cover the paper’s seven-property requirement.
  • 2.5 Biscuit: Biscuit supplies public-key signatures, Datalog policies, and append-only delegation blocks, but lacks identity resolution, protocol bindings, and provenance.AIP adds those protocol-level capabilities on top of Biscuit’s cryptographic foundation.
  • 2.10 Agent Identity and Discovery (AID): AID addresses DNS-based agent discovery rather than authorization and could direct verifiers to AIP identity documents.The paper presents the protocols as complementary layers rather than competing authorization systems.
  • 2 Related Work and Gap Analysis: The survey identifies seven required properties and reports no prior solution addressing all seven simultaneously; AIP is designed to satisfy them.The properties include public-key verification, holder-side attenuation, expressive policy, cross-protocol flow, provenance binding, lightweight infrastructure, and lifecycle awareness.

3 The Agent Identity Protocol

AIP defines identity resolution and IBCTs as a common protocol for binding agent identity, attenuated authority, and provenance. It supports compact JWTs for single-hop calls and chained Biscuit tokens for multi-hop delegation and audit trails.

  • 3.1 Identity Scheme: AIP supports DNS-based identities for long-lived organizational agents and self-certifying public-key identities for ephemeral sub-agents.Both methods produce identity documents containing public keys, delegation parameters, protocol bindings, and expiration data.
  • 3.2 Invocation-Bound Capability Tokens: IBCTs fuse identity, attenuated authorization, and provenance into an append-only chain that evolves through authority, delegation, and completion blocks.The chain records the root authority, successive scope reductions, and optional execution outcomes.
  • 3.2 Invocation-Bound Capability Tokens: Delegation blocks cryptographically enforce scope narrowing, rejecting any delegation that widens capabilities beyond its parent block.Each block also names the delegator and delegatee and includes a mandatory purpose context.
  • 3.2 Invocation-Bound Capability Tokens: A completed IBCT can answer who authorized an action, how delegation flowed, which constraints applied, what outcome occurred, and whether it was independently verified.These questions are answered from the token chain as a single artifact.
  • 3.2 Invocation-Bound Capability Tokens: Compact mode uses EdDSA JWTs for single-hop cases, while chained mode uses Biscuit blocks and Datalog evaluation for multi-hop, cross-organization, and audit scenarios.Upgrading between modes requires re-issuance that maps JWT claims to Biscuit authority facts.

3.3 Completion Blocks and Trust Model

Completion blocks record execution outcomes but are self-reported by default, so their evidentiary strength depends on additional verification. AIP therefore defines escalation through delegator countersignatures or third-party attestations.

  • 3.3 Completion Blocks and Trust Model: Completion blocks are signed by the executing agent and are tamper-evident and attribution-bound, but not independently verified by default.The default trust level treats the completion as a self-reported claim.
  • 3.3 Completion Blocks and Trust Model: AIP defines self-reported, counter-signed, and third-party-attested trust levels for completion claims.The latter two levels add independent verification by a delegator, peer, human reviewer, or audit service.
  • 3.3 Completion Blocks and Trust Model: The example chain narrows authority across two delegations before an ephemeral agent appends a completion block containing status, result hash, cost, and token usage.The illustrated chain begins with a root authority and ends with execution metadata signed by the ephemeral agent.

3.4 Budget Semantics

IBCT budgets are authorization ceilings expressed in integer cents, while chained policies offer progressively more expressive controls from generated checks to bounded full Datalog.

  • 3.4 Budget Semantics: IBCT budget values are integer cents representing per-token authorization ceilings, not running balances or cumulative spend.Verifiers check that declared budgets are non-negative; completion blocks record actual cost, while runtime systems enforce aggregate spending.
  • 3.4 Budget Semantics: Simple policies generate four canonical checks for tool allowlists, budget ceilings, maximum delegation depth, and expiry.The Simple profile requires no Datalog knowledge and targets most single-organization delegation scenarios.
  • 3.4 Budget Semantics: Standard policies add conjunctive conditions and set-membership tests, including trust-domain restrictions and delegator-attribute-based access.Recursion and unbounded evaluation are prohibited in this profile.
  • 3.4 Budget Semantics: Advanced policies permit recursive rules, cross-block fact derivation, and arbitrary constraint combinations under a 1,000-iteration evaluation limit.The profile is opt-in for complex governance requirements.
  • 3.4 Budget Semantics: Verifiers that do not support Advanced policies must reject tokens containing non-Standard Datalog rather than ignore those policy blocks.

3.6 Protocol Bindings

AIP binds the same identity and token model to MCP, A2A, and generic HTTP, while delegation chains enforce attenuation, bounded depth, audit context, and short-lived grants.

  • 3.6 Protocol Bindings: AIP defines bindings for MCP, A2A, and HTTP so one identity and token format operates across agent protocols.
  • 3.6 Protocol Bindings: MCP clients send IBCTs in X-AIP-Token, allowing servers to resolve identities, verify signatures, evaluate policies, and inject verified identity into request context.Servers can require AIP and distinguish authentication failures from authorization failures with structured errors.
  • 3.6 Protocol Bindings: A2A callers place IBCTs with appended delegation blocks in task metadata, enabling receivers to verify the chain and delegate further when depth permits.
  • 3.6 Protocol Bindings: Each delegation block must attenuate its parent’s scope; widening capabilities, budgets, or expiry causes verification failure.The Biscuit authorizer evaluates all blocks together to reject contradictory facts.
  • 3.6 Protocol Bindings: Delegation is bounded by a declared maximum depth, and every block must include non-empty context to preserve the audit trail.AIP also supports ephemeral sub-agent grants with narrowed scope and short TTLs.
  • 3.6 Protocol Bindings: AIP v1 prefers tokens shorter than one hour over revocation infrastructure, while mutual authentication for self-certifying identities is deferred to v2.

3.8 End-to-End Walkthrough

The walkthrough follows a human request through an orchestrator, a specialist, and an MCP tool, showing how AIP preserves authorization details and outcomes across delegation.

  • 3.8 End-to-End Walkthrough: AIP’s end-to-end delegation flow connects published agent identity, protocol bindings, and multi-hop authorization from a human request to an MCP tool call.The example uses a research orchestrator delegating work to a specialist.
  • 3.8 End-to-End Walkthrough: At each hop, AIP checks signatures, scope and budget attenuation, depth, expiry, and non-empty context.The completed IBCT records who authorized the action, the delegation path, constraints at each hop, and the outcome.

4 Implementation

AIP is implemented in Python and Rust with compact and chained token support, cross-language conformance testing, and integrations for identity, policy, transport, and provenance.

  • 4 Implementation: AIP provides open-source Python and Rust implementations supporting compact and chained modes with full cross-language interoperability.The project is released under the Apache 2.0 license.
  • 4 Implementation: The Python SDK implements Ed25519 identities, signed compact tokens, Biscuit-based chained delegation, and generated Simple-profile policies.
  • 4 Implementation: The Rust workspace implements Ed25519 identity operations, manual compact JWT construction, Biscuit chained tokens, Datalog evaluation, and MCP header processing.
  • 4 Implementation: Cross-language conformance tests verify identical accept/reject decisions for tokens created and verified across Python and Rust, including malformed and expired claims.
  • 4 Implementation: Table 3 summarizes implementation details, with LOC counts covering library source while excluding Rust benchmarks and binaries.
  • 4 Implementation: AIP integrates with LDP provenance through identity-document extensions and completion-block provenance identifiers.

5 Evaluation

AIP evaluation covers compact and chained verification, realistic HTTP and LLM deployments, and adversarial security. Across these settings, overhead remains low, chained costs scale linearly, and AIP rejects attacks that unsigned and plain JWT deployments miss.

  • 5.2 Microbenchmarks (H1, H2): 0.049 ms Rust and 0.189 ms Python compact verification latencies remained below one millisecond, with identical 356-byte token sizes.Rust verification was approximately 3.9× faster than Python.
  • 5.3 Real-World MCP Deployment (H1, H3): 0.222 ms compact and 0.180 ms chained overhead were measured for real HTTP tool calls, keeping both modes below one millisecond.Compact overhead was 73.9% above the 0.301 ms baseline, while chained overhead was 59.8%.
  • 5.2 Microbenchmarks (H1, H2): 340–380 bytes per block and verification latency grew linearly with chained delegation depth, remaining under one millisecond at the recommended maximum depth.Scope attenuation was enforced in 100/100 tests, rejecting attempts to widen tools, budget, or expiry.
  • 5.4 Multi-Agent Delegation with LLM Inference (H3): 2.351 ms mean AIP overhead represented 0.086% of 2,749 ms end-to-end latency with Gemini 2.5 Flash.At p99, overhead remained 0.127%; protocol overhead was three orders of magnitude smaller than LLM inference.
  • 5.5 Adversarial Security Evaluation (H4): AIP rejected 600/600 adversarial attempts across six attack categories, while plain JWT missed delegation-depth and empty-context audit-evasion attacks.AIP uniquely detects these failures through mandatory delegation context and bounded depth in the authority block.

6 Threat Model

AIP’s threat model covers delegation misuse, identity compromise, replay, verifier behavior, fraudulent completion claims, collusion, and policy-complexity attacks. It specifies which attacks are prevented, detected, partially mitigated, or outside the token layer.

  • Threat coverage: AIP prevents scope widening through Biscuit’s check-all-blocks semantics, but misuse within an already granted scope remains outside the token layer.Every block is evaluated, and contradictory attenuation is rejected as a cryptographic guarantee.
  • Threat coverage: AIP detects forged DNS-hosted identity documents through self-signatures, but provides no defense when an attacker controls the agent’s private key.The signature detects document tampering; private-key compromise fully compromises the identity.
  • Threat coverage: Short-lived expiry rejects expired replayed tokens, while real-time replay within the TTL requires transport protections such as TLS and nonce binding.Token-layer mitigation is partial rather than a complete replay defense.
  • Threat coverage: AIP assumes verifiers perform signature, policy, and expiry checks correctly, making compliance an operational concern addressed through testing and reference implementations.The protocol cannot cryptographically enforce honest verifier behavior.
  • Threat coverage: Self-reported completion blocks bind claims to the signing agent but do not prevent dishonest result reporting; counter-signing and third-party attestation are optional.Colluding agents can also misuse authority within granted scopes, although delegation records support partial audit detection.
  • Threat coverage: Policy-complexity attacks are bounded by profile restrictions: Simple uses four canonical templates, while Advanced caps evaluation at 1,000 iterations.Verifiers that enforce these profiles bound worst-case evaluation cost.

7 Limitations

The evaluation and design have practical scope boundaries involving deployment realism, verifier complexity, self-reported provenance, revocation, DNS trust, and cryptographic algorithm coverage. These limitations identify where AIP’s guarantees and measurements do not yet extend.

  • Deployment scope: The evaluation uses one machine and localhost networking, so its overhead measurements do not capture production networking, cross-datacenter, or sustained-load conditions.The study includes real HTTP transport and Gemini 2.5 Flash inference but no production multi-agent deployment with real traffic.
  • Verifier complexity: Chained-mode Datalog can expose verifiers to excessive CPU use, although Simple eliminates this risk and Advanced caps evaluation at 1,000 iterations.The paper recommends Simple as the default deployment profile.
  • Provenance limits: Completion blocks are self-reported by executing agents, so the cryptographic layer alone cannot detect dishonest result hashes or cost claims.Counter-signing and third-party attestation are available as optional trust-escalation mechanisms.
  • Revocation: AIP v1 relies on tokens shorter than one hour rather than enforced revocation checks, deferring full revocation infrastructure to v2.Identity documents may declare a CRL endpoint, but the reference implementation does not enforce CRL checks.
  • Trust anchors: DNS-based identities inherit hijacking and cache-poisoning risks, while self-signatures detect tampering only if verifiers actually check them.Verifier compliance remains an operational rather than cryptographic guarantee.
  • Cryptographic scope: AIP v1 supports only Ed25519, with algorithm agility and post-quantum signature schemes deferred to a future version.The Ed25519-only design simplifies implementation but creates a migration burden if quantum-capable threats become practical.

8 Conclusion

The paper introduces AIP’s IBCT-based identity, authorization, and provenance chain in compact and chained formats, with interoperable Python and Rust implementations. AIP adds low measured overhead and rejects all tested attacks, while production validation, provenance integration, and OAuth comparison remain future work.

  • Contributions: IBCTs unify identity, attenuated authorization, and provenance in an append-only chain, using JWT compact mode for single-hop calls and Biscuit-Datalog chained mode for multi-hop delegation.Compact tokens are 356 bytes; chained blocks scale linearly at 340–380 bytes per block.
  • Contributions: AIP’s Python and Rust reference implementations demonstrate cross-language interoperability across 78 tests.The implementations cover both wire-format modes.
  • Evaluation: 0.22 ms is AIP’s overhead over unauthenticated MCP-over-HTTP, while Gemini 2.5 Flash deployment adds 2.35 ms, or 0.086% of total latency.The results report identity verification as not a bottleneck in these deployments.
  • Evaluation: 100% of 600 adversarial attempts were rejected, with delegation-depth violations and audit evasion uniquely caught by chained delegation.The paper identifies these categories as undetected by unsigned or plain-JWT deployments in the abstract.
  • Future work: Future work includes production validation of A2A delegation, formalizing the AIP–LDP provenance bridge, and comparing against a real OAuth 2.1 baseline.These steps target deployment evidence, interoperability, and a more informative authorization comparison.
Loading 2603.24775v1…