Pith. sign in

REVIEW 3 major objections 5 minor 64 references

InterSAGE: The Secure and Verifiable Interoperability Protocol for An Internet of Agents

T0 review · 3 major / 5 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read InterSAGE is a four-layer trust protocol suite that lets agents prove who built them, what code they run, and what they did.

desk verdict A well-organized architectural position paper whose honest synthesis of known primitives is let down by security claims that outrun the evidence and a delegation step that is genuinely under-specified. read the letter →

arxiv 2608.13030 v1 pith:6KBSIY46 submitted 2026-08-13 cs.CR cs.MAcs.NI

Zhenhua Zou , Sheng Guo , Qiuyang Zhan , Lepeng Zhao , Shuo Li , Zhuotao Liu This is my paper · ORCID
classification cs.CRcs.MAcs.NI
keywords agentidentitycardsverifiablecredentialscapability-awarediscoverymonotoniccapabilityattenuationtrustnegotiationaccountabilityinternetofagentsdelegation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that today's agent protocols standardize how agents exchange messages but not how agents prove identity, authorization, capabilities, or accountability, so the Internet of Agents lacks a trust plane. InterSAGE is proposed as that plane: four layers—persistent identity, capability-aware discovery, trust negotiation, and accountability—built on four primitives: Agent Identity Cards, DID-bound Verifiable Credential manifests, monotonic capability attenuation with two-tier access control, and kernel-mediated signed audit trails. If correct, InterSAGE would let agents verify each other's provenance and permissions before acting, keep delegated authority strictly shrinking, and attribute every action without relying on a blockchain. The paper positions InterSAGE as complementary to existing protocols, embedding trust primitives into their messages rather than replacing them.

What carries the argument

The load-bearing object is the Agent Identity Card (AIC), a registry-signed credential $AIC=\operatorname{Sign}_{GAR}(DID_{agent}\|K_{pub}\|S_{max})$ whose $S_{max}$ is the maximum capability set. Around it, the machinery is a four-stage monotonic attenuation chain—developer declaration, operator subset, registry issuance, runtime intersection—where every stage can only narrow, and a session boundary $S_{session}=S_{policy}\cap(S_{A}^{max}\cap S_{B}^{max})$. Skills and tools are carried as DID-bound Verifiable Credential manifests, and trace entries are signed by a kernel-held private key and linked by hashes. This machinery supplies the structural guarantees: subset checks and signatures, not runtime policy engines, enforce least privilege.

What would settle it

Run an implementation, misconfigure the application-tier policy to request a capability outside the parent agent's signed maximum, and inspect the session token; if any token grants that capability, the structural least-privilege claim is false.

Watch

Extended reading notes

Core claim

InterSAGE's central claim is that no prior architecture jointly enforces persistent identity, capability-aware discovery, trust negotiation, and accountability as one four-layer substrate for agent interoperability. The Agent Identity Card binds developer, code package, operator, and deployment context into one GAR-signed credential, so an attacker who compromises one dimension cannot impersonate another. Discovery turns each advertised skill or tool into a signed credential bound to the agent's DID, verified for issuer provenance, subject binding, permission alignment, and freshness before interaction. Trust negotiation builds sessions as the intersection of both agents' signed capability boundaries, optionally narrowed by application policy, so a misconfigured policy can deny access but cannot grant more than the signed boundary. Accountability uses kernel-held signing keys and hash-chained trace entries to make execution history tamper-evident and non-repudiable without consensus.

Load-bearing premise

The protocol assumes that the central registry's signing key is never stolen or misused and that the registry honestly checks a developer's and operator's claims before signing an identity card; all other guarantees trace back to that one signature.

Editorial extensions

If this is right

  • MCP tool invocations can carry the caller's AIC capability boundary, letting a tool server verify authorization before execution.
  • A2A and ANP discovery responses can embed signed skill and tool manifests, so discovery results are verified rather than self-declared.
  • Session tokens issued after mutual attestation are scoped to the intersection of both parties' signed capability boundaries, so a misconfigured application policy cannot widen access.
  • Delegation chains are cryptographically bounded in depth and capability, with revoking a parent invalidating all descendants.
  • Kernel-signed, hash-linked execution traces give non-repudiation without a distributed ledger, which would extend to edge and air-gapped deployments.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper does not formalize this, but the attenuation chain suggests a lattice: if capabilities form a lattice under intersection and subset, the session boundary is a greatest lower bound, turning the structural claim into a provable invariant.
  • Because Layer 0 identity is independently useful, the protocol could bootstrap through partial adoption: issuing identity cards first, then layering discovery and negotiation as the population grows.
  • If the four-dimensional binding holds against operator compromise, audit systems could use AIC dimensions to separate 'authorized action within bound' from 'policy error', a distinction current logs blur.
  • The design leaves room for behavioral attestation as an additional signal rather than a rival: structural capability bounds could be combined with runtime trust scoring, with each covering what the other lacks.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper proposes InterSAGE, a four-layer trust protocol suite for the Internet of Agents. Layer 0 provides persistent agent identity through Agent Identity Cards (AICs) that bind developer, code package, operator, and operational context, signed by a Global Agent Registry (GAR). Layer 1 offers capability-aware discovery via DID-bound Verifiable Credential manifests. Layer 2 provides trust negotiation through mutual attestation, delegation with monotonic capability attenuation, and two-tier access control. Layer 3 supplies kernel-mediated cryptographic audit trails for accountability. The paper positions InterSAGE as complementary to MCP, A2A, ANP, and AG-UI, and argues that no prior architecture jointly enforces persistent identity, capability-aware discovery, trust negotiation, and accountability as a single trust substrate. The manuscript is explicitly a positioning paper: formal proofs, performance evaluation, implementation details, and adversarial validation are deferred to companion work (§10.1).

Significance. If the protocol were fully specified and formally analyzed, InterSAGE would address a genuine gap in agent interoperability: most communication protocols do not define agent-native identity, capability verification, or non-repudiable audit. The paper's threat model (Table 1) and design principles (§3.1) are thoughtful, and Table 7 makes the joint-coverage argument explicit and checkable. The authors also deserve credit for clearly delimiting the paper's scope in §10.1 and for avoiding overclaiming on implementation maturity. However, the central novelty claim—that InterSAGE is the only architecture jointly enforcing the four properties—rests on qualitative self-assessment in Table 7 and is weakened by internal inconsistencies in the credential definitions and by the mismatch between the 'we prove' language in §8.2 and the deferral of formal verification in §10.1.

major comments (3)
  1. [§6.2 (Delegation Protocol, step 6) versus §4.1, Eq. (1)] The AIC definition in Eq. (1) states that an AIC is Sign_GAR(DIDagent || Kpub || Smax), so every AIC is GAR-signed and verification walks to the GAR root. However, the delegation protocol in §6.2, step 6, says 'GAR issues child AIC signed by the parent's key.' If this is literal, child AICs are not GAR-signed, and the statements in §8.2 that chain verification 'walks to the GAR root' and in §5.4 that discovery verifies manifests against the AIC trust chain are undefined for delegated agents. If the intended meaning is that the parent authorizes and the GAR then signs, that GAR signature is missing from the protocol text and from the formal model in Eq. (1). Either way, the delegation primitive—a core component of Layer 2—does not currently form a GAR-rooted trust chain as claimed, and this inconsistency sits at Layer 0, on which all other layers depend.
  2. [§8.2 versus §10.1 (Limitations)] Section 8.2 opens with 'We prove that InterSAGE satisfies its core security properties under the defined threat model,' but the analysis that follows is a prose argument over definitions, not a formal proof. Section 10.1 explicitly lists 'Formal verification: TLA+ or ProVerif models of the attestation and delegation protocols' as out of scope, along with performance evaluation, implementation detail, and adversarial evaluation. The proof claim in §8.2 is therefore contradicted by the manuscript's own limitations statement. The security properties should be presented as design arguments or informal security analysis, not as proofs, or the relevant formal models should be included.
  3. [§9.8 and Table 7] The joint-coverage argument—the basis for the abstract's claim that InterSAGE is 'the only architecture' jointly enforcing the four properties—rests entirely on the qualitative marks in Table 7 (•, ◦, —) assigned by the authors to selected comparators. The table gives no citations, definitions of the evaluation dimensions, or justification for each mark. For example, AgentMesh is marked '◦' for '4-dim binding' and '—' for 'verifiable manifests,' but the text does not explain which of AgentMesh's mechanisms were examined to reach these conclusions. Without a clear evaluation rubric or at least per-cell justifications, the 'only architecture' claim is not substantiated. The authors should either supply a detailed scoring methodology with evidence for each cell or weaken the novelty claim to 'none of the surveyed comparators provides all four primitives in our sense.'
minor comments (5)
  1. [§8.2] In the first paragraph of §8.2, the credential is called the 'Agent Identity Credential' while everywhere else it is the 'Agent Identity Card' (AIC); please use consistent terminology.
  2. [§4.4 and §7.3] The term 'kernel' is used for both a general secure key-custody component and the specific 'DeepKernel' product. Since the paper describes a protocol suite that is not tied to DeepKernel, clarify that 'kernel' refers to any compliant key-custody component and that DeepKernel is one implementation.
  3. [§8.4, Table 6] The table row 'PDP misconfigured to allow tools:*' lists InterSAGE as '✓' but the supporting argument depends on the assumption in §8.1 that the kernel correctly enforces delegation bounds and that the GAR correctly verifies bindings at issuance; please state these dependencies explicitly in the table caption or the surrounding text.
  4. [§10.1] The phrase 'positioning paper' is used repeatedly; consider adding a sentence in the introduction that defines what a positioning paper means for the journal's audience, since the term may be unfamiliar.
  5. [§5.4] The text says 'both skills and tools are represented assigne Verifiable Credentials' (missing blank); please fix the typo.

Circularity Check

0 steps flagged · score 0.0 of 10

No definitional circularity: InterSAGE's derivation is architectural, and its novelty claim rests on a self-authored comparison table rather than on a self-referential equation or fitted parameter.

full rationale

InterSAGE is a positioning paper whose derivation chain is architectural rather than statistical: it defines the AIC as a GAR-signed credential (Eq. 1), builds discovery and Layer-2 checks on that definition, and presents Table 7 as a survey-based novelty claim. I found no step in which an input is fitted and then reported as a prediction, no equation that reduces to its own premises, and no load-bearing self-citation. The authors cite their own BlockA2A for motivation and contrast, but the central four-layer design and the joint-coverage argument do not depend on BlockA2A being correct. Table 7 is a self-authored qualitative comparison, not a derivation, so its subjectivity is an evidentiary limitation rather than circularity. One internal correctness risk is worth flagging even though it is not circularity: Section 4.1 Eq. (1) defines every AIC as GAR-signed, whereas Section 6.2 delegation step 6 says the GAR issues child AIC signed by the parent's key, which would leave delegated AICs outside the GAR-root chain that Section 8.2 relies on; this is an inconsistency in the formal model, not a reduction of the conclusion to the inputs. Accordingly, the circularity score is 0.

Assumptions & free parameters 2 free parameters · 6 assumptions · 4 invented entities

The design rests almost entirely on external cryptographic standards (Ed25519, VCs, DIDs) plus two paper-specific trust anchors, the GAR and the kernel. The two free parameters are operational constants without defended values. All proposed entities are architectural components with no shipped artifact and no independent falsifiable handle.

free parameters (2)
  • attestation nonce TTL = 60 s
    Selected in §6.1, step 3 for challenge freshness. No analysis demonstrates safety under clock skew or replay in the mediated and direct peer-to-peer modes.
  • delegation depth ceiling = null
    A kernel-configured constant in §6.2, step 4. The depth-bounding property depends on this ceiling existing and being enforced, but no value or derivation is provided.
assumptions (6)
  • standard math Ed25519 signatures are existentially unforgeable (EUF-CMA).
    Stated in §8.1; used for AIC issuance, nonce challenges, session tokens, and trace signatures.
  • standard math Hash function H is collision-resistant.
    Stated in §8.1; used to bind nonces and the prev_hash trace chain.
  • ad hoc to paper GAR root key is uncompromised and GAR accurately verifies developer/operator bindings.
    Assumed in §8.1 under GAR Honesty. The GAR is an entity introduced by this paper, so the trust anchor is paper-specific.
  • ad hoc to paper Kernel integrity: key custody never signs unauthorized payloads and the private key cannot be extracted.
    Assumed in §8.1. The kernel is a DeepKernel component described in companion work, not specified here.
  • domain assumption Dolev-Yao network adversary augmented with LLM-level compromise but no key extraction or TEE bypass.
    Threat model in §8.1. Excludes hardware-level key extraction, which the paper classifies as outside protocol scope.
  • domain assumption OIDC providers are honest and time synchronization is loose.
    Listed as graceful degradation assumptions in §8.1; used to bind operator identity and validate freshness or expiry.
invented entities (4)
  • Agent Identity Card (AIC)
    purpose: Binds developer, code package, operator, and deployment context into one signed identity credential.
    Defined by this paper and used as the root of identity and delegation. No implementation or external validation is provided.
  • Global Agent Registry (GAR)
    purpose: Issues, verifies, and revokes AICs; acts as a CA-like trust anchor.
    The paper proposes a centralized or federated registry but ships no deployment, availability analysis, or governance mechanism.
  • DeepKernel security kernel
    purpose: Holds the agent's private key and mediates all signing operations.
    Referenced as a DeepKernel Lab component with a companion system paper pending. No code or specification is provided here.
  • Trusted Attestation Service (TAS)
    purpose: Optional remote mediator for mutual attestation between agents.
    Described in §6.1 and §10.2 as a deployment topology. It is an architectural entity without independent evidence.

how reviews work

0 comments
Cite this review

Pith. "Pith review of InterSAGE: The Secure and Verifiable Interoperability Protocol for An Internet of Agents." pith.science (2026). https://pith.science/paper/6KBSIY46

@misc{pith2026260813030,
  author       = {Pith},
  title        = {Pith review of: InterSAGE: The Secure and Verifiable Interoperability Protocol for An Internet of Agents},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6KBSIY46}},
  note         = {Machine review of arXiv:2608.13030}
}
read the original abstract

The emerging Internet of Agents enables LLM-powered agents to discover peers, invoke tools, and delegate tasks across organizational boundaries. Existing protocols increasingly define how agents exchange messages, but not how an agent proves its identity, authorization, advertised capabilities, or accountability after delegation. We present InterSAGE, a trust-native protocol suite that supplies this missing security substrate alongside, rather than in place of, communication protocols. InterSAGE comprises four layers: Persistent Identity, Discovery, Trust Negotiation, and Accountability. Its four core primitives are: (1) Agent Identity Cards that bind developer, code package, operator, and deployment context; (2) capability-aware discovery using DID-bound Verifiable Credential manifests; (3) trust negotiation combining monotonic capability attenuation with two-tier access control; and (4) kernel-mediated cryptographic audit trails that bind usage, delegation, and execution traces to agent identity without a consensus ledger. InterSAGE is designed to complement MCP, A2A, ANP, and AG-UI, allowing communication protocols to evolve independently while keeping trust semantics explicit, portable, and verifiable. We compare InterSAGE with more than 50 efforts spanning agent protocols, decentralized identity, OAuth/OIDC extensions, zero-trust governance, delegation, and audit architectures. We show that no prior architecture jointly enforces persistent identity, capability-aware discovery, trust negotiation, and accountability as a unified four-layer trust substrate for secure agent interoperability.

Figures

Figures reproduced from arXiv: 2608.13030 by the authors.

Figure 1
Figure 1. The InterSAGE four-layer protocol suite. Each layer builds on the one below it and embeds trust primitives into existing agent communication protocols: L0 constrains MCP tool invocation through AIC capability boundaries, L1 exposes DID-bound manifest VCs through discovery protocols such as ANP, L2 authorizes A2A interaction through session tokens, and L3 attaches signed execution traces to AG-UI streams. context—int… view at source ↗
Figure 2
Figure 2. Four-dimensional identity binding in the Agent Identity Card. Each dimension is controlled by a different party and verified independently [PITH_FULL_IMAGE:figures/full_fig_p010_2.png] view at source ↗
Figure 3
Figure 3. Mutual attestation protocol. Each agent’s kernel (Kernel𝐴, Kernel𝐵) mediates its own signing operations; private keys never leave the isolated trust boundary. When both agents share a host, the two kernels collapse to one. The protocol produces a pair of session tokens with capabilities scoped to 𝑆 𝐴 max ∩ 𝑆 𝐵 max (further narrowed by any application-level policy). 1. Agent 𝐴 requests attestation with Agent 𝐵 throug… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

64 extracted references · 34 canonical work pages

  1. [1]

    ReAct: Synergizing reasoning and acting in language models.arXiv preprint arXiv:2210.03629, 2022

    Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. ReAct: Synergizing reasoning and acting in language models.arXiv preprint arXiv:2210.03629, 2022

    arXiv 2022

  2. [2]

    AutoGen: Enabling next-gen LLM applications via multi-agent conversation.arXiv preprint arXiv:2308.08155, 2023

    Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, et al. AutoGen: Enabling next-gen LLM applications via multi-agent conversation.arXiv preprint arXiv:2308.08155, 2023

    arXiv 2023

  3. [3]

    MetaGPT: Meta programming for a multi-agent collaborative framework.arXiv preprint arXiv:2308.00352, 2023

    Sirui Hong, Mingchen Zhuge, Jiaqi Chen, Xiawu Zheng, et al. MetaGPT: Meta programming for a multi-agent collaborative framework.arXiv preprint arXiv:2308.00352, 2023

    arXiv 2023

  4. [4]

    Internet of agents: Weaving a web of heterogeneous agents for collaborative intelligence.arXiv preprint arXiv:2407.07061, 2024

    Weize Chen, Ziming You, Ran Li, Yitong Guan, Chen Qian, Chenyang Zhao, et al. Internet of agents: Weaving a web of heterogeneous agents for collaborative intelligence.arXiv preprint arXiv:2407.07061, 2024

    arXiv 2024

  5. [5]

    Gartner predicts agentic AI will autonomously resolve 80% of common customer service issues by 2029

    Gartner. Gartner predicts agentic AI will autonomously resolve 80% of common customer service issues by 2029. Gartner Press Release, 2025

    work page 2025

  6. [6]

    Agent-to-agent (A2A) protocol specification

    Google. Agent-to-agent (A2A) protocol specification. https://a2a-protocol.org/latest/ specification/, 2025

    work page 2025

  7. [7]

    Model context protocol (MCP) specification.https://modelcontextprotocol.io/, 2025

    Anthropic. Model context protocol (MCP) specification.https://modelcontextprotocol.io/, 2025

    work page 2025

  8. [8]

    Agent network protocol technical white paper.arXiv preprint arXiv:2508.00007, 2025

    Gao Chang, Eddie Lin, Chongyuan Yuan, Ran Cai, Bin Chen, Xinlin Xie, et al. Agent network protocol technical white paper.arXiv preprint arXiv:2508.00007, 2025

    arXiv 2025

Show all 64 references
  1. [9]

    Internet of agents: Fundamentals, applications, and challenges.IEEE Transactions on Cognitive Communications and Networking, 2025

    Yuntao Wang, Song Guo, Yutong Pan, Zhou Su, Fangmin Chen, et al. Internet of agents: Fundamentals, applications, and challenges.IEEE Transactions on Cognitive Communications and Networking, 2025. arXiv:2505.07176; accepted by IEEE TCCN

    2025

  2. [10]

    Agent-OSI: A layered protocol stack toward a decentralized internet of agents.arXiv preprint arXiv:2602.13795, 2026

    Wenxin Xu, Taotao Wang, Yihan Xia, Shengli Zhang, and Soung Chang Liew. Agent-OSI: A layered protocol stack toward a decentralized internet of agents.arXiv preprint arXiv:2602.13795, 2026

    2026 arXiv

  3. [11]

    A layered protocol architecture for the internet of agents.arXiv preprint arXiv:2511.19699, 2025

    Charles Fleming, Luca Muscariello, Vivek Pandey, et al. A layered protocol architecture for the internet of agents.arXiv preprint arXiv:2511.19699, 2025

    2025

  4. [12]

    A survey of AI agent protocols.arXiv preprint arXiv:2504.16736, 2025

    Yingxuan Yang, Huayi Chai, Yuqi Song, Shuai Qi, Muning Wen, Na Li, et al. A survey of AI agent protocols.arXiv preprint arXiv:2504.16736, 2025

    2025 arXiv

  5. [13]

    A survey of agent interoper- ability protocols: MCP, ACP, A2A, and ANP.arXiv preprint arXiv:2505.02279, 2025

    Abul Ehtesham, Aditi Singh, Gaurav Kumar Gupta, and Sandeep Kumar. A survey of agent interoper- ability protocols: MCP, ACP, A2A, and ANP.arXiv preprint arXiv:2505.02279, 2025

    2025 arXiv

  6. [14]

    ACPS: Agent collaboration protocols for the internet of agents.arXiv preprint arXiv:2505.13523, 2025

    Chao Li, Jiaxing Wu, Qiong Du, Shui Yu, Rui Zou, Kan Yu, et al. ACPS: Agent collaboration protocols for the internet of agents.arXiv preprint arXiv:2505.13523, 2025

    2025 arXiv

  7. [15]

    Agent client protocol (ACP): A protocol for connecting any editor to any agent.https://github.com/agentclientprotocol/agent-client-protocol, 2025

    Agent Client Protocol Project. Agent client protocol (ACP): A protocol for connecting any editor to any agent.https://github.com/agentclientprotocol/agent-client-protocol, 2025. 33

    2025

  8. [16]

    AgentRFC: Security design principles and conformance testing for agent protocols.arXiv preprint arXiv:2603.23801, 2026

    Shenghan Zheng and Qifan Zhang. AgentRFC: Security design principles and conformance testing for agent protocols.arXiv preprint arXiv:2603.23801, 2026

    2026

  9. [17]

    Security threat modeling for emerging AI-agent protocols: A comparative analysis of MCP, A2A, agora, and ANP.arXiv preprint arXiv:2602.11327, 2026

    Zeynab Anbiaee, Mahdi Rabbani, Mansur Mirani, Gunjan Piya, et al. Security threat modeling for emerging AI-agent protocols: A comparative analysis of MCP, A2A, agora, and ANP.arXiv preprint arXiv:2602.11327, 2026

    2026 arXiv

  10. [18]

    Wibowo and George C

    Juan A. Wibowo and George C. Polyzos. Toward a safe internet of agents.arXiv preprint arXiv:2512.00520, 2025

    2025 arXiv

  11. [19]

    AgentMesh: Production-grade trust layer for multi-agent systems

    Microsoft. AgentMesh: Production-grade trust layer for multi-agent systems. https://github.com/ microsoft/agent-governance-toolkit/tree/main/agent-governance-python/agent-mesh , 2026. Part of the Agent Governance Toolkit; SPIFFE/SVID-based identity, policy engine, A2A/MCP/IATP...

    2026

  12. [20]

    Fortifying the agentic web: A unified zero-trust architecture against logic-layer threats.arXiv preprint arXiv:2508.12259, 2025

    Kevin Huang, Yasir Mehmood, Haris Atta, Jingbo Huang, et al. Fortifying the agentic web: A unified zero-trust architecture against logic-layer threats.arXiv preprint arXiv:2508.12259, 2025

    2025 arXiv

  13. [21]

    AIP: Agent identity protocol for verifiable delegation across MCP and A2A.arXiv preprint arXiv:2603.24775, 2026

    Shiv Prakash. AIP: Agent identity protocol for verifiable delegation across MCP and A2A.arXiv preprint arXiv:2603.24775, 2026

    2026

  14. [22]

    Identity-aware governance for autonomous AI agents: A framework for enterprise authorization, delegation, and audit.SSRN, (6439998), 2026

    Hari Ramachandran and Gautam Mishra. Identity-aware governance for autonomous AI agents: A framework for enterprise authorization, delegation, and audit.SSRN, (6439998), 2026

    2026

  15. [23]

    BlockA2A: Towards secure and verifiable agent-to-agent interoperability.arXiv preprint arXiv:2508.01332, 2025

    Zhenhua Zou, Zhuotao Liu, Lepeng Zhao, and Qiuyang Zhan. BlockA2A: Towards secure and verifiable agent-to-agent interoperability.arXiv preprint arXiv:2508.01332, 2025

    2025

  16. [24]

    OpenID connect for agents (OIDC-A) 1.0: A standard extension for LLM-based agent identity and authorization.arXiv preprint arXiv:2509.25974, 2025

    Sudhir Nagabhushanaradhya. OpenID connect for agents (OIDC-A) 1.0: A standard extension for LLM-based agent identity and authorization.arXiv preprint arXiv:2509.25974, 2025

    2025

  17. [25]

    Identity management for agentic AI: The new frontier of authorization, authentication, and security.arXiv preprint arXiv:2510.25819, 2025

    Tobin South, Sudhir Nagabhushanaradhya, et al. Identity management for agentic AI: The new frontier of authorization, authentication, and security.arXiv preprint arXiv:2510.25819, 2025. OpenID Foundation whitepaper

    2025

  18. [26]

    Saavedra

    Daniel R. Saavedra. Interoperable architecture for digital identity delegation for AI agents with blockchain integration.arXiv preprint arXiv:2601.14982, 2026

    2026

  19. [27]

    Jones, Brian Campbell, John Bradley, and Nat Sakimura

    Michael B. Jones, Brian Campbell, John Bradley, and Nat Sakimura. OAuth 2.0 token exchange (RFC 8693). IETF RFC 8693, 2020

    2020

  20. [28]

    Bridging protocol and production: Design patterns for deploying AI agents with model context protocol.arXiv preprint arXiv:2603.13417, 2026

    Vivek Srinivasan. Bridging protocol and production: Design patterns for deploying AI agents with model context protocol.arXiv preprint arXiv:2603.13417, 2026

    2026 arXiv

  21. [29]

    Coral protocol: Open infrastructure connecting the internet of agents.arXiv preprint arXiv:2505.00749, 2025

    RJ Georgio, C Forder, S Deb, A Rahimov, et al. Coral protocol: Open infrastructure connecting the internet of agents.arXiv preprint arXiv:2505.00749, 2025

    2025 arXiv

  22. [30]

    Agentic AI frameworks: Architectures, protocols, and design challenges.arXiv preprint arXiv:2508.10146, 2025

    Hana Derouiche, Zaki Brahmi, and Haithem Mazeni. Agentic AI frameworks: Architectures, protocols, and design challenges.arXiv preprint arXiv:2508.10146, 2025

    2025 arXiv

  23. [31]

    AG-UI: The agent-user interaction protocol

    CopilotKit. AG-UI: The agent-user interaction protocol. https://github.com/ag-ui-protocol/ag-ui , 2025. 34

    2025

  24. [32]

    ContextForge: An AI gateway, registry, and proxy for MCP, A2A, and REST/gRPC APIs

    IBM. ContextForge: An AI gateway, registry, and proxy for MCP, A2A, and REST/gRPC APIs. https: //github.com/IBM/mcp-context-forge, 2026

    2026

  25. [33]

    agents.json: An open specification for API and agent interaction contracts

    Wild Card AI. agents.json: An open specification for API and agent interaction contracts. https: //github.com/wild-card-ai/agents-json, 2025

    2025

  26. [34]

    The OAuth 2.0 authorization framework (RFC 6749)

    Dick Hardt. The OAuth 2.0 authorization framework (RFC 6749). IETF RFC 6749, 2012

    2012

  27. [35]

    OpenID connect core 1.0

    OpenID Foundation. OpenID connect core 1.0. https://openid.net/specs/openid-connect-core-1_0. html, 2014

    2014

  28. [36]

    Authenticated delegation and authorized AI agents.arXiv preprint arXiv:2501.09674, 2025

    Tobin South, Samuele Marro, Thomas Hardjono, Robert Mahari, et al. Authenticated delegation and authorized AI agents.arXiv preprint arXiv:2501.09674, 2025

    2025 arXiv

  29. [37]

    A conceptual framework for authentication in agentic AI ecosystems: Protocol analysis and taxonomy

    Bharat Bhushan, Karthik Pappu, and Aman Mittal. A conceptual framework for authentication in agentic AI ecosystems: Protocol analysis and taxonomy. InIEEE ICCA, 2025

    2025

  30. [38]

    The transport layer security (TLS) protocol version 1.3 (RFC 8446)

    Eric Rescorla. The transport layer security (TLS) protocol version 1.3 (RFC 8446). IETF RFC 8446, 2018

    2018

  31. [39]

    Agentic AI identity security

    Kevin Huang and Chris Hughes. Agentic AI identity security. InSecuring AI Agents. Springer, 2025

    2025

  32. [40]

    SPIFFE-based zero-trust authentication for AI agent ecosystems

    Karthik Pappu, Bharat Bhushan, and Aman Mittal. SPIFFE-based zero-trust authentication for AI agent ecosystems. InIEEE ICCA, 2025

    2025

  33. [41]

    A novel zero-trust identity frame- work for agentic AI: Decentralized authentication and fine-grained access control.arXiv preprint arXiv:2505.19301, 2025

    Kevin Huang, Venkata Sai Narajala, Justin Yeoh, Justin Ross, et al. A novel zero-trust identity frame- work for agentic AI: Decentralized authentication and fine-grained access control.arXiv preprint arXiv:2505.19301, 2025

    2025 arXiv

  34. [42]

    Internet X.509 public key infrastructure certificate and certificate revocation list profile (RFC 5280)

    David Cooper, Stefan Santesson, Stephen Farrell, Sharon Boeyen, Russell Housley, and Tim Polk. Internet X.509 public key infrastructure certificate and certificate revocation list profile (RFC 5280). IETF RFC 5280, 2008

    2008

  35. [43]

    Gehrmann, et al

    Sandro Rodríguez Garzon, Arian Vaziry, Elif Merve Kuzu, Daniel E. Gehrmann, et al. AI agents with decentralized identifiers and verifiable credentials.arXiv preprint arXiv:2511.02841, 2025

    2025 arXiv

  36. [44]

    Verifiable credentials data model v2.0

    W3C. Verifiable credentials data model v2.0. https://www.w3.org/TR/vc-data-model-2.0/ , 2025. W3C Recommendation, 2025-05-15

    2025

  37. [45]

    Agent payments protocol (AP2): Building a secure and interoperable future for AI-driven payments.https://github.com/google-agentic-commerce/AP2, 2026

    Google. Agent payments protocol (AP2): Building a secure and interoperable future for AI-driven payments.https://github.com/google-agentic-commerce/AP2, 2026

    2026

  38. [46]

    Danny Dolev and Andrew C. Yao. On the security of public key protocols.IEEE Transactions on Information Theory, 29(2):198–208, 1983

    1983

  39. [47]

    OpenAgents network model

    OpenAgents. OpenAgents network model. https://openagents.org/docs/zh/concepts/ openagents-network-model, 2026. Version 1.0; updated May 8, 2026

    2026

  40. [48]

    AI agent communication from internet architecture perspective: Challenges and opportunities.arXiv preprint arXiv:2509.02317, 2025

    Chenguang Du, Chao Wang, Yihan Chao, Xin Xie, and Yong Cui. AI agent communication from internet architecture perspective: Challenges and opportunities.arXiv preprint arXiv:2509.02317, 2025

    2025 arXiv

  41. [49]

    A study on the MCP x A2A framework for enhancing interoperability of LLM-based autonomous agents.arXiv preprint arXiv:2506.01804, 2025

    Cheonsu Jeong. A study on the MCP x A2A framework for enhancing interoperability of LLM-based autonomous agents.arXiv preprint arXiv:2506.01804, 2025. 35

    2025

  42. [50]

    AI agent communications in the future internet—paving a path toward the agentic web.Future Internet (MDPI), 18(3):171, 2026

    Qiang Duan and Zhihui Lu. AI agent communications in the future internet—paving a path toward the agentic web.Future Internet (MDPI), 18(3):171, 2026

    2026

  43. [51]

    A2H: Agent-to-human protocol for AI agent.arXiv preprint arXiv:2602.15831, 2026

    Zhuo Liang, Erzhuo Cui, Qian Wei, Rui She, Ting Li, Minghui Guo, et al. A2H: Agent-to-human protocol for AI agent.arXiv preprint arXiv:2602.15831, 2026

    2026

  44. [52]

    Song Guo, Yuntao Wang, Zhou Su, Yutong Pan, Qimei Hu, and Tom H. Luan. Agent discovery in internet of agents: Challenges and solutions.IEEE Network, 2026. arXiv:2511.19113

    2026

  45. [53]

    Position: AI agents need authenticated delegation

    Tobin South, Samuele Marro, Thomas Hardjono, Robert Mahari, et al. Position: AI agents need authenticated delegation. InICML, 2025. Position paper

    2025

  46. [54]

    Decentralized digital identity management for large language model agents.IEEE Communications Standards Magazine, 2026

    Abdullah Aydeger, Engin Zeydan, et al. Decentralized digital identity management for large language model agents.IEEE Communications Standards Magazine, 2026

    2026

  47. [55]

    AGNTCY identity: Onboarding, creating, and verifying identities for agents and MCP servers.https://github.com/agntcy/identity, 2026

    AGNTCY. AGNTCY identity: Onboarding, creating, and verifying identities for agents and MCP servers.https://github.com/agntcy/identity, 2026

    2026

  48. [56]

    Verified agent identity: Decentralized identity management for AI agents using iden3

    BillionsNetwork. Verified agent identity: Decentralized identity management for AI agents using iden3. https://github.com/BillionsNetwork/verified-agent-identity, 2026

    2026

  49. [57]

    Agent name service (ANS): A universal di- rectory for secure AI agent discovery and interoperability.arXiv preprint arXiv:2505.10609, 2025

    Kevin Huang, Venkata Sai Narajala, Idan Habler, et al. Agent name service (ANS): A universal di- rectory for secure AI agent discovery and interoperability.arXiv preprint arXiv:2505.10609, 2025. arXiv:2505.10609

    2025 arXiv

  50. [58]

    An explainable zero trust identity framework for LLMs, AI agents, and agentic AI systems.EuroLexis Open Access Journal, 2025

    Bharat Bhushan. An explainable zero trust identity framework for LLMs, AI agents, and agentic AI systems.EuroLexis Open Access Journal, 2025

    2025

  51. [59]

    Agentic AI for self-sovereign identity: A decentralized zero trust framework for autonomous microservices.IJCMI, 2025

    Dhanush Reddy Palavali. Agentic AI for self-sovereign identity: A decentralized zero trust framework for autonomous microservices.IJCMI, 2025

    2025

  52. [60]

    LDP: An identity-aware protocol for multi-agent LLM systems.arXiv preprint arXiv:2603.08852, 2026

    Shiv Prakash. LDP: An identity-aware protocol for multi-agent LLM systems.arXiv preprint arXiv:2603.08852, 2026

    2026

  53. [61]

    HDP: A lightweight cryptographic protocol for human delegation provenance in agentic AI systems.arXiv preprint arXiv:2604.04522, 2026

    Asiri Dalugoda. HDP: A lightweight cryptographic protocol for human delegation provenance in agentic AI systems.arXiv preprint arXiv:2604.04522, 2026. IETF Internet-Draft draft-helixar-hdp- agentic-delegation-00

    2026 arXiv

  54. [62]

    Know your agent: Governing AI identity on the agentic web

    TJ Chaffer. Know your agent: Governing AI identity on the agentic web. SSRN Working Paper, 2025. SSRN 5162127

    2025

  55. [63]

    OpenAI agents SDK: A lightweight framework for multi-agent workflows

    OpenAI. OpenAI agents SDK: A lightweight framework for multi-agent workflows. https://github. com/openai/openai-agents-python, 2025

    2025

  56. [64]

    Agent development kit (ADK): An open-source python toolkit for building AI agents

    Google. Agent development kit (ADK): An open-source python toolkit for building AI agents. https: //github.com/google/adk-python, 2025

    2025

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.