InterSAGE\n
\nThe Secure and Verifiable Interoperability Protocol \n
for An Internet of Agents\n
\nA Paper from the DeepKernel Lab

\n\nZhenhua ZouSheng GuoQiuyang ZhanLepeng ZhaoShuo Li\n\n \nZhuotao Liu\n\nAffiliation: \n\nAffiliation: Corresponding author:\nzhuotaoliu@tsinghua.edu.cn\n

\n\n

Abstract

\n \n

The emerging Internet of Agents—a global environment in which\nLLM-powered agents discover peers, negotiate trust, invoke tools, and\ndelegate tasks across organizational boundaries—is currently being\nstandardized from the communication layer upward. Protocols increasingly\nspecify how agents exchange messages, but not how an agent proves what it\nis, what it is authorized to do, whether its advertised capabilities are\ngenuine, or how its actions remain accountable after delegation. We argue\nthat this leaves the ecosystem without the foundation for secure\ninteroperability.

\n \n

We present InterSAGE, a trust-native protocol suite that supplies this trust\nsubstrate alongside existing Internet and agent communication protocols.\nInterSAGE is organized into four layers—Persistent\nIdentity (L0), Discovery (L1), Trust Negotiation (L2), and\nAccountability (L3)—covering nine security aspects across the agent\nlifecycle. Its core contribution is a set of four layer-aligned design\nprimitives. First, Agent Identity Cards provide persistent agent identity\nwith four-dimensional binding across developer, code package, operator, and\ndeployment context. Second, capability-aware discovery turns skill and tool\nadvertisements into DID-bound Verifiable Credential manifests, so discovery\nresults are verified for issuer provenance, subject binding, permission\nalignment, and freshness before interaction begins. Third, trust negotiation\ncombines monotonic capability attenuation with two-tier access control,\nmaking least privilege a signed structural invariant while preserving\napplication-level policy independence. Fourth, kernel-mediated\ncryptographic audit trails bind usage, delegation, and execution traces to\nagent identity without requiring a consensus ledger.

\n \n

InterSAGE does not replace existing agent protocols such as MCP, A2A, ANP, or AG-UI; it defines the missing\ntrust-relevant primitives that those protocols need: AIC capability boundaries,\nDID-bound manifest VCs, least-privilege session tokens, and signed execution traces.\nThis separation ensures that communication protocols can evolve\nindependently, while trust semantics remain explicit, portable, and\nverifiable. We compare InterSAGE against 50+ related efforts across agent\nprotocols, decentralized identity, OAuth/OIDC extensions, zero-trust\ngovernance, delegation systems, and audit architectures.\nWe show that InterSAGE is the only\narchitecture that jointly enforces persistent identity,\ncapability-aware discovery, trust negotiation, and accountability as a single four-layer trust substrate for the Internet of Agents.

\n \n

1 Introduction

\n\n

The emergence of LLM-powered autonomous agents marks a qualitative shift in\nhow software interacts with the world. Unlike traditional microservices that\nexecute deterministic APIs, these agents reason over natural language, invoke\ntools dynamically, and collaborate with other agents to accomplish complex,\nmulti-step tasks [1, 2, 3, 4]. Industry analysts\nproject that by 2029 agentic AI will autonomously resolve a large share of\ncommon customer service issues without human intervention [5], and major cloud providers\nhave already released agent-to-agent communication\nprotocols [6, 7, 8] to enable such\ncollaboration at scale.

This trajectory evolves toward an Internet of Agents\n(IoA) [4, 9, 10]—a global network where\nbillions of heterogeneous agents discover one another, negotiate task\nparameters, exchange value, and compose into ad-hoc workflows across\norganizational boundaries. Multiple research groups have begun designing\nprotocol stacks for this vision: Fleming et al. propose reference layers for\nagent communication (L8) and semantics (L9) atop TCP/IP [11]; the Agent-OSI\nproject outlines a six-layer reference architecture including settlement and\nprovenance [10]; and comprehensive surveys catalog the growing\nzoo of protocols spanning agent-to-agent (A2A), agent-to-tool (MCP), and\nrelated interaction axes [12, 13, 14].¹¹\n 1\n \n \n \n \n \n \n \n In Ehtesham et al., “ACP” denotes the Agent Communication Protocol (REST/HTTP), not the Agent Client Protocol [15].

The missing trust layer. \nA striking pattern emerges across these efforts: they focus predominantly on\nhow agents communicate where security is again treated as the second-class citizen. Yet the agent threat landscape is qualitatively different from the traditional\nnetworking and computer systems. Agents operate with delegated authority, make\nnon-deterministic decisions, and dynamically compose into workflows whose\nauthorization requirements cannot be statically pre-computed. An agent that\nimpersonates a supply-chain optimizer, escalates its capabilities beyond\ndelegation scope, or repudiates a financial commitment can cause cascading\ndamage that no transport-layer encryption or OAuth token can\nprevent [16, 17, 18]. A first wave of\ntrust-layer proposals has begun to address this gap—Microsoft’s\nAgentMesh [19], which its documentation describes as “SSL for AI agents”;\nHuang et al.’s unified zero-trust architecture for the agentic\nweb [20]; AIP [21], which fuses identity,\nattenuation, and provenance into invocation-bound capability tokens; and\nRamachandran and Mishra’s enterprise identity-aware governance\nframework [22]. These efforts converge on the\ndiagnosis but diverge in mechanism: each enforces least-privilege through\nruntime policy evaluation, behavioral attestation, or per-call\nDatalog rather than through structural invariants signed into the agent’s\ncredential at issuance. In the language of classical protocol design, the\nIoA still lacks its trust plane—the security substrate that binds\nidentity, authorization, and accountability into a coherent whole that\nholds even when downstream policy engines, attestors, or operators are\nmisconfigured or compromised.

Lessons from our prior work. \nIn BlockA2A [23], we presented a unified trust framework\nfor multi-agent systems, integrating decentralized identifiers (DIDs),\nblockchain-anchored ledgers, and smart-contract-enforced access control. The\nframework demonstrated that security can be systematically layered\nonto agent collaboration protocols such as A2A [6]. However, its\nreliance on blockchain infrastructure introduced deployment constraints:\non-chain transaction latency, gas costs, and the requirement for a shared\nledger among all participants limited applicability to environments where\nblockchain nodes are available and economically viable. The core security\nideas—cryptographic agent identity, capability-bounded access\ncontrol, immutable audit trails, and defense orchestration—remain sound,\nbut their realization must be generalized beyond any specific type of\ninfrastructure.

This paper: InterSAGE. \nWe present InterSAGE, the first trust-native protocol suite for secure and verifiable agent-to-agent interoperability.\nRather than proposing another communication stack, InterSAGE provides the trust layers that any communication protocol\n(MCP, A2A, or future designs) can build upon. Its four layers address\nnine critical aspects of agent-native security:

1. \n
\n
Layer 0 — Agent Identity: persistent identity via cryptographic agent\nidentity cards (AICs) with four-dimensional binding to developer, code\npackage, operator, and deployment context.
\n
2. \n
\n
Layer 1 — Discovery: capability-aware discovery in which\neach skill and tool is a signed Verifiable Credential (VC) bound to the\nagent’s DID. Manifest VCs are presented during discovery and verified for\nsupply-chain authenticity, subject binding, and permission alignment.
\n
3. \n
\n
Layer 2 — Trust Negotiation: authentication via mutual attestation,\ndelegation via chains with monotonic capability attenuation, and a two-tier\naccess control model.
\n
4. \n
\n
Layer 3 — Accountability: token-usage tracing, payment\nprimitives, and action accountability via identity-signed execution traces\nand non-repudiation.
\n

InterSAGE is guided by five design principles (detailed in\n§3.1) and introduces four novel design primitives.\nWe summarize each below using a uniform pattern—shared goal with prior\nwork, the specific divergence, and the operationally observable\nconsequence—a pattern we apply throughout §9 when\ncontrasting InterSAGE with related systems.

• \n
\n
Persistent Identity (L0). An Agent Identity Card (AIC)\ncryptographically binds four identity dimensions—developer, code\npackage, operator, and operational context—into a single verifiable\ncredential. The goal of giving each agent a verifiable persistent\nidentity is shared with SPIFFE workload identities, OAuth 2.0 client\ncredentials, W3C DIDs, OIDC for Agents (OIDC-A) [24], the\nOpenID Foundation’s strategic agenda for agentic\nIAM [25], and AIP’s capability\ntokens [21]; the divergence is that each of those\nmodels binds only a single dimension—workload instance, client\napplication, holder key, or token issuer—whereas the AIC binds all\nfour dimensions independently and signs their conjunction. The\nconsequence is that an attacker who compromises the operator’s\ndeployment cannot impersonate a different developer or substitute a\ndifferent code package, because each dimension carries its own\nindependently verifiable signature.
\n
• \n
\n
Capability-Aware Discovery (L1). Each skill and tool an\nagent advertises is a signed Verifiable Credential (VC) whose\ncredentialSubject.id is the agent’s own DID—making it\nnon-transferable and replay-resistant. Skill VCs are issued by skill\ndistributors, tool VCs are issued by tool providers, and both can carry\noptional GAR endorsements before being presented in the agent’s\nregistration record during discovery. The goal of\nmaking agents discoverable is shared with ANP’s DID-based\ndiscovery [8], A2A’s well-known Agent\nCards [6], and registry-style agent catalogs; the\ndivergence is that InterSAGE treats discovery results as verified\ncapability credentials rather than self-declared descriptions.\nRequesters verify each manifest VC for supply-chain authenticity,\nsubject binding to the presenter’s AIC, and permission alignment\nagainst the agent’s capability boundary $S_{\\max}$ . The consequence is\nthat discovery cannot become an implicit escalation channel: an\nagent cannot advertise skills it does not hold, tools it has not been\nauthorized to use, or permissions it was not granted, because every\nclaim is cryptographically bound to the agent’s identity and\nindependently verifiable at discovery time.
\n
• \n
\n
Trust Negotiation (L2). InterSAGE combines a four-stage\nmonotonic attenuation chain (Developer $\\to$ Operator $\\to$ GAR\n $\\to$ Runtime) with a two-tier access control model that separates\ninfrastructure-tier cryptographic verification from application-tier\ndeclarative policy. The goal of bounded authorization is shared with\nAIP’s Biscuit/Datalog attenuation [21], Saavedra’s\nDelegation Grants [26], AgentMesh’s policy\nplane [19], OAuth 2.0 token exchange [27], and\nenterprise governance frameworks [22];\nthe divergence is that InterSAGE encodes the capability boundary into\nsigned credentials and then evaluates application policy on an\nindependent path. The consequence is that no policy edit, JIT\ndecision, or misconfigured PDP downstream of issuance can grant\ncapabilities the preceding stage did not authorize, while an\napplication-tier regression still cannot weaken cryptographic\nidentity verification.
\n
• \n
\n
Accountability (L3). Every agent\naction is recorded in a tamper-evident hash chain and signed by the\nagent’s kernel-protected private key. The goal of immutable\naccountability is shared with blockchain-anchored ledgers\n(like BlockA2A [23]) and centralized audit logs; the\ndivergence is that InterSAGE achieves non-repudiation via trusted\nkernel-mediated cryptography rather than distributed consensus or\ntrusted third parties. The consequence is that agents can prove\ntheir execution history and attribute costs across boundaries in\ncompletely decentralized or resource-constrained environments where\nglobal ledgers are unviable.
\n

Scope and positioning. \nInterSAGE is a positioning paper: it presents the conceptual framework,\nprotocol architecture, and design rationale at a level suitable for guiding\nsubsequent protocol specifications, formal verification, and systems\nimplementation. Detailed cryptographic proofs, performance benchmarks, and\nproduction deployment experiences are deferred to companion publications\ncurrently in preparation.

Contributions. \nIn summary, this paper makes the following contributions:

1. \n
\n
We articulate the case for secure interoperability as the\nfoundational missing layer in the Internet of Agents, distinct from\ncommunication interoperability and grounded in a dedicated trust\nsubstrate.
\n
2. \n
\n
We present InterSAGE, a four-layer security protocol suite that\ncoherently addresses nine security aspects: persistent identity,\ncapability-aware discovery, authentication, delegation, access\ncontrol, payment, semantic tagging, token-usage tracing, and action\naccountability. The first five receive detailed protocol-level\ntreatment; the latter four are specified as framework-level\nprimitives that establish architectural slots for future refinement.
\n
3. \n
\n
We introduce four novel design primitives: the Agent Identity\nCard for persistent identity, capability-aware discovery through\nDID-bound Verifiable Credential manifests that make skill and tool\nclaims cryptographically verifiable at discovery time, trust\nnegotiation combining the monotonic capability attenuation chain\nwith the two-tier A2A access control model, and kernel-mediated\ncryptographic audit trails for accountability.
\n
4. \n
\n
We position InterSAGE within the current landscape of agent protocol,\nidentity, and governance efforts (§9)—organized\ninto six clusters spanning IoA stacks and surveys, agent IAM and\nOAuth/OIDC extensions, zero-trust DID/VC architectures,\ndelegation-centric protocols, security-design principles, and\nindustry trust overlays—and make the joint-coverage argument\nexplicit: each individual primitive in InterSAGE is anticipated by some\nprior work, but the conjunction of persistent identity,\ncapability-aware discovery, trust negotiation with monotonic\nattenuation and two-tier access control, and kernel-mediated\naccountability appears in\nno prior single architecture (Table 7).
\n

The remainder of this paper is organized as follows.\n§2 surveys the agent interaction landscape and threat\nmodel. §3 presents the design philosophy and protocol suite\noverview. §4–§7 detail each\nlayer. §8 provides a security analysis and comparison with\nexisting approaches. §9 discusses related work in depth.\n§10 outlines limitations and future directions.\n§11 concludes.

2 Background & Threat Landscape

\n\n

2.1 The Agent Interaction Landscape

\n\n

Modern agent-to-agent communication is shaped by a rapidly growing set of\nprotocols, each targeting a different facet of the problem:

Model Context Protocol (MCP). \nThe Model Context Protocol (MCP) [7], introduced by Anthropic and\nnow maintained as an open, vendor-neutral specification, standardizes how an\nagent (client) discovers and invokes external tools hosted by MCP servers via\nJSON-RPC. Third-party deployment surveys report over 97 million monthly SDK\ndownloads as of early 2026 [28]; MCP is widely adopted for\nagent-to-tool integration. The core specification, however, does not define\nagent-native identity, mutual authentication between agents, or authorization\nsemantics beyond transport-level security.

Agent-to-Agent Protocol (A2A). \nThe Agent-to-Agent (A2A) protocol [6], developed under the\nA2A open specification effort, enables peer-to-peer task delegation between\nagents using capability-based Agent Cards. A2A supports both\nsynchronous and asynchronous interactions and provides structured task\nlifecycle management. Published security guidance centers on HTTPS and\nOAuth 2.0; the specification does not yet standardize agent-native identity,\nstructured delegation chains, or cross-domain trust comparable to a dedicated\ntrust plane.

Agent Network Protocol (ANP). \nANP [8] introduces a three-layer architecture—identity\nand encrypted communication, meta-protocol negotiation, and application\nprotocol—using W3C DIDs and JSON-LD for open agent discovery. ANP focuses\non the “agentic web” vision but, in its published white paper, treats\naccess control and end-to-end accountability less extensively than\nidentity and discovery.

Emerging protocol stacks. \nSeveral groups propose higher-level architectures. Fleming\net al. [11] propose reference layers for agent communication\n(L8) and agent semantics (L9) above TCP/IP (not part of the classical OSI\nstack). Agent-OSI [10] proposes a six-layer\ndecentralized stack including settlement and provenance. ACPS [14]\ndefines registration, discovery, interaction, and tooling protocols.\nCoral Protocol [29] provides open infrastructure for\nagent communication, coordination, trust, and payments framed as the\n“Internet of Agents.” Surveys [12, 13, 30] catalog and compare these efforts.

Beyond A2A: adjacent interaction axes and trust overlays. \nThe protocol space continues to multiply along distinct interaction axes\nthat complement A2A: AG-UI [31] for agent-to-user\nstreaming, the Agent Client Protocol (ACP) [15] for\neditor-to-coding-agent flows, IBM ContextForge [32]\nas a federated gateway proxying MCP/A2A/REST, and the\nagents.json specification [33] extending OpenAPI\nwith agent-specific interaction contracts. Most recently, Microsoft’s\nAgentMesh [19] describes itself in project documentation as\n“SSL for AI agents,”\nlayering SPIFFE/SVID workload identity, a runtime policy engine, and\nA2A/MCP/IATP protocol translators atop existing communication stacks; a\nparallel academic effort, Huang et al.’s unified zero-trust\narchitecture [20], adds behavioral attestation and trust-adaptive runtime environments to the same trust-overlay paradigm. We\nreturn to both as our primary industry and academic comparators in\n§9.

\n\nKey Insight 1: Observation. \nExisting protocols and stacks overwhelmingly prioritize communication\ninteroperability: how agents find each other, exchange messages, and\ninvoke tools. Security is treated as an aspect to be satisfied at each\nlayer rather than as a foundational design center with its own\ncoherent architecture. Even the most security-conscious trust overlays\n(AgentMesh [19], the unified zero-trust\narchitecture of Huang et al. [20]) enforce least-privilege\nthrough runtime policy evaluation and behavioral attestation rather than\nthrough monotonic capability attenuation that holds at the credential\nlevel—so a misconfigured policy or a compromised attestor can silently\nwiden capability. This leaves critical gaps that individual protocol\npatches cannot close.\n\n

2.2 Agent-Specific Threat Model

\n\n

The agent ecosystem introduces threats that are qualitatively different from\ntraditional web services. We identify six categories that motivate the design\nof InterSAGE.

Table 1: Agent-specific threat categories and their structural causes.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Threat	\n\nDescription\n	\n\nStructural Cause\n
T1: Identity spoofing	\n\nAn agent claims to be built by a trusted developer or to possess capabilities it lacks.\n	\n\nAgents use self-declared names or API keys; no binding to developer, code, or operator.\n
T2: Capability escalation	\n\nA child agent exercises permissions beyond what its parent delegated.\n	\n\nStatic permission models lack monotonic attenuation; delegation is often unconstrained.\n
T3: Delegation abuse	\n\nUnbounded delegation chains create laundering paths for authority.\n	\n\nNo depth bounding, no cascading revocation, no tenant isolation in delegation.\n
T4: Cross-domain trust breakdown	\n\nAgents from different organizations cannot verify each other’s identity or capabilities.\n	\n\nNo shared trust anchor; each framework uses its own identity model.\n
T5: Payment & usage fraud	\n\nAn agent consumes LLM tokens or services without traceable identity.\n	\n\nToken usage is tied to API keys, not to cryptographic agent identity; no metering protocol.\n
T6: Action repudiation	\n\nAn agent denies having performed a high-impact action (e.g., financial transfer).\n	\n\nExecution traces are not cryptographically signed; audit logs are mutable.\n

\n\n

Table 1 summarizes these threats. Prior threat\nanalyses [16, 17, 18, 23] have\nidentified overlapping subsets; our contribution is to map them to their\nstructural causes—the architectural deficiencies that enable\neach threat—which directly motivates the layered design of InterSAGE.

The taxonomy in Table 1 is not constructed in isolation. It\nsynthesizes three independent lines of analysis: Anbiaee\net al. [17] compare MCP, A2A, Agora, and ANP and\nidentify twelve protocol-level risks, several of which (cross-protocol\ncredential laundering, executable-component attestation, lifecycle\nrisks) map directly onto T1–T4. AgentRFC [16] formalizes\neleven security principles as TLA+ invariants and introduces the\nComposition Safety principle—the observation that properties holding\nfor individual protocols can break under composition—which underlies\nT2 and T4. Identity-aware governance\nanalyses [22] ground these abstract risks\nin production incidents reported in that survey (e.g., the ClawHavoc\nsupply-chain attack on 824+ malicious agent skills, Cisco’s finding that\n26% of analyzed agent skills contain security vulnerabilities, and\n30,000+ internet-exposed OpenClaw instances), making T1–T6 verifiable\nrather than purely analytical.

2.3 Why Traditional Internet Security Falls Short

\n\n

The Internet’s existing security mechanisms were designed for human users\ninteracting with web services. Three fundamental mismatches arise when they\nare applied to autonomous agents.

OAuth/OIDC assumes human principals. \nOAuth 2.0 [34] and OpenID Connect [35] model a three-party\nflow: a human user authorizes a client application to access a resource\nserver. Agent-to-agent interactions invert this model—both parties are\nnon-human, may be ephemeral, and require mutual (not unilateral)\nauthentication. The OpenID Foundation’s strategic agenda for agentic\nIAM [25] explicitly catalogs these gaps and surveys\ncandidate extensions; OIDC-A [24] is the most concrete\nextension to date, defining standard claims for representing agent\nidentity, attestation, and delegation chains within OAuth. Yet such\nextensions still inherit OAuth’s interactive-flow assumptions and bind\nto a single client dimension, not to the developer, code\npackage, operator, and operational context that agent provenance\nrequires [36, 37].

TLS provides transport, not identity semantics. \nTLS [38] secures the channel but does not tell the recipient\nwho built the agent, what code it runs, or who\nauthorized its deployment. A TLS certificate binds a public key to a\ndomain name, not to a developer-code-operator triple. Mutual TLS (mTLS)\nadds client-side certificates but still does not express agent\ncapabilities, delegation depth, or revocation cascades. Recent\nzero-trust frameworks add SPIFFE/SVID workload identity above\nmTLS [39, 40, 41], which\nremoves static API keys and enables short-lived attestation, but binds\nkeys to workload instances—a single dimension—rather than to\nthe conjunction of developer, code package, operator, and operational\ncontext that agent trust decisions require.

X.509 does not bind agent semantics. \nX.509 certificates [42] bind a public key to a subject name and\nare widely used in PKI. However, agent identity requires richer\nsemantics: capability boundaries, delegation chains, code-package\nhashes, and operational context. Encoding these in X.509 extensions is\ntechnically possible but semantically awkward and incompatible with the\nexisting CA ecosystem. SPIFFE/SPIRE [40] provides\nworkload identity for Kubernetes but, as noted above, does not model\nagent-native concepts such as delegation depth, capability attenuation,\nor developer-code provenance.

\n\nKey Insight 2: Gap. \nNo existing Internet security mechanism provides the combination of\npersistent identity with four-dimensional binding,\ncapability-aware discovery with verifiable skill and tool\nmanifests, trust negotiation that combines monotonic capability\nattenuation with two-tier access control, and accountability via\ntamper-evident execution traces. InterSAGE fills this gap with a dedicated\nsecurity protocol suite.\n\n

3 InterSAGE: Design Philosophy & Protocol Suite Overview

\n\n

3.1 Design Principles

\n\n

InterSAGE is guided by five principles distilled from lessons learned in\nBlockA2A [23], the DeepKernel security\nkernel, and the broader agent security literature:

P1. \n
\n
Trust as a binding layer, not an add-on.\nExisting IoA stacks [11, 10, 14] design communication\nfirst and add security externally—via auth headers, gateway proxies, or\nprotocol-specific translators [19]. InterSAGE inverts this: its\ntrust primitives (AIC capability boundaries, manifest VCs, session tokens,\ntrace entries) are designed to be embedded into existing protocol\nmessages. An MCP invocation carries an AIC-bound capability context; an\nANP discovery response carries manifest VCs; an A2A interaction carries a\nLayer 2 session token; an AG-UI event stream attaches provenance metadata.\nThe trust layer pervades the communication layer rather than\nwrapping around it.
\n
P2. \n
\n
Complementary to existing Internet layers.\nInterSAGE does not replace TCP/IP, HTTP, or application-layer protocols such as\nMCP and A2A. Instead, it provides a trust overlay that any\ntransport and any agent protocol can bind to. An agent using A2A over HTTPS\ncan adopt InterSAGE’s identity and access control layers without modifying A2A’s\nmessage format.
\n
P3. \n
\n
General cryptographic primitives, no infrastructure lock-in.\nBlockA2A demonstrated the value of blockchain-anchored auditability, but\nat the cost of deployment generality. InterSAGE uses standard Ed25519 signatures,\na PKI-style Global Agent Registry (GAR), and challenge-response protocols\nthat work in any environment—cloud, edge, or air-gapped.\nSpecific deployments can optionally layer additional trust anchors\n(TEEs, HSMs, distributed ledgers) without changing the core protocol.
\n
P4. \n
\n
Deny-by-default, converge-on-strict.\nCapabilities, permissions, and access are denied unless explicitly granted.\nWhen multiple policies combine (e.g., developer declaration, operator\nprovisioning, runtime policy), the system computes the\nintersection, never the union. Authority can only be attenuated,\nnever amplified—a property we call monotonic capability\nattenuation.
\n
P5. \n
\n
Structural guarantees over policy-based assurances.\nWhere possible, InterSAGE encodes security properties as structural invariants\n(e.g., a child AIC’s capability set is a cryptographically signed subset of\nits parent’s) rather than relying on runtime policy engines to enforce\nthem. Structural guarantees survive misconfiguration; policy-based\nassurances do not.
\n

3.2 Protocol Suite Architecture

\n\n

InterSAGE is organized into four layers, each addressing a distinct set of\nsecurity concerns. Figure 1 illustrates the architecture\nand its relationship to the existing Internet protocol stack.

Figure 1: The InterSAGE four-layer protocol suite. Each layer builds on the one\nbelow it and embeds trust primitives into existing agent communication\nprotocols: L0 constrains MCP tool invocation through AIC capability\nboundaries, L1 exposes DID-bound manifest VCs through discovery protocols\nsuch as ANP, L2 authorizes A2A interaction through session tokens, and L3\nattaches signed execution traces to AG-UI streams.

\n\n

Layer 0: Agent Identity. \nThe foundation of InterSAGE. Every agent receives a cryptographic Agent\nIdentity Card (AIC) that binds four identity dimensions—developer, code\npackage, operator, and operational context—into a single verifiable\ncredential signed by the Global Agent Registry. Layer 0 also manages the\nagent’s key lifecycle: provisioning, rotation, and revocation with cascading\nguarantees. (§4)

Layer 1: Discovery. \nBefore two agents can interact, they must find each other and understand\neach other’s capabilities. Layer 1 provides capability-aware discovery:\neach skill and tool is represented as a signed Verifiable Credential (VC)\nbound to the agent’s DID, issued by the relevant skill distributor or tool\nprovider, and presented in the agent’s registration record. Requesters\nverify each manifest VC for issuer authenticity, subject binding, and\npermission alignment against the agent’s AIC capability boundary—transforming\ndirectory lookup into a trust-establishing protocol step. Layer 1 supports\nboth registry-mediated and peer-to-peer discovery modes.\n(§5)

Layer 2: Trust Negotiation. \nThe interaction layer. When an agent wishes to collaborate with or delegate\nto another, Layer 2 orchestrates mutual attestation via challenge-response\nover AICs, computes the session capability boundary via intersection, and\nevaluates the responder’s application-level access policy. Its core\nprimitive combines monotonic capability attenuation with two-tier access\ncontrol: cryptographic credentials define the maximum boundary, while\napplication policy can only narrow the resulting session. Layer 2 also\nmanages delegation: a parent agent can issue a child AIC with strictly\nattenuated capabilities, forming a cryptographic delegation chain with\nbounded depth and cascading revocation. (§6)

Layer 3: Accountability. \nEvery interaction leaves a cryptographic trace. Layer 3 binds LLM\ntoken-usage records to agent identity, provides payment primitives for\nagent-to-agent service exchange, and ensures that execution traces are\nsigned by the agent’s kernel-held private key for non-repudiation.\n(§7)

3.3 Relationship to Existing Protocols

\n\n

The agent ecosystem already has a rich set of communication\nprotocols—MCP, A2A, ANP, AG-UI [31],\nACP [15]—that define what agents say to each\nother: message formats, task lifecycles, tool invocations, UI event\nstreams. InterSAGE does not compete with any of them. Instead, it treats\nthem as host protocols—the transport and application channels\ninto which its trust primitives are embedded—and answers a different\nquestion: why should agents trust each other?

We discuss this compositional relationship here, rather than deferring\nit to Related Work, because it is integral to the design: every layer\nof InterSAGE (Figure 1) is defined in terms of how its\nprimitives bind to host-protocol messages, so understanding that binding\nis a prerequisite for understanding the protocol suite itself.\nThe Related Work section (§9) serves a different\npurpose: it compares InterSAGE against security-oriented architectures\nand trust frameworks—AgentMesh, AIP, HDP, ZT-IAM, AgentRFC, among\nothers—that share InterSAGE’s goal of adding trust to the agent ecosystem\nbut differ in mechanism. Those works are InterSAGE’s comparators;\nthe protocols below are its substrates.

Figure 1 shows this substrate relationship concretely.\nInterSAGE operates alongside—not above or below—the host protocols, and\nthe two concerns compose naturally:

• \n
\n
An MCP tool invocation carries the agent’s AIC capability boundary\n(from Layer 0), ensuring that the tool server can verify the caller is\nauthorized to invoke the requested tool before execution.
\n
• \n
\n
ANP’s DID-based discovery responses embed the agent’s manifest VCs\n(from Layer 1), enabling any peer resolving an agent’s DID to verify\nskill and tool claims via subject binding and permission alignment.
\n
• \n
\n
An A2A interaction carries a session token issued by InterSAGE’s Layer 2\nafter mutual attestation and capability intersection, scoping the\nsession to the least-privilege boundary of both parties.
\n
• \n
\n
AG-UI events streamed to a frontend include identity-signed\nexecution traces (from Layer 3), allowing the UI to display verified\nprovenance and non-repudiable action history for each agent.
\n

This composability is a direct consequence of Principle P2: by avoiding\nassumptions about the underlying transport or application protocol, InterSAGE remains agnostic to the rapidly evolving agent communication landscape.

4 Layer 0: Persistent Agent Identity

\n\n

\n\nKey Insight 3: Design Thesis. \nWithout verified identity, every other security property is built on air.\nLayer 0 ensures that every agent in the InterSAGE ecosystem is a\ncryptographic principal—unforgeable, verifiable, and bound to its\nprovenance.\n\n

4.1 Agent Identity Card (AIC)

\n\n

The Agent Identity Card is the foundational credential in InterSAGE. An\nAIC is a verifiable credential that binds an agent’s identity to its\npermission boundary. Formally:

\n\n\n\n\n\n\n\n

\\mathsf{AIC}=\\mathsf{Sign}_{\\mathsf{GAR}}\\!\\bigl(\\mathsf{DID}_{\\mathsf{agent}}\\;\\|\\;K_{\\mathsf{pub}}\\;\\|\\;S_{\\max}\\bigr)

(1)

where $\\mathsf{DID}_{\\mathsf{agent}}$ is a structured agent identifier derived from the\n $\\langle\\textit{developer},\\allowbreak\\;\\textit{code\\_pkg},\\allowbreak\\;\\textit{deploy\\_ctx}\\rangle$ triple,\n $K_{\\mathsf{pub}}$ is the agent’s Ed25519 public key (whose corresponding private key\n $K_{\\mathsf{priv}}$ never leaves the isolated trust boundary), and $S_{\\max}$ is the\ncapability boundary—the maximum set of permissions this agent may\never exercise.

The AIC is signed by the Global Agent Registry (GAR) using its root\nEd25519 key, analogous to a Certificate Authority signing an X.509\ncertificate. However, unlike X.509, the AIC natively encodes agent-specific\nsemantics: capability sets, delegation depth, identity assurance levels, and\noperational context.

4.2 Four-Dimensional Identity Binding

\n\n

A persistent agent identity must answer four questions simultaneously:\nwho built it, what code does it run, who deployed it,\nand in what context does it operate. InterSAGE binds all four into the AIC\nthrough what we call four-dimensional identity binding.

Figure 2: Four-dimensional identity binding in the Agent Identity Card. Each\ndimension is controlled by a different party and verified independently.

\n\n

Table 2: The four identity dimensions of an AIC.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Dimension	\n\nWhat It Binds\n	\n\nWho Controls\n	\n\nVerification\n
Developer Identity	\n\nDeveloper’s Ed25519 signing key\n	\n\nDeveloper (build time)\n	\n\nGAR verifies developer enrollment\n
Code Package	\n\nCryptographic digest of the agent’s code or container image\n	\n\nBuild pipeline\n	\n\nGAR checks code hash at issuance\n
Operator Identity	\n\nOIDC-verified human operator (e.g., via Google, GitHub SSO)\n	\n\nHuman operator (provisioning)\n	\n\nGAR binds OIDC token to AIC\n
Operational Context	\n\nTenant ID, deployment environment, region\n	\n\nPlatform operator\n	\n\nGAR records at issuance; inherited by delegates\n

\n\n

This four-dimensional binding addresses threat T1 (identity spoofing) from\nTable 1: an attacker cannot forge an AIC without simultaneously\ncontrolling the developer’s signing key, producing a matching code digest,\npresenting valid OIDC credentials, and registering with the correct\noperational context.

Contrast with existing approaches. \nDID-based identity [43, 26] binds a public\nkey to a decentralized identifier but does not natively encode developer,\ncode, or operator dimensions. SPIFFE [40] provides workload\nidentity attestation via platform-specific mechanisms but does not model\ncapability boundaries or delegation semantics. The AIP\nprotocol [21] introduces Invocation-Bound Capability Tokens\nwithout separating developer and operator dimensions in the credential model. InterSAGE’s four-dimensional binding provides richer provenance than\nworkload-centric models such as SPIFFE/SVID (used by\nAgentMesh [19]) and, among the identity proposals surveyed in\n§9, is the only one we found that jointly binds developer,\ncode, operator, and operational context within a single verifiable credential.

4.3 Global Agent Registry (GAR)

\n\n

The GAR serves as the trust anchor for the InterSAGE ecosystem, playing a role\nanalogous to a Certificate Authority in traditional PKI. Its responsibilities\ninclude:

1. \n
\n
Developer enrollment: onboarding developers with verified\nsigning keys and policy governance.
\n
2. \n
\n
AIC issuance: validating that the requested capability\nboundary $S_{\\max}$ is a subset of the developer’s declared maximum,\nverifying the developer signature, binding the OIDC operator identity,\nand signing the AIC with the GAR root key.
\n
3. \n
\n
AIC lookup and verification: enabling any party to resolve\nan agent’s AIC by identifier and verify its signature chain.
\n
4. \n
\n
Revocation: maintaining a revocation registry; revoking an\nAIC atomically invalidates it and all its delegated descendants\n(cascading revocation, detailed in §6.2).
\n

The GAR can be deployed as a centralized service (suitable for enterprise\nenvironments), a federated constellation (analogous to federated CAs), or\nbacked by a distributed ledger for environments that require decentralized\ntrust anchoring. This flexibility is a direct consequence of Principle P3.

4.4 Key Protection Tiers

\n\n

The agent’s private key $K_{\\mathsf{priv}}$ is the root of its cryptographic identity.\nInterSAGE defines three protection tiers, allowing deployments to choose the\nappropriate security-cost trade-off:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Tier	Mechanism	\n\nSecurity Level\n	Deployment
1	OS file isolation (0o600)	\n\nModerate\n	Dev / testing
2	OS keychain (Keychain, DPAPI)	\n\nGood (HW-backed)\n	Production
3	TEE enclave (SGX, Nitro)	\n\nStrong (key never leaves HW)\n	High-assurance

Table 3: Key protection tiers.

K_{\\mathsf{priv}}

never leaves the local trust boundary regardless of tier.

\n\n

Regardless of the tier, a fundamental invariant holds: $K_{\\mathsf{priv}}$ never\nleaves the isolated trust boundary. All signing operations are mediated by the\nagent’s designated kernel, which acts as an HSM-like custodian. External agents and\neven the agent’s own application logic interact only with opaque\nhandles—they can request signatures but never access the raw key\nmaterial.

4.5 Identity Lifecycle

\n\n

An AIC progresses through a well-defined lifecycle:

1. \n
\n
Provisioning: The operator submits a registration request\n(agent ID, capabilities, OIDC token) to the kernel. The kernel generates\na fresh Ed25519 keypair, constructs the AIC payload, and forwards it to\nthe GAR for signing. The signed AIC is returned and cached locally.
\n
2. \n
\n
Active use: The AIC is used for mutual attestation\n(§6), session token issuance, and delegation.
\n
3. \n
\n
Rotation: Key rotation generates a new keypair, revokes the\nold AIC, and issues a replacement preserving all identity dimensions.\nActive sessions are invalidated to prevent stale credential use.
\n
4. \n
\n
Revocation: An AIC can be revoked by the operator, the GAR\nadministrator, or automatically upon expiration. Revocation cascades to\nall delegated descendants (§6.2), ensuring that\nrevoking a parent instantly invalidates the entire subtree.
\n

The lifecycle is designed so that identity is persistent (the agent’s\nidentity dimensions survive key rotation) while credentials are\nephemeral (AICs have bounded validity and can be revoked at any time).\nThis distinction is crucial for long-lived agents that operate across\nsessions and deployments.

5 Layer 1: Registration, Discovery & Semantic Interoperability

\n\n

Layer 0 establishes who an agent is; Layer 1 establishes what\nan agent can do and how to find it. This layer bridges identity to\ninteraction by providing the infrastructure for agents to advertise their\ncapabilities, discover peers, and cryptographically verify the authenticity\nof advertised skills before any trust negotiation begins.

The central insight of Layer 1 is that discovery must be a security\nprimitive: every capability claim an agent advertises is backed by a signed\nVerifiable Credential (VC) bound to the agent’s DID and verifiable against\nthe AIC trust chain. This transforms agent discovery from a directory\nlookup into a trust-establishing protocol step.

5.1 Capability-Aware Registration

\n\n

When an agent is provisioned (Layer 0), its AIC already contains a capability\nboundary $S_{\\max}$ . Layer 1 extends this with a richer registration\nrecord that the agent publishes to the GAR or a federated discovery service:

\n\nRegistration Record\n\n\n\n\nagent_id\n

\\mathsf{DID}_{\\mathsf{agent}}

from the AIC\n\naic_ref\nreference to the signed AIC\n\ncapabilities\nstructured list from the capability vocabulary\n\nsemantic_tags\ntags for capability-aware search\n\nendpoints\ntransport endpoints (HTTP, gRPC, WebSocket)\n\nprotocols\nsupported protocols (A2A, MCP, ANP)\n\nmanifests\nlist of signed skill/tool manifest VCs\n\nmetadata\ndescription, version, pricing hints\n\n\n

The registration record is itself signed by the agent’s $K_{\\mathsf{priv}}$ (via the\nkernel), ensuring that only the agent can create or update its own record.\nThe GAR or discovery service verifies this signature against the AIC’s\n $K_{\\mathsf{pub}}$ before accepting the registration.

5.2 Semantic Capability Tagging

\n\n

Raw capability enumerations (e.g., fs.read, network.fetch)\ndescribe what system surfaces an agent can touch but not the semantic\ndomain of the agent’s expertise. InterSAGE introduces a two-level tagging scheme:

1. \n
\n
System capabilities (from Layer 0): a closed vocabulary of\npermission classes bound to the AIC. These are machine-enforced at\nruntime.
\n
2. \n
\n
Semantic tags (from Layer 1): an open vocabulary of\ndomain-specific labels (e.g., legal-review,\ncode-generation, financial-analysis) that describe the\nagent’s expertise at a human-understandable and LLM-parseable level.
\n

Semantic tags are not capability grants—they carry no enforcement\nweight. Their purpose is to enable capability-aware discovery: a requester\nsearching for a “code review” agent can filter candidates by semantic tag,\nthen verify actual capabilities via the AIC and manifest VCs before\nLayer 2 negotiation.\nThis separation prevents semantic labels from being abused as implicit\npermission escalation vectors.

5.3 Capability-Aware Discovery

\n\n

InterSAGE treats discovery as a security primitive rather than a directory lookup.\nA discovery response is only useful if the requester can verify not just that\nan agent claims a skill or tool, but that the advertised capability is backed by a\nsigned manifest VC and fits within the agent’s AIC capability boundary. This\nturns Layer 1 into capability-aware discovery: semantic search narrows\nthe candidate set, while DID-bound manifest VCs and AIC-bound capabilities\nmake the result safe to consume during Layer 2 negotiation.

InterSAGE supports two discovery modes that can coexist within the same ecosystem:

Registry-mediated discovery. \nAgents query the GAR (or a federated registry constellation) with structured\nqueries over capabilities, semantic tags, protocol support, and trust\nattributes (e.g., minimum identity assurance level, trusted developer list).\nThe registry returns matching registration records, each verifiable against\nthe corresponding AIC. This mode is analogous to DNS resolution and is\nsuitable for enterprise and platform-managed environments.

Peer-to-peer discovery. \nIn decentralized environments, agents can discover peers via protocol-native\nmechanisms (e.g., ANP’s DID-based discovery [8], A2A’s\nwell-known Agent Cards [6]). InterSAGE does not replace these\nmechanisms but augments them: once a candidate agent is discovered via\nany means, its AIC can be resolved and verified through the GAR, adding a\ntrust verification step that the native discovery protocol may lack.

Both modes converge on the same verification flow: the discovered agent’s AIC\nis verified against the GAR’s trust chain, and each manifest VC in its\nregistration record is validated via the four-check protocol\n(§5.4). Discovery thus answers three questions\nsimultaneously: “who is out there” (AIC verification), “what can they\ndo” (manifest VC verification), and “should I trust them” (subject\nbinding + permission alignment).

5.4 Verifiable Skill & Tool Manifests

\n\n

An agent’s capabilities are realized through two mechanisms:

• \n
\n
Skills—reusable capability modules (code packages) that\nrun within the agent’s execution environment.
\n
• \n
\n
Tools—external service bindings (API endpoints, MCP\nservers) that the agent invokes over the network.
\n

In InterSAGE, both skills and tools are represented as signed\nVerifiable Credentials (VCs) cryptographically bound to the agent’s DID\nand verifiable against the AIC trust chain. This design ensures that\ncapability claims—whether local code or remote services—carry the same\nstructural trust guarantees as agent identity itself. The two types share a\ncommon credential structure but differ in their issuance model, reflecting\ntheir distinct trust relationships.

Credential structure. \nBoth skill and tool manifest VCs follow the W3C Verifiable Credentials\ndata model [44] adapted for agent semantics:

\n\nSkill Manifest VC\n\n\n\n\n@context\nW3C VC context + InterSAGE skill vocabulary\n\nid\nunique credential URI\n\ntype\n[“VerifiableCredential”, “SkillManifest”]\n\nissuer\ndistributor DID (skill author)\n\ncredentialSubject\n{\n\n id\n

\\mathsf{DID}_{\\mathsf{agent}}

(the agent holding this skill)\n\n manifest_id\nunique manifest identifier\n\n perms_required\nsystem capabilities the skill needs\n\n caps_provided\nwhat the skill enables for the agent\n\n code_hash\ndigest of the skill code package\n\n}\n\n\nproof\nEd25519 signature by the distributor\n\ngar_endorsement\noptional GAR endorsement\n\n\n

\n\nTool Manifest VC\n\n\n\n\n@context\nW3C VC context + InterSAGE tool vocabulary\n\nid\nunique credential URI\n\ntype\n[“VerifiableCredential”, “ToolManifest”]\n\nissuer\ntool provider DID (service operator)\n\ncredentialSubject\n{\n\n id\n

\\mathsf{DID}_{\\mathsf{agent}}

(the agent authorized to use this tool)\n\n manifest_id\nunique manifest identifier\n\n perms_required\ncapabilities the tool invocation needs\n\n caps_provided\nwhat the tool enables for the agent\n\n endpoint\nservice URI (MCP server, REST API, etc.)\n\n api_hash\ndigest of the tool’s interface schema\n\n}\n\n\nproof\nEd25519 signature by the tool provider\n\ngar_endorsement\noptional GAR endorsement\n\n\n

In both cases the credentialSubject.id field binds the manifest to\na specific agent DID ( $\\mathsf{DID}_{\\mathsf{agent}}$ ). This binding means that a manifest VC is\nnon-transferable: even if an attacker obtains the credential, it cannot be\npresented on behalf of a different agent because the verifier checks that\nthe subject DID matches the presenter’s AIC.

Skill manifest issuance. \nThe lifecycle of a skill manifest VC proceeds as follows:

1. \n
\n
Distributor publishes skill. The skill author (the\ndistributor) creates the manifest, signs it with their distributor key,\nand optionally submits it to the GAR for endorsement.
\n
2. \n
\n
Agent acquires skill. When an agent installs a skill, the\nkernel verifies the distributor’s signature and (if present) the GAR\nendorsement. The kernel then issues a binding proof: a secondary\nsignature using the agent’s $K_{\\mathsf{priv}}$ that attests “I hold this skill\nand my AIC permits its required capabilities.”
\n
3. \n
\n
Agent presents during discovery. The agent includes its\nbound skill manifest VCs in its registration record.
\n

Tool manifest issuance. \nTools differ from skills because their trust anchor is the tool\nprovider (the external service operator), not a code distributor:

1. \n
\n
Tool provider registers service. The service operator\npublishes a tool manifest describing the tool’s endpoint, interface\nschema, and required permissions. The provider signs the manifest with\ntheir provider key and optionally obtains a GAR endorsement.
\n
2. \n
\n
Provider issues VC to agent. When an agent requests access\nto a tool, the provider verifies the agent’s AIC and checks that the\nagent’s capability boundary $S_{\\max}$ is a superset of the tool’s\nperms_required. If satisfied, the provider issues a tool\nmanifest VC with credentialSubject.id set to the agent’s\n $\\mathsf{DID}_{\\mathsf{agent}}$ —effectively granting the agent verifiable authorization to\ninvoke the service.
\n
3. \n
\n
Agent presents during discovery. The agent includes its\ntool manifest VCs alongside skill manifest VCs in its registration\nrecord. Requesters can now verify that the agent not only claims access\nto a tool but has been explicitly authorized by the tool provider.
\n

In both flows, the agent’s registration record ultimately\ncontains a set of manifest VCs—some for skills, some for tools—each\nindependently verifiable by any requester or registry.

Verification during discovery. \nWhen a requester discovers an agent and retrieves its registration record,\nthe following checks are performed on each manifest VC before the agent is\nconsidered a valid candidate for Layer 2 negotiation:

• \n
\n
Supply-chain verification: The issuer’s signature\n(skill distributor or tool provider) and any GAR endorsement are\nverified, preventing supply-chain attacks analogous to the “ClawHavoc”\nincident [22].
\n
• \n
\n
Subject binding: The credentialSubject.id must\nmatch the discovered agent’s $\\mathsf{DID}_{\\mathsf{agent}}$ . This prevents manifest replay\nattacks where an adversary copies another agent’s manifest credentials.
\n
• \n
\n
Permission alignment: The manifest’s\nperms_required must be a subset of the agent’s AIC capability\nboundary $S_{\\max}$ . If a skill or tool requires permissions beyond the agent’s\nboundary, the manifest is rejected, ensuring that discovery cannot\nsurface agents whose advertised claims exceed their actual authorization.
\n
• \n
\n
Freshness: The manifest VC must not be expired or revoked\n(checked against the GAR’s revocation list or status endpoint).
\n

This four-check verification protocol transforms discovery from a trust-me\ndirectory into a verify-then-interact security boundary. The\nconsequence is structural: an agent cannot advertise capabilities it does\nnot possess, because every advertised skill or tool must be backed by a VC whose\nsubject binding, issuer provenance, and permission alignment are all\nindependently verifiable.

6 Layer 2: Trust Negotiation

\n\n

Layer 2 is the interaction layer of InterSAGE. It governs three critical\nprocesses: mutual attestation (how two agents establish trust),\ndelegation (how a parent agent creates bounded child identities), and\naccess control (how a responder decides what a requester may do).\nTogether, these processes address threats T2–T4 from Table 1.

6.1 Mutual Attestation Protocol

\n\n\nWhen two agents wish to interact, neither should blindly trust the other. The\nmutual attestation protocol establishes bilateral trust through a\nchallenge-response exchange grounded in the agents’ AICs.\n\n\nWe write Kernel_$A$ and Kernel_$B$ for the kernels that hold

K_{\\mathsf{priv}}^{A}

and\n

K_{\\mathsf{priv}}^{B}

respectively. When both agents reside on the same host,\nKernel_$A$

{}={}

Kernel_$B$ and the protocol reduces to local operations.\n\n\n\n\nFigure 3: Mutual attestation protocol. Each agent’s kernel (Kernel_$A$, Kernel_$B$)\nmediates its own signing operations; private keys never leave the isolated\ntrust boundary. When both agents share a host, the two kernels collapse to\none. The protocol produces a pair of session tokens with capabilities\nscoped to

S_{\\max}^{A}\\cap S_{\\max}^{B}

(further narrowed by any\napplication-level policy).\n\n\n\n1. \n\nAgent

A

requests attestation with Agent

B

through Kernel_$A$.\n\n2. \n\nKernel_$A$ resolves

\\mathsf{AIC}_{A}

and

\\mathsf{AIC}_{B}

, verifying both against\nthe GAR (signature validity, expiration, revocation status).\n\n3. \n\nKernel_$A$ generates a fresh nonce

n_{A}

(32 bytes, 60 s TTL) and\nsigns it:

\\sigma_{A}=\\mathsf{Sign}_{K_{\\mathsf{priv}}^{A}}(n_{A})

.\n\n4. \n\nThe challenge

(n_{A},\\sigma_{A})

is delivered to Kernel_$B$.\nKernel_$B$ verifies

\\sigma_{A}

against

K_{\\mathsf{pub}}^{A}

from

\\mathsf{AIC}_{A}

,\ngenerates a fresh nonce

n_{B}

, and signs:\n

\\sigma_{B}=\\mathsf{Sign}_{K_{\\mathsf{priv}}^{B}}(n_{B})

.\n\n5. \n\nKernel_$B$ returns

(n_{B},\\sigma_{B})

to Kernel_$A$.\nKernel_$A$ verifies

\\sigma_{B}

against

K_{\\mathsf{pub}}^{B}

from

\\mathsf{AIC}_{B}

.\n\n6. \n\nInfrastructure capability bound:\n

S_{\\text{infra}}=S_{\\max}^{A}\\cap S_{\\max}^{B}

.\n\n7. \n\nApplication-level policy (if registered for

B

): the\nresponder’s access policy evaluates

\\mathsf{AIC}_{A}

’s attributes and returns\n

({\\mathit{allowed}},\\;S_{\\text{policy}})

.\n\n8. \n\nSession capabilities:\n

S_{\\text{session}}=S_{\\text{policy}}\\cap S_{\\text{infra}}

.\n\n9. \n\nShared secret:\n

k=\\mathsf{H}(n_{A}\\,\\|\\,\\sigma_{A}\\,\\|\\,n_{B}\\,\\|\\,\\sigma_{B})

.\n\n10. \n\nKernel_$A$ issues session token

\\mathit{ST}_{A}

and Kernel_$B$ issues\n

\\mathit{ST}_{B}

, each with capabilities

S_{\\text{session}}

,\nshared secret

k

, and bounded TTL.\n\n\n\n

Remark (Deployment Topologies).

The protocol above is parameterized by the relationship between Kernel_$A$ and Kernel_$B$. Three instantiations cover the practical deployment spectrum:

Co-located (single kernel).: \n
\n
When $A$ and $B$ reside on the same host, Kernel_$A$ ${}={}$ Kernel_$B$ and\nsteps 3–5 collapse to kernel-internal operations with no network\nround-trip. This is the natural mode for DeepKernel-managed\nmulti-agent orchestration on a single device.
\n
Remote-mediated (Trusted Attestation Service).: \n
\n
A standalone service—architecturally identical to an agent kernel\nbut deployed as a remote endpoint—coordinates the exchange. Each\nagent’s designated kernel retains $K_{\\mathsf{priv}}$ and signs within its\ntrust boundary; the TAS relays challenges, caches GAR verification results, and issues session\ntokens. The TAS plays a role analogous to an OIDC Provider in human\nweb SSO: it centralizes session establishment while each agent\nretains sovereign control of its private key.
\n
Direct peer-to-peer.: \n
\n
Each kernel signs its own nonce and verifies the counterpart’s signature\nindependently via the GAR. No trusted intermediary is required.\nThis mode is fully decentralized but incurs higher latency: each side\nperforms an independent GAR round-trip, and every attestation requires\na full network challenge-response exchange. AIC caching with\nrevocation-push notifications (§10) can amortize\nthe GAR cost.
\n

The three modes can coexist within a single ecosystem: co-located\nattestation for intra-device workflows, mediated attestation for\norganizational clusters, and direct P2P for open cross-organization\ninteractions.

Anti-spoofing guarantees. \nSession tokens are bound to specific agent instances (AIC + execution\ncontext). Tokens expire on agent termination; replay is impossible because\nnonces are single-use and time-bounded. Private keys never leave the\nagent’s isolated kernel, so stolen tokens are useless outside the authorized\nexecution context.

6.2 AIC Delegation Chain

\n\n

In multi-agent orchestration scenarios, a parent agent often needs to\ndynamically spawn task-specific child agents. InterSAGE supports this through\nAIC delegation: the parent requests the kernel to issue a child AIC\nwith strictly attenuated capabilities, forming a cryptographic chain\nanalogous to an X.509 intermediate-CA hierarchy.

\n\nDelegation Protocol\n\n\n\n1. \n\nParent requests child AIC from the kernel, specifying desired\ncapabilities

S_{\\text{child}}\\subseteq S_{\\max}^{\\text{parent}}

.\n\n2. \n\nKernel verifies the parent’s AIC chain (iterative walk to GAR root).\n\n3. \n\nKernel checks:\n

S_{\\text{child}}\\subseteq S_{\\max}^{\\text{parent}}

\n(no capability escalation).\n\n4. \n\nKernel checks: delegation depth

\\leq

configured ceiling.\n\n5. \n\nKernel generates fresh Ed25519 keypair for the child.\n\n6. \n\nGAR issues child AIC signed by the parent’s key, with:\n\n• \n\n

S_{\\max}^{\\text{child}}=S_{\\text{child}}

\n\n• \n\nInherited tenant_id and\ndeployment_environment\n\n• \n\nValidity capped to parent’s remaining lifetime\n\n\n\n7. \n\nChild AIC is returned; parent-to-child link is recorded.\n\n\n\n\n\n\nFigure 4: Monotonic capability attenuation chain. Each party can only\nnarrow the boundary set by the preceding party. The runtime\nintersection further constrains per-invocation permissions.\n\n

The delegation mechanism provides six structural security properties:

Table 4: Security properties of AIC delegation.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Property	\n\nMechanism\n
Monotonic attenuation	\n\n $S_{\\max}^{\\text{child}}\\subseteq S_{\\max}^{\\text{parent}}$ enforced\ncryptographically at delegation time.\n
Tenant isolation	\n\nChild inherits tenant_id from parent; cross-tenant delegation is\nstructurally impossible.\n
Depth bounding	\n\n $d_{\\text{eff}}=\\min(d_{\\text{kernel}},\\,d_{\\text{request}})$ ; the\nrequest can only tighten, never loosen.\n
Cascading revocation	\n\nRevoking a parent AIC atomically revokes all descendants; chain\nverification fails for the entire subtree.\n
Validity capping	\n\nChild’s expires_at $\\leq$ parent’s expires_at;\nparent expiry cascades temporally.\n
Cycle resistance	\n\nIterative chain verification with visited set and hard hop cap; no\nrecursion overflow or cycle attacks.\n

\n\n

6.3 Two-Tier A2A Access Control

\n\n

A pure capability-intersection model (§6.1, step 6) is\nnecessary but insufficient: the responder agent may wish to restrict\ninteractions based on attributes beyond raw capabilities—for example,\nallowing only agents from trusted developers, requiring a minimum identity\nassurance level, or enforcing same-tenant isolation.

InterSAGE introduces a two-tier access control model that separates\nplatform-enforced trust from application-level policy:

1. \n
\n
Infrastructure tier (mandatory, kernel-enforced):\nCryptographic AIC verification via the GAR. This tier answers: “Is this\nagent who it claims to be?” Both parties’ AICs are verified for\nsignature validity, expiration, and revocation. The infrastructure\ncapability bound $S_{\\text{infra}}=S_{\\max}^{A}\\cap S_{\\max}^{B}$ is computed.
\n
2. \n
\n
Application tier (optional, agent-defined):\nThe responder agent registers a declarative access policy that\nevaluates the requester’s AIC attributes:
\n
- • \n
  \n
  Required capabilities (requester must possess specific caps)
  \n
- • \n
  \n
  Trusted developers (glob patterns on developer_id)
  \n
- • \n
  \n
  Trusted operators (glob patterns on operator_id)
  \n
- • \n
  \n
  Minimum identity assurance level (IAL threshold)
  \n
- • \n
  \n
  Maximum risk level
  \n
- • \n
  \n
  Same-tenant requirement
  \n
\n
The application tier answers: “Does this specific responder want to work\nwith this specific requester?” It produces a (possibly narrowed) set of\ngranted capabilities that is intersected with the infrastructure\nbound.
\n

The final session capability set is:

\n\n\n\n\n\n\n\n

S_{\\text{session}}=S_{\\text{policy}}\\cap\\bigl(S_{\\max}^{A}\\cap S_{\\max}^{B}\\bigr)

(2)

This two-tier design has three key advantages over single-layer approaches:

• \n
\n
Composability: Infrastructure and application concerns are\nindependently auditable and evolvable.
\n
• \n
\n
Backward compatibility: Agents without a registered policy\nfall back to the infrastructure tier alone.
\n
• \n
\n
Fine-grained control: The responder can make admission\ndecisions based on identity attributes that raw capability intersection\ncannot express.
\n

6.4 The Capability Narrowing Chain

\n\n

InterSAGE’s approach to authorization can be summarized as a four-stage\nnarrowing chain in which each stage can only tighten the permission\nboundary:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Stage 1:	Developer	declares	$S_{\\text{declared}}$
Stage 2:	Operator	selects	$S_{\\max}\\subseteq S_{\\text{declared}}$
Stage 3:	GAR	enforces & signs	$S_{\\max}$ (subset-checked, signed AIC)
Stage 4:	Runtime	intersects	$S_{\\text{session}}\\subseteq S_{\\max}^{A}\\cap S_{\\max}^{B}$

At no point can any party widen the boundary set by the preceding\nparty. This is enforced cryptographically: the developer’s signature covers\n $S_{\\text{declared}}$ ; the GAR’s signature covers $S_{\\max}\\subseteq S_{\\text{declared}}$ ; the session token is kernel-signed over\n $S_{\\text{session}}\\subseteq S_{\\max}^{A}\\cap S_{\\max}^{B}$ . Any attempt to insert\nadditional capabilities requires forging a signature.

This monotonic attenuation provides structural least-privilege: the\nproperty holds by construction, not by correct policy configuration.\nMisconfiguring a policy can deny legitimate access but can never grant\nunauthorized capabilities.

7 Layer 3: Accountability & Economics

\n\n

Layers 0–2 establish who an agent is, what it can do, and whom it trusts.\nLayer 3 closes the loop by ensuring that every agent action is\ntraceable, attributable, and economically accountable.\nThis layer addresses threats T5 (payment and usage fraud) and T6 (action\nrepudiation) from Table 1.

7.1 Token-Usage Tracing

\n\n

LLM-powered agents consume computational resources (inference tokens, tool\ninvocations, storage) on behalf of their operators. In multi-agent\nworkflows, a single user request may trigger cascading agent interactions,\neach consuming tokens from different LLM providers. Without identity-aware\nmetering, costs are attributed to API keys rather than to the agents (and\nultimately the humans) who authorized the work.

InterSAGE binds token-usage records to cryptographic agent identity:

\n\nToken-Usage Record\n\n\n\n\nagent_id\n

\\mathsf{DID}_{\\mathsf{agent}}

of the consuming agent\n\nsession_id\nsession token ID from Layer 2 attestation\n\nprovider\nLLM provider identifier\n\nmodel\nmodel name and version\n\ninput_tokens\nprompt token count\n\noutput_tokens\ncompletion token count\n\ntimestamp\nUTC timestamp\n\ndelegation_chain\nordered list of AIC IDs from root to leaf\n\nsignature\n

\\mathsf{Sign}_{K_{\\mathsf{priv}}}(\\text{record payload})

\n\n\n

The delegation chain field enables cost attribution up the delegation\ntree: if agent $C$ was delegated by agent $B$ , which was delegated by\nagent $A$ (the root), the usage record traces the cost back to $A$ ’s\noperator. Combined with the AIC’s operator identity (OIDC-bound), this\nenables precise per-user, per-agent cost allocation in multi-tenant\nenvironments.

7.2 Payment Primitives

\n\n

As agents increasingly provide services to other agents (e.g., a code-review\nagent charging per review, a data-analysis agent billing per query), the\nInternet of Agents requires payment primitives that are identity-aware and\nauditable.

InterSAGE defines a minimal payment protocol framework built on Layer 0–2\nprimitives:

1. \n
\n
Price advertisement: An agent’s registration record\n(Layer 1) includes optional pricing metadata (rate type, currency, unit).
\n
2. \n
\n
Payment negotiation: During mutual attestation (Layer 2),\nthe requester and responder can negotiate payment terms as part of the\nsession establishment. Payment terms are included in the session token\nmetadata.
\n
3. \n
\n
Service delivery with metering: During the session, both\ntoken usage and service-specific metering events are recorded with\nidentity-signed records (§7.1).
\n
4. \n
\n
Settlement: After service completion, the metering records\nserve as cryptographically verifiable invoices. Settlement can occur\nthrough traditional payment rails, escrow services, or—for environments\nthat support it—on-chain settlement [10].
\n

InterSAGE is deliberately agnostic about the settlement mechanism: it provides the\nidentity and metering infrastructure that any payment system requires,\nwithout mandating a specific payment rail. This follows Principle P3 (no\ninfrastructure lock-in). Notably, Google’s Agent Payments Protocol\n(AP2) [45] is a recent open specification for AI-driven\nagent payments, focusing on the settlement rail and transaction flow. InterSAGE and AP2 are complementary: AP2 defines how\nagents pay, while InterSAGE defines who is paying whom and with what\nauthority, binding every payment event to a verified cryptographic\nidentity and a capability-bounded session.

7.3 Action Accountability

\n\n

Every action an agent takes—tool invocations, delegations, message\nexchanges—generates an execution trace entry that is\ncryptographically signed by the agent’s kernel-held private key:

\n\nTrace Entry\n\n\n\n\ntrace_id\nunique identifier\n\nagent_id\n

\\mathsf{DID}_{\\mathsf{agent}}

of the acting agent\n\naction_type\ntool_call

|

delegation

|

message

|

payment\n\naction_params\nstructured parameters of the action\n\naction_result\noutcome or status\n\nsession_id\nsession context (from Layer 2)\n\ntimestamp\nUTC timestamp\n\nprev_hash\nhash of the preceding trace entry (chain integrity)\n\nsignature\n

\\mathsf{Sign}_{K_{\\mathsf{priv}}}(\\text{entry payload}\\,\\|\\,\\text{prev\\_hash})

\n\n\n

The prev_hash field chains trace entries into a hash-linked log,\nproviding tamper evidence: any modification to\na historical entry breaks the hash chain from that point forward. The\nsignature binds each entry to its agent’s cryptographic identity, providing\nnon-repudiation.

Key gains of kernel-mediated accountability. \nWhat distinguishes InterSAGE’s accountability model from application-level\nlogging or blockchain-anchored ledgers is its reliance on trusted,\nkernel-mediated cryptography. The kernel (whether running locally or as a\nremote service) provides a verifiable, isolated trust boundary, typically\nanchored by hardware mechanisms like Trusted Execution\nEnvironments (TEEs) and secure boot. Because the agent’s private key $K_{\\mathsf{priv}}$ never leaves\nthis kernel, the architecture yields three key gains:\n(1) Decentralized non-repudiation: agents can cryptographically prove\ntheir execution history and attribute costs without relying on a global\nconsensus ledger or trusted third-party auditor.\n(2) Deployment ubiquity: immutable audit trails can be maintained even\nin air-gapped, edge, or resource-constrained environments where blockchain\nnodes are economically or technically unviable.\n(3) Compromise containment: because the application logic cannot access\nthe raw signing key or rewrite historical logs, an attacker compromising the\nagent’s LLM or memory cannot forge retroactive trace entries, guaranteeing\nthe integrity of the audit trail up to the exact moment of breach.

Contrast with BlockA2A. \nIn BlockA2A [23], audit trails were anchored to a blockchain via\nMerkle proofs, providing immutability backed by distributed consensus. InterSAGE achieves comparable tamper-evidence through identity-signed hash chains,\nwhich work in any environment. For deployments requiring stronger\nimmutability guarantees, the hash chain root can be periodically anchored to\na public timestamping service or distributed ledger.

7.4 Non-Repudiation

\n\n

Non-repudiation in InterSAGE rests on two pillars:

1. \n
\n
Kernel-mediated signing: The agent’s private key\n $K_{\\mathsf{priv}}$ is held exclusively by the kernel. All signing operations\n(attestation challenges, session tokens, trace entries, usage records)\nare mediated by the kernel’s signing API. The agent’s application logic\ncannot forge signatures because it never has access to the raw key.
\n
2. \n
\n
AIC chain binding: Every signature can be verified against\nthe agent’s AIC, which chains back to the GAR root key. The verifier\nneeds only the GAR’s public key (a well-known trust anchor) to validate\nany trace entry from any agent in the ecosystem.
\n

Together, these mechanisms ensure that if a trace entry bears a valid\nsignature under an agent’s $K_{\\mathsf{pub}}$ , and the agent’s AIC chain verifies back\nto the GAR root, then the named agent did perform the recorded action.\nThe agent cannot repudiate it without claiming that the kernel was\ncompromised—a claim that can be evaluated against the key protection tier\n(Table 3) and deployment attestation records.

8 Security Analysis

\n\n

A protocol suite spanning identity, discovery, trust negotiation, and accountability must be evaluated by whether its properties hold jointly under a defined attacker model. This section provides a rigorous, property-centric security evaluation of InterSAGE. Table 5 summarizes the security properties provided by InterSAGE.

8.1 Threat Model and Assumptions

\n\n

We assume a Dolev-Yao network adversary [46] capable of intercepting, replaying, and injecting messages across all network paths. Crucially, the adversary is augmented with LLM-level compromise capabilities: it can control an agent’s application logic, issue arbitrary API calls, and observe context data (e.g., via prompt injection or malicious memory retrieval). However, the attacker cannot extract the agent’s private key $K_{\\mathsf{priv}}$ from the underlying kernel or compromise the kernel’s signing API.

Our evaluation rests on three cryptographic and structural assumptions: (1) GAR Honesty: The Global Agent Registry root key is uncompromised and accurately verifies developer/operator bindings during AIC issuance. (2) Kernel Integrity: The agent’s key-custody layer (the kernel) enforces delegation bounds and never signs payloads without authorization. (3) Cryptographic Soundness: Ed25519 provides existential unforgeability (EUF-CMA) and $\\mathsf{H}$ is collision-resistant. Graceful degradation assumptions, such as loose time synchronization and OIDC provider honesty, limit the scope of localized failures without causing systemic compromise.

Table 5: Security properties of the InterSAGE protocol suite. Threats refer to Table 1.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

\n\nProperty\n	\n\nMechanism\n	\n\nGuarantee Level\n	\n\nThreats\n
\n\nIdentity Integrity\n	\n\nFour-dimensional AIC binding, GAR root anchor\n	\n\nCryptographic\n	\n\nT1, T4\n
\n\nCapability Confinement\n	\n\nMonotonic attenuation chain, two-tier access control\n	\n\nStructural\n	\n\nT2\n
\n\nDelegation Safety\n	\n\nSubset enforcement, depth bounds, tenant isolation\n	\n\nCrypto + Structural\n	\n\nT2, T3\n
\n\nDiscovery Integrity\n	\n\nVerifiable credentials, supply-chain validation\n	\n\nVerifiable Cred.\n	\n\nT1, T2\n
\n\nAccountability\n	\n\nKernel-mediated signing, hash-linked execution logs\n	\n\nCryptographic\n	\n\nT5, T6\n

\n\n

8.2 Property-Centric Security Evaluation

\n\n

We prove that InterSAGE satisfies its core security properties under the defined threat model, directly neutralizing threats T1–T6 (Table 1).

Identity & Authenticity (T1, T4). \nAn adversary attempting to spoof an agent’s identity (T1) must forge the Agent Identity Credential (AIC). The AIC requires four independently verified signatures: developer code-package digest, build pipeline attestation, OIDC operator binding, and the final GAR endorsement. Because each dimension is cryptographically bound and verified prior to GAR issuance, single-dimension compromise (e.g., a rogue OIDC provider) cannot yield full identity forgery. At runtime, mutual attestation defeats replay attacks by requiring fresh nonce signing, proving possession of $K_{\\mathsf{priv}}$ . Furthermore, the GAR acts as a shared root of trust, enabling cross-domain verification (T4) via a single AIC chain, eliminating the need for pairwise trust agreements.

Capability Confinement & Delegation Safety (T2, T3). \nInterSAGE neutralizes capability escalation (T2) structurally. The monotonic attenuation chain ensures that permissions can only be narrowed at each delegation stage (developer $\\to$ operator $\\to$ GAR $\\to$ session). For any chain $\\mathsf{AIC}_{0}\\to\\dots\\to\\mathsf{AIC}_{n}$ , the invariant $S_{\\max}^{\\mathsf{AIC}_{n}}\\subseteq\\dots\\subseteq S_{\\max}^{\\mathsf{AIC}_{0}}$ is enforced cryptographically; violating it requires forging a signature at a prior stage. At runtime, the two-tier access control model computes $S_{\\text{session}}=S_{\\text{policy}}\\cap(S_{\\max}^{A}\\cap S_{\\max}^{B})$ . Even if the application-level policy ( $S_{\\text{policy}}$ ) is compromised or misconfigured, it cannot grant access beyond the cryptographically verified infrastructure bound. Delegation abuse (T3) is prevented via depth bounding, strict validity capping, tenant isolation, and cascading revocation, ensuring delegation cannot be used as a capability-laundering channel.

Discovery Integrity (T1, T2). \nExisting discovery directories suffer from self-declared, unverified claims. InterSAGE transforms discovery into a verify-then-interact boundary using Verifiable Credentials (VCs). An agent cannot advertise unauthorized skills because manifest VCs undergo strict verification: supply-chain signature checks, subject binding against the presenter’s $\\mathsf{DID}_{\\mathsf{agent}}$ , and permission alignment against the agent’s $S_{\\max}$ . Consequently, discovery cannot serve as an implicit escalation path.

Accountability & Non-repudiation (T5, T6). \nAction repudiation (T6) and usage fraud (T5) are mitigated without relying on distributed consensus. Every operational trace entry is signed by $K_{\\mathsf{priv}}$ under kernel mediation. Since application logic never possesses $K_{\\mathsf{priv}}$ , an LLM-compromised agent cannot forge signatures. Furthermore, trace entries are linked via cryptographic hashes (prev_hash); an attacker modifying past entries invalidates the chain. Hence, usage records remain cryptographically attributable up the delegation tree to a human-accountable operator.

8.3 Security under Composition

\n\n

A common pitfall in protocol design is composition failure, where security properties holding in isolation break when layers interact. InterSAGE achieves composition safety through strict downward-only dependencies and independent failure domains. The guarantees of higher layers rely only on the invariants of lower layers, never the reverse. For instance, L2 session capability intersection relies on L0’s AIC integrity; however, a misconfigured L2 application policy cannot widen L0’s cryptographic capability boundary. Similarly, L3 accountability depends solely on L0’s kernel-mediated key custody, remaining tamper-evident regardless of L1 discovery mechanisms or L2 trust negotiation flaws. This structural isolation ensures that a compromise at the application or discovery layer cannot weaken the cryptographic and identity invariants enforced by the infrastructure.

8.4 Comparison and Residual Risks

\n\n

Table 6 illustrates InterSAGE’s structural guarantees compared to AgentMesh [19], AIP [21], and BlockA2A [23] under specific failure scenarios. Where existing approaches rely on correct runtime policy configuration (e.g., AgentMesh) or omit protocol-level delegation attenuation (e.g., BlockA2A), InterSAGE provides cryptographic bounds that fail closed independently of the policy engine.

Table 6: Security guarantee comparison under failure scenarios.

\\checkmark

= guarantee holds,

\\times

= guarantee breaks,

\\triangle

= bounded break.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

\n\nScenario\n	\n\nInterSAGE\n	\n\nAgentMesh [19]\n	\n\nAIP [21]\n	\n\nBlockA2A [23]\n
\n\nPDP misconfigured to allow tools:*\n	\n\n $\\checkmark$ (bound by $S_{\\max}$ intersection)\n	\n\n $\\times$ (single-PDP silently grants access)\n	\n\n $\\triangle$ (depends on Datalog correctness)\n	\n\n $\\checkmark$ (smart contract enforced)\n
\n\nOperator credential compromised\n	\n\n $\\triangle$ (developer + code signatures remain valid)\n	\n\n $\\times$ (workload impersonation)\n	\n\n $\\times$ (root issuer mints full capabilities)\n	\n\n $\\triangle$ (no dev/operator separation)\n
\n\nChild escalating beyond parent’s $S_{\\max}$ \n	\n\n $\\checkmark$ (cryptographic subset enforcement)\n	\n\n $\\triangle$ (runtime policy error enables escalation)\n	\n\n $\\checkmark$ (attenuation at token level)\n	\n\n— (no protocol-level delegation attenuation)\n
\n\nAttacker rewrites past execution logs\n	\n\n $\\checkmark$ ( $K_{\\mathsf{priv}}$ kernel-mediated, hash chain)\n	\n\n $\\triangle$ (application-level logging)\n	\n\n $\\triangle$ (application-level logging)\n	\n\n $\\checkmark$ (blockchain immutability)\n

\n\n

Scope Boundaries. \nCertain risks fall explicitly outside InterSAGE’s protocol scope. InterSAGE secures identity and authorization limits, not cognitive correctness. If an agent suffers a prompt injection that causes it to misuse its authorized capabilities, this is an LLM-level cognitive failure rather than a protocol flaw. Furthermore, catastrophic infrastructure compromise (e.g., GAR root key theft) or hardware-level key extraction (bypassing the kernel) represent ultimate trust boundaries mitigated by external operational security measures, such as HSMs and Trusted Execution Environments (TEEs), rather than protocol-level invariants.

9 Related Work

\n\n

How we contrast InterSAGE with prior work. \nWe organize the rapidly growing body of agent protocol and security\nresearch into six clusters and contrast InterSAGE with each using a uniform\nthree-step pattern: (i) the goal or mechanism that InterSAGE shares\nwith the cluster, (ii) the specific point of divergence, named\nin the canonical vocabulary of persistent identity,\ncapability-aware discovery, trust negotiation, and accountability, and\n(iii) the operationally observable consequence—typically a\nconcrete attacker action or misconfiguration that InterSAGE structurally\ndenies and the comparator catches only via runtime policy evaluation,\nbehavioral attestation, or operator vigilance. We use this pattern\nbecause it forces every distinction claim to be grounded in mechanism\nrather than rhetoric.

What InterSAGE inherits. \nInterSAGE is not built from scratch. It inherits decentralized identifiers\nand verifiable credentials from the W3C and SSI lineage, SPIFFE-style\nworkload attestation, OAuth/OIDC scoping vocabulary, capability tokens\nin the UCAN/Biscuit lineage, the idea of monotonic attenuation as a\ndelegation discipline, signed software manifests, and tamper-evident\nhash-chained audit. InterSAGE’s\ncontribution is the architecture that combines and structurally\nenforces these primitives within a single coherent four-layer trust\nplane; we therefore foreground the conjunction rather than any\nindividual primitive.

Table 7 compares InterSAGE with representative approaches across\nthirteen evaluation dimensions ordered to mirror the four-layer trust\nsubstrate in Figure 1. Layer 0 (Agent\nIdentity) uses rows 1–2 (persistent identity,\nfour-dimensional binding). Layer 1 (Discovery) uses\nrows 3–4 (capability-aware discovery, verifiable\nmanifests). Layer 2 (Trust Negotiation) uses rows 5–8 in the\nsame sequence as §3.2: mutual attestation,\nmonotonic attenuation, two-tier access control, then\ndelegation chains. Layer 3 (Accountability) uses\nrows 9–12 in the same sequence as §7:\ntoken-usage tracing, payment primitives, action\naccountability, non-repudiation. Row 13 is cross-cutting\ndeployment generality (independent of any single layer).

Table 7: Comparison of InterSAGE with representative agent security approaches.\n

\\bullet

= comprehensive support,

\\circ

= partial\nsupport, — = not addressed.\nRows follow the InterSAGE four-layer suite (Figure 1): L0\nAgent Identity (1–2), L1 Discovery (3–4), L2 Trust Negotiation (5–8\nin protocol flow order), L3 Accountability (9–12), then deployment\ngenerality (13). The leftmost column labels the protocol layer for each\nblock; Cross marks a cross-cutting deployment dimension.\nFor deployment generality:\n

\\bullet

= cloud + edge + air-gapped,\n

\\circ

= cloud-only or specific infrastructure,\n— = blockchain required.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

\n\nLayer\n	Dimension	\n \n InterSAGE \n	\n \n AgentMesh \n	\n \n AIP \n	\n \n HDP \n	\n \n ANP \n	\n \n Ag-OSI \n	\n \n ZT-IAM \n	\n \n BlockA2A \n
\n\nL0\n	Persistent identity	$\\bullet$	$\\bullet$	$\\circ$	—	$\\circ$	$\\circ$	$\\bullet$	$\\bullet$
	4-dim binding	$\\bullet$	$\\circ$	—	—	—	—	$\\circ$	—
\n\nL1\n	Capability-aware discovery	$\\bullet$	$\\circ$	—	—	$\\circ$	$\\circ$	$\\circ$	—
	Verifiable manifests	$\\bullet$	—	—	—	—	—	$\\circ$	—
\n\nL2\n	Mutual attestation	$\\bullet$	$\\circ$	$\\circ$	—	$\\circ$	—	$\\circ$	$\\circ$
	Monotonic attenuation	$\\bullet$	—	$\\circ$	—	—	—	—	—
	Two-tier access control	$\\bullet$	—	—	—	—	—	—	$\\circ$
	Delegation chains	$\\bullet$	$\\circ$	$\\circ$	$\\bullet$	—	—	$\\circ$	—
\n\nL3\n	Token-usage tracing	$\\bullet$	$\\circ$	—	—	—	—	—	—
	Payment primitives	$\\bullet$	—	—	—	—	$\\bullet$	—	—
	Action accountability	$\\bullet$	$\\bullet$	$\\circ$	$\\circ$	—	$\\circ$	$\\circ$	$\\bullet$
	Non-repudiation	$\\bullet$	$\\circ$	$\\circ$	$\\circ$	—	—	—	$\\bullet$
\n\nCross\n	Deployment generality	$\\bullet$	$\\circ$	$\\bullet$	$\\bullet$	$\\circ$	—	$\\circ$	—

\n\n

9.1 Communication Stacks vs. Security-First Substrates

\n\n

A first cluster of work designs communication-first stacks for the\nInternet of Agents. Fleming et al. [11] propose reference layers for agent\ncommunication (L8) and semantics (L9) atop TCP/IP (outside the classical OSI\nmodel);\nAgent-OSI [10] proposes a six-layer decentralized stack with\nidentity, settlement, and provenance; ACPS [14] defines\nregistration, discovery, interaction, and tooling protocols; Coral\nProtocol [29] provides open infrastructure for\ncommunication, coordination, trust, and payments; the OpenAgents\nNetwork Model [47] defines an event-centered\nnetwork abstraction with scoped networks, routable addresses, mods,\nresources, discovery, and transport bindings; Du\net al. [48] analyze agent communication from five\nclassical Internet-architecture perspectives; the IoA framework of Chen\net al. [4] and the survey by Wang\net al. [9] provide ecosystem perspectives; and\nGoogle’s Agent Payments Protocol (AP2) [45] is a prominent\nopen effort focused on AI-driven agent payments. A parallel cluster of comparative\nsurveys [12, 13, 30, 49, 50, 51, 52]\ncatalog and compare these efforts (including landscape surveys with limited\nsecurity depth, such as [50, 51]); across these surveys, security is\ntypically treated as one dimension among several rather than as a dedicated,\ncryptographically bound trust layer.

Relation to InterSAGE. \nInterSAGE shares with these works the goal of supporting interoperable\nmulti-agent collaboration; it diverges by being a security-first\nprotocol suite that is agnostic to the underlying communication stack,\nand is therefore designed to complement rather than compete with\nany of the architectures above. In particular, OpenAgents is best\nunderstood as a network model rather than an in-depth security or\nverifiability design: its verification levels and guard mods name where\nauthentication, access control, and rate limiting can occur, but they do\nnot specify AIC-style multi-dimensional identity binding, signed\ncapability manifests, monotonic attenuation, two-tier authorization, or\ntamper-evident audit. Similarly, while ANP [8] uses\nW3C DIDs for discovery and mutual verification, its published design does\nnot specify structured delegation chains or a tamper-evident accountability\nlayer comparable to InterSAGE; attestation and access control are lighter than\ncryptographically bound, challenge-response attestation with monotonic\ncapability attenuation. Agent-OSI [10] provides comprehensive\nlayering and prototypes on-chain escrow and verification in its reference\nimplementation, limiting deployment generality where blockchain is required. The observable consequence is that InterSAGE can layer\non top of MCP, A2A, ANP, ACPS, Agent-OSI, or OpenAgents-style event\nnetworks without changes to the host protocol’s wire format.

9.2 Single-Dimension IAM vs. Multi-Dimensional Binding

\n\n

A second cluster retrofits human-IAM primitives onto agent flows. The\nOpenID Foundation’s strategic agenda [25] catalogs the\ngaps in extending OAuth 2.0 and OpenID Connect to agentic\nauthorization; OIDC-A [24] is the most concrete OIDC extension\nto date, defining standard claims for agent identity, attestation, and\ndelegation chains. South et\nal. [36, 53]\nextend OAuth 2.0 with agent-specific credentials and natural-language\npermission scoping. Bhushan et al. [37] provide a\nfive-pattern taxonomy organizing SPIFFE/SPIRE, OAuth 2.0, OIDC, Token\nExchange, DPoP, CIBA, and decentralized identity by interaction type\n(user-to-agent, orchestrator-to-agent, agent-to-internal,\nagent-to-external, cross-domain federation). On the\ndecentralized-identity side, Aydeger and\nZeydan [54] integrate SSI with LLM agents\non a blockchain backend; AGNTCY Identity [55] and\nBillionsNetwork [56] provide open-source\ntoolkits using W3C VCs and the iden3 protocol respectively.

Relation to InterSAGE. \nInterSAGE shares with this cluster the use of standardized credential\nformats and the goal of cross-domain agent authentication. It diverges\nby defining an agent-native AIC lifecycle whose four-dimensional\nbinding (developer, code package, operator, context) is signed at\nissuance, rather than treating the agent as a single OAuth client or a\nsingle VC holder. The consequence is that an attacker who steals an\noperator’s OAuth client secret or who phishes a holder key cannot\nsilently substitute a different code package or claim a different\ndeveloper, because each dimension carries its own independently\nverifiable signature—a property no OAuth or single-holder DID\nextension provides.

9.3 Directory Discovery vs. Capability-Aware Manifests

\n\n

A third cluster builds zero-trust identity and discovery infrastructure\nfor agents. The DID/VC + Agent Name Service strand—Huang\net al.’s zero-trust framework with DIDs, VCs, ANS, and ZKPs [41],\nthe ANS itself as a DNS-inspired PKI directory [57], and Garzon\net al.’s ledger-anchored DID/VC prototype for cross-domain LLM-agent\nauthentication [43]—focuses on discovery and\nauthentication. The SPIFFE-on-Kubernetes strand—Huang and Hughes’s\nSpringer chapter on agentic AI identity\nsecurity [39], Pappu et al.’s\nSPIFFE-based zero-trust authentication [40],\nBhushan’s explainable zero-trust framework [58], and\nPalavali’s SSI-for-microservices framework [59]—focuses\non workload attestation and short-lived credentials. A third\nstrand frames the problem at the enterprise governance layer:\nRamachandran and Mishra’s identity-aware\ngovernance [22] explicitly proposes\nambient-authority elimination, infrastructure-level policy\nenforcement, sequence-aware authorization, independent action\nverification, and hallucination-aware audit, and grounds these in\ndocumented production incidents.

Relation to InterSAGE. \nInterSAGE shares with this cluster the zero-trust posture and the use of\nDID/SPIFFE-style cryptographic identity. It diverges in two ways. First,\nthe DID/VC works typically bind only the holder dimension and\nthe SPIFFE works only the workload-instance dimension; InterSAGE’s\nAIC binds developer, code package, operator, and context as\nindependently signed dimensions, so the four-dimensional binding\nstrictly subsumes both. Second, the enterprise-governance proposals\nshare InterSAGE’s two-tier intuition (separating infrastructure from\napplication policy) but realize it through a single PDP at the\ninfrastructure layer; InterSAGE realizes it as two independent evaluation\npaths with independent failure semantics. The consequence is that a\nPDP misconfiguration in the application tier cannot weaken\ncryptographic AIC verification in the infrastructure tier, and vice\nversa—each tier fails closed independently.

9.4 Policy-Evaluated vs. Structurally-Attenuated Delegation

\n\n

A fourth cluster focuses specifically on delegation chains as\nfirst-class protocol artifacts. We discuss this cluster in detail\nbecause it is where the monotonic-capability-attenuation primitive of\nInterSAGE has the closest competitors.

AIP [21] introduces Invocation-Bound Capability Tokens\n(IBCTs) that fuse identity, attenuated authorization, and provenance\ninto an append-only token chain, with compact (signed JWT) and chained\n(Biscuit/Datalog) wire formats and transport bindings for MCP, A2A,\nand HTTP. LDP [60] extends this with rich delegate\nidentity cards carrying quality hints, governed sessions, and trust\ndomains as protocol-level boundaries. HDP [61] (an IETF\nInternet-Draft) provides a lightweight Ed25519 hop-chain dedicated to\nhuman delegation provenance in agentic systems. Saavedra’s\nframework [26] introduces Delegation Grants\n(DGs)—first-class authorization artifacts with explicitly enforced\nscope reduction—together with a Canonical Verification Context, a\nTrust Gateway, and optional blockchain anchoring. South et\nal.’s authenticated delegation [36, 53] extends OAuth 2.0/OIDC with\nagent-specific credentials and natural-language scoping for delegation\nchains.

Relation to InterSAGE. \nAll five works share with InterSAGE the goal of bounding what a delegated\nagent may do and producing an auditable chain of authority; AIP and\nSaavedra’s DGs go furthest by making attenuation a structural property\nof the credential rather than only a runtime check. The divergences\nare mechanism-specific. AIP’s attenuation is invocation-scoped\nand policy-evaluated: each IBCT carries Datalog rules\nre-evaluated at every hop, and the verifier must run a Datalog engine\nto reject a malformed token. InterSAGE’s attenuation is\nlifecycle-scoped and intersection-evaluated: the\ncapability boundary is signed into the AIC at issuance and every\nsubsequent narrowing reduces to set-intersection plus signature\nverification—no Datalog runtime, no per-hop policy interpretation.\nNeither AIP nor Saavedra’s DGs separate developer from\noperator as distinct issuance stages, so a compromised AIP\nroot issuer or a compromised DG-issuing trust gateway can mint a\ncredential with the full upstream capability set; InterSAGE’s\nfour-dimensional binding makes the developer-declared boundary and\nthe operator-provisioned subset two distinct cryptographic stages, so\nan operator-tier compromise structurally cannot escalate beyond the\ndeveloper-tier boundary. HDP and the OAuth-extension delegation\nproposals address human-to-agent provenance and OAuth compatibility\nrespectively, but do not extend monotonic attenuation across the\nmulti-stage agent supply chain. The observable consequence is that\nthe two attack categories that AIP’s chained model uniquely catches\n(delegation-depth violations and audit evasion via empty\ncontext [21]) are also caught by InterSAGE, plus a third\ncategory—operator-tier capability widening—that AIP’s\nsingle-issuer model does not catch.

9.5 Conformance Testing vs. Cryptographic Enforcement

\n\n

A fifth cluster articulates security principles and threat models for\nthe agentic ecosystem rather than full protocols. AgentRFC [16]\nis the closest principles framework to InterSAGE: it defines a six-layer\nAgent Protocol Stack analogous to ITU-T X.800 for OSI, formalizes\neleven security principles as TLA+ invariants with an explicit\nproperty taxonomy (spec-mandated, spec-recommended, AASM-hardening,\nAPS-completeness), and introduces the Composition Safety\nprinciple—the observation that security properties holding for\nindividual protocols can break when protocols are composed through\nshared infrastructure. The AgentConform tooling extracts normative\nclauses into a typed Protocol IR and model-checks the resulting TLA+\nmodel. Anbiaee et al. [17] present\ncomparative threat modeling across MCP, A2A, Agora, and ANP and\nenumerate twelve protocol-level risks. Wibowo and\nPolyzos [18] argue that agentic safety is an architectural\nprinciple rather than an add-on, and bottom-up deconstruct single-,\nmulti-, and interoperable-multi-agent stacks. Chaffer’s “Know Your\nAgent” [62] proposes a governance frame centered on\nidentity verification, behavioral monitoring, and accountability; the agent discovery survey by Guo\net al. [52] introduces a two-stage\ncapability-discovery framework with semantic modeling.

Relation to InterSAGE. \nInterSAGE shares with AgentRFC the diagnosis that agent protocols need a\nprincipled security framework, and we adopt the Composition Safety\nprinciple in our threat model (§2.2). The\ndivergence is that AgentRFC’s invariants are model-checked\nproperties intended for conformance testing of independent protocols,\nwhereas InterSAGE’s invariants are cryptographically structural—the\nmonotonic capability attenuation chain enforces the bound at the\ncredential level, not at the spec-conformance level. The consequence\nis complementary: AgentRFC can flag where existing specs leave\nComposition Safety gaps; InterSAGE provides a credential format that\ncloses those gaps by construction. The threat-modeling and\ngovernance-framework works are likewise complementary—they identify\nrisks that InterSAGE is designed to neutralize architecturally rather than\narticulate.

9.6 Single-Plane Overlays vs. Two-Tier Authorization

\n\n

The sixth cluster contains the two industry- or industry-adjacent\nefforts that share InterSAGE’s framing as a trust layer added on top of\nexisting communication protocols: Microsoft’s\nAgentMesh [19] and Huang et al.’s unified zero-trust\narchitecture for the agentic web [20].

AgentMesh. \nAgentMesh, released as part of the Agent Governance Toolkit, is marketed in\nits documentation as “SSL for AI agents” (Public Preview). It organizes its architecture into\nfour layers: (i) an identity and zero-trust core using Agent CA with\nSPIFFE/SVID identities and Ed25519 or ML-DSA-65 signatures; (ii) a\ntrust and protocol bridge that translates between A2A, MCP, and IATP\nwith capability scoping; (iii) a compliance and policy plane; and\n(iv) a reward and learning engine. Project documentation claims alignment\nwith the OWASP Agentic Top 10 categories and ships an MCP proxy.

Relation to InterSAGE. \nInterSAGE and AgentMesh share the high-level goal of adding a trust layer\nto the multi-agent ecosystem and both use signed credentials for\nidentity. They differ in five mechanism-level ways, each with a\nconcrete observable consequence:

1. \n
\n
Identity model. AgentMesh’s SPIFFE-based identity\nbinds a key to a single workload instance; InterSAGE’s AIC binds\ndeveloper, code package, operator, and operational context as\nfour independently signed dimensions. Consequence: an\nattacker who compromises an AgentMesh workload signs valid SVIDs\nfor the workload’s identity but cannot prove anything about its\ncode provenance; under InterSAGE, the same compromise cannot\nimpersonate a different developer or substitute a different code\npackage because the developer and code-package signatures are\nindependent of the operator-tier credential.
\n
2. \n
\n
Bound enforcement: structural vs. policy-based.\nAgentMesh enforces least-privilege through a runtime policy\nengine: a misconfigured policy rule (e.g., a tenant operator\naccidentally granting tools:*) can silently grant\nexcessive access. InterSAGE’s monotonic capability attenuation chain\nencodes the bound at credential issuance, so the same policy edit\ncannot widen capability beyond the developer-declared boundary\nregardless of any subsequent runtime policy decision.\nConsequence: InterSAGE remains safe under PDP misconfiguration\nin a way AgentMesh does not.
\n
3. \n
\n
Access-control architecture. AgentMesh uses a single\npolicy plane that conflates cryptographic verification with\ndeclarative authorization. InterSAGE’s two-tier access control keeps\ninfrastructure-tier checks (AIC validity, capability\nintersection) on a separate evaluation path from application-tier\ndeclarative rules. Consequence: an application-tier\nregression cannot weaken cryptographic checks, and an\ninfrastructure-tier credential lapse cannot bypass per-agent\nauthorization—each failure mode is independently auditable.
\n
4. \n
\n
Protocol relationship. AgentMesh ships explicit\nA2A/MCP/IATP protocol translators; InterSAGE is protocol-agnostic and\nprovides trust primitives that any host protocol can bind to.\nConsequence: InterSAGE does not require a translator update to\nsupport a new host protocol, and protocol additions do not\nexpand the trust-layer attack surface.
\n
5. \n
\n
Scope. AgentMesh embeds a reward and learning engine\nfor adaptive governance. InterSAGE deliberately confines itself to\nthe trust and accountability layer and treats adaptive behavior\nas orthogonal. Consequence: InterSAGE’s verifier semantics\nremain pure cryptographic checks, simplifying formal verification\nand audit.
\n

Unified zero-trust architecture (Huang et al.). \nInterSAGE’s closest academic comparator is Huang\net al.’s unified zero-trust architecture [20], which\nlikewise proposes a unified zero-trust architecture for the agentic web.\nIt builds on DIDs, VCs, and ANS for identity and discovery and adds\nthree mechanisms: Trust-Adaptive Runtime Environments (TARE), Causal\nChain Auditing, and Dynamic Identity with Behavioral Attestation. It\nshares with InterSAGE the diagnosis that the agentic web needs a unified\ntrust layer; it diverges by enforcing trust through runtime\nbehavioral attestation and trust scoring rather than through\nissuance-time cryptographic attenuation. The observable consequence is\nthat an agent whose behavior has not yet diverged from baseline\nreceives a high trust score from TARE even if its capability\nboundary has been silently widened upstream; under InterSAGE the same\nagent’s AIC-bounded capability set is unchanged regardless of\nbehavioral history.

9.7 Our Prior Work: BlockA2A

\n\n

BlockA2A [23] introduced a unified multi-agent trust\nframework combining DIDs for cross-domain authentication,\nblockchain-anchored ledgers for immutable audit, and smart contracts\nfor dynamic access control. It demonstrated effective defense against\ndiverse MAS attacks and practical integration with A2A [6].

Evolution to InterSAGE. \nInterSAGE preserves BlockA2A’s core security ambitions (unified trust,\nimmutable audit, dynamic access control) while making three key\nadvances: (1) removing the blockchain dependency in favor of\ngeneral-purpose cryptographic primitives, broadening deployment to\nedge and air-gapped environments; (2) introducing layer-aligned\nprimitives for persistent identity, capability-aware discovery, trust\nnegotiation, and accountability, whereas BlockA2A approximated\nidentity and authorization only at the smart-contract policy level; and\n(3) adding DID-bound skill/tool manifest VCs, payment, and token-usage\ntracing capabilities that BlockA2A did not address. InterSAGE can be\nviewed as the generalization of BlockA2A from a blockchain-specific\nrealization to a deployment-agnostic protocol suite.

9.8 Summary: the Joint-Coverage Argument

\n\n

Each of InterSAGE’s primitives is anticipated by at least one prior work\nsurveyed above: DID/VC and SPIFFE precede the AIC’s identity\nmachinery; UCAN, Biscuit, AIP IBCTs, and Saavedra DGs precede the\nattenuation discipline; AgentMesh’s policy plane and the enterprise\ngovernance frameworks precede the two-tier intuition; AgentRFC\nprecedes the principled-invariants framing; and BlockA2A precedes\nthe unified-trust ambition. InterSAGE’s contribution is twofold.

First, InterSAGE deepens each primitive beyond its nearest\npredecessor. Where SPIFFE, OAuth, and DIDs each bind a single\nidentity dimension, the AIC binds four independently signed\ndimensions so that compromising one tier cannot impersonate another.\nWhere A2A Agent Cards and ANP’s DID-based discovery treat skill and tool\nadvertisements as self-declared descriptions, InterSAGE represents each\nskill and tool as a DID-bound Verifiable Credential that is verified\nfor supply-chain authenticity, subject binding, and permission\nalignment at discovery time—making discovery a trust-establishing\nsecurity boundary rather than a directory lookup.\nWhere AIP and Saavedra DGs attenuate capabilities via per-hop\nDatalog or runtime policy, InterSAGE’s monotonic chain signs the\ncapability boundary at issuance and reduces verification to signature\nchecking, so the bound holds even when the policy engine is wrong.\nWhere AgentMesh and the enterprise governance frameworks route\ncryptographic checks and application policy through a single PDP,\nInterSAGE’s two-tier split keeps them on independent evaluation paths\nwith independent failure semantics, so a regression in one tier\ncannot weaken the other. And where BlockA2A anchors audit trails\nto blockchain consensus, InterSAGE achieves tamper-evident\nnon-repudiation via kernel-mediated signing that works in air-gapped\nand resource-constrained environments without a distributed ledger.

Second, InterSAGE provides the conjunction: no prior single\narchitecture jointly enforces persistent identity with four-dimensional\nbinding, capability-aware discovery through DID-bound Verifiable\nCredential manifests, trust negotiation that combines lifecycle-scoped\nmonotonic capability attenuation with two-tier access control, and\nkernel-mediated cryptographic audit trails.\nTable 7 makes both contributions visible across\nthirteen evaluation dimensions: every prior approach achieves at\nmost a strict subset of InterSAGE’s coverage in breadth, and the\nper-primitive depth gap is most pronounced precisely where\nstructural guarantees matter—under operator compromise, PDP\nmisconfiguration, or cross-protocol composition.

10 Discussion & Future Directions

\n\n

In this section, we discuss the limitations of the InterSAGE framework and outline key directions for future research. We first acknowledge the boundaries of this positioning paper and the practical challenges of deploying a global trust anchor. We then highlight promising avenues for future work, ranging from formal verification and privacy-preserving extensions to scalable infrastructure and integration with existing agent frameworks.

10.1 Limitations

\n\n

Positioning scope. \n\nInterSAGE is a positioning paper that establishes the conceptual framework,\nprotocol architecture, and design rationale. A complete protocol\nspecification would additionally require formal proofs of security\nproperties, quantitative performance evidence, implementation detail, and\nadversarial validation; we defer these to companion work. Concretely, the\nfollowing aspects are explicitly out of scope here:

• \n
\n
Formal verification: TLA+ or ProVerif models of the\nattestation and delegation protocols.
\n
• \n
\n
Performance evaluation: Latency and throughput benchmarks\nunder realistic multi-agent workloads.
\n
• \n
\n
Implementation details: A companion DeepKernel system\npaper will describe the full implementation including kernel\narchitecture, eBPF enforcement, and perception/cognition layers.
\n
• \n
\n
Adversarial evaluation: Red-team exercises and attack\nsimulation against the protocol suite.
\n

GAR as a trust anchor. \nThe Global Agent Registry serves as a centralized (or federated) trust\nanchor, analogous to a Certificate Authority. This introduces the same\ntrade-offs as traditional PKI: the GAR must be highly available, its\ncompromise would be catastrophic, and cross-GAR trust requires federation\nagreements. Decentralized alternatives (e.g., blockchain-backed GARs, web\nof trust models) can mitigate these risks but introduce latency and\ngovernance complexity.

Adoption bootstrapping. \nThe value of InterSAGE increases with adoption (network effects). Early\ndeployments may face a chicken-and-egg problem where few agents support\nInterSAGE’s identity layer, reducing the incentive for others to adopt. We\nenvision a phased adoption path: Layer 0 (identity) can be adopted\nindependently of Layers 1–3, providing immediate value for agent\nauthentication even when only a subset of the ecosystem participates.

Semantic tag governance. \nLayer 1’s semantic tagging relies on an open vocabulary. Without\ngovernance, semantic tags may become fragmented or misleading. We\nanticipate that domain-specific tag ontologies will emerge organically\n(similar to Docker image tags or npm package keywords) and can be curated\nby registry operators.

10.2 Future Directions

\n\n

Formal verification. \nThe attestation and delegation protocols lend themselves to formal\nverification using tools such as TLA+ [16] for safety\nproperties and ProVerif or Tamarin for cryptographic protocol analysis.\nFormalizing the monotonic attenuation chain as a lattice-theoretic\ninvariant would strengthen the structural guarantee claims.

Attestation deployment topologies. \nThe mutual attestation protocol (§6.1) is\nparameterized by the relationship between Kernel_$A$ and Kernel_$B$, yielding three\ndeployment modes with distinct trust and performance profiles.\nCo-located attestation (Kernel_$A$ ${}={}$ Kernel_$B$) is the lowest-latency\noption, natural for DeepKernel-managed multi-agent orchestration on a\nsingle host; the entire challenge-response collapses to kernel-internal\noperations with no network round-trip.\nRemote-mediated attestation interposes a Trusted Attestation\nService (TAS)—architecturally identical to a local agent kernel but\ndeployed as a cloud endpoint—that coordinates nonce exchange, caches GAR\nverification results, and issues session tokens. The TAS plays a role\nanalogous to an OIDC Provider in human web SSO: it centralizes session\nestablishment at the cost of introducing a single point of trust that must\nitself be highly available and key-protected.\nDirect peer-to-peer attestation eliminates the intermediary: each\nkernel signs its own nonce and independently verifies the counterpart’s\nsignature via the GAR. This mode is fully decentralized but incurs at\nleast two independent GAR round-trips per attestation; AIC caching with\nrevocation-push notifications can amortize the cost.\nThe three modes can coexist within a single ecosystem—co-located for\nintra-device workflows, mediated for organizational clusters, and direct\nP2P for open cross-organization interactions—and the choice is\ndetermined by the deployment context rather than by the protocol itself.

Privacy-preserving extensions. \nThe current design exposes the requester’s full AIC attributes to the\nresponder during Layer 2 attestation. Zero-knowledge proofs (ZKPs) could\nenable selective disclosure: an agent could prove it possesses a required\ncapability or meets an IAL threshold without revealing its full identity.\nThis is particularly relevant for privacy-sensitive domains such as\nhealthcare and finance.

Integration with agent frameworks. \nInterSAGE is designed to be framework-agnostic, but practical adoption requires\nSDK integrations with popular agent frameworks (LangGraph, AutoGen,\nCrewAI, Semantic Kernel) and vendor SDKs (OpenAI Agents\nSDK [63], Google ADK [64]). We envision\nthin adapter libraries that bridge each framework’s identity and tool\ninvocation APIs to InterSAGE’s protocol primitives. AgentMesh’s approach of\nbuilding explicit protocol translators for A2A, MCP, and IATP (in the same\nAgent Governance Toolkit monorepo as AgentMesh) [19] suggests a\npragmatic integration pattern that InterSAGE could adopt for its initial deployment\ntargets.

Scalability of the GAR. \nAs the agent population grows to millions or billions, the GAR must scale\ncorrespondingly. Horizontal sharding by tenant or geographic region,\ncaching at the kernel level (with revocation push notifications), and\neventual consistency models for non-critical metadata are all viable\nstrategies that need empirical evaluation.

Cross-GAR federation. \nIn a multi-stakeholder ecosystem, multiple GARs will coexist (enterprise\nGARs, cloud-provider GARs, open-community GARs). Cross-GAR trust\nestablishment requires mutual recognition protocols analogous to\ncross-certification in PKI or trust federation in SAML. Designing these\nprotocols is a natural extension of InterSAGE’s architecture.

Agentic payment infrastructure. \nLayer 3’s payment primitives are deliberately minimal. A full agentic\npayment infrastructure would need to address escrow for long-running\ntasks, dispute resolution, quality-of-service guarantees, and\nmicro-payment efficiency. Google’s AP2 [45] is a leading open effort in this\ndirection, focusing on the payment rail and transaction flow. We view InterSAGE’s identity and metering layer as the\nfoundation upon which AP2-style settlement protocols can be built,\nproviding the “who is paying whom and with what authority” semantics that\npayment rails alone cannot supply.

Post-quantum readiness. \nAgentMesh [19] already lists ML-DSA-65 alongside Ed25519 as a\nsupported signature scheme. As NIST post-quantum standards mature, InterSAGE’s\nAIC and attestation protocols should be extended to support PQ signature\nalgorithms (e.g., ML-DSA, SLH-DSA) as drop-in replacements for Ed25519,\npreserving the structural security properties while future-proofing the\ncryptographic substrate.

11 Conclusion

\n\n

The Internet of Agents will not become secure merely by standardizing how\nagents exchange messages. The harder problem is whether independently built\nagents can make interoperable trust decisions: is this agent the entity it\nclaims to be, are its advertised skills and tools genuine, can its authority\nonly decrease as it is delegated, and can its actions later be attributed\nwithout ambiguity? This paper has argued that these questions require a\ntrust substrate, not another communication protocol.

InterSAGE provides such a substrate as a four-layer protocol suite spanning\nPersistent Identity, Discovery, Trust Negotiation, and Accountability. Its\nprincipal contribution is the conjunction of four layer-aligned primitives:\nAgent Identity Cards with four-dimensional binding; capability-aware\ndiscovery through DID-bound skill/tool manifest VCs; trust negotiation that\ncombines monotonic capability attenuation with two-tier access control; and\nkernel-mediated cryptographic audit trails. Each primitive has antecedents\nin existing identity, delegation, policy, or audit systems. What is missing\nfrom prior work, and what InterSAGE supplies, is their joint enforcement across\nthe full agent lifecycle: from issuance and discovery, through negotiation\nand delegation, to metering and non-repudiation.

This architecture deliberately remains communication-protocol agnostic.\nRather than competing with MCP, A2A, ANP, AG-UI, or future agent protocols,\nInterSAGE defines the trust objects those protocols can carry: AIC capability\nboundaries, manifest VCs, session tokens, and signed traces. This separation\nis what makes the design deployable across cloud, edge, and air-gapped\nsettings without relying on a single runtime, policy engine, registry\ntopology, or distributed ledger.

As a positioning paper, InterSAGE establishes the conceptual framework and\nprotocol architecture; formal verification, performance benchmarks, and a\ncompanion DeepKernel systems paper are left to ongoing work. The claim of\nthis paper is therefore precise: communication interoperability is necessary\nfor agents to talk, but secure interoperability is necessary for agents to\nact across organizational boundaries. InterSAGE is a step toward making the\nunderlying trust layer explicit, composable, and verifiable.

References

\n\n

[1]\nS. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao (2022)\n\nReAct: synergizing reasoning and acting in language models.\n\narXiv preprint arXiv:2210.03629.\n\nCited by: §1.\n
[2]\nQ. Wu, G. Bansal, J. Zhang, Y. Wu, et al. (2023)\n\nAutoGen: enabling next-gen LLM applications via multi-agent conversation.\n\narXiv preprint arXiv:2308.08155.\n\nCited by: §1.\n
[3]\nS. Hong, M. Zhuge, J. Chen, X. Zheng, et al. (2023)\n\nMetaGPT: meta programming for a multi-agent collaborative framework.\n\narXiv preprint arXiv:2308.00352.\n\nCited by: §1.\n
[4]\nW. Chen, Z. You, R. Li, Y. Guan, C. Qian, C. Zhao, et al. (2024)\n\nInternet of agents: weaving a web of heterogeneous agents for collaborative intelligence.\n\narXiv preprint arXiv:2407.07061.\n\nCited by: §1,\n§1,\n§9.1.\n
[5]\nGartner (2025)\n\nGartner predicts agentic AI will autonomously resolve 80% of common customer service issues by 2029.\n\nNote: Gartner Press Release\n\nExternal Links: Link\n\nCited by: §1.\n
[6]\nGoogle (2025)\n\nAgent-to-agent (A2A) protocol specification.\n\nNote: https://a2a-protocol.org/latest/specification/\n\nCited by: 2nd item,\n§1,\n§1,\n§2.1,\n§5.3,\n§9.7.\n
[7]\nAnthropic (2025)\n\nModel context protocol (MCP) specification.\n\nNote: https://modelcontextprotocol.io/\n\nCited by: §1,\n§2.1.\n
[8]\nG. Chang, E. Lin, C. Yuan, R. Cai, B. Chen, X. Xie, et al. (2025)\n\nAgent network protocol technical white paper.\n\narXiv preprint arXiv:2508.00007.\n\nCited by: 2nd item,\n§1,\n§2.1,\n§5.3,\n§9.1.\n
[9]\nY. Wang, S. Guo, Y. Pan, Z. Su, F. Chen, et al. (2025)\n\nInternet of agents: fundamentals, applications, and challenges.\n\nIEEE Transactions on Cognitive Communications and Networking.\n\nNote: arXiv:2505.07176; accepted by IEEE TCCN\n\nCited by: §1,\n§9.1.\n
[10]\nW. Xu, T. Wang, Y. Xia, S. Zhang, and S. C. Liew (2026)\n\nAgent-OSI: a layered protocol stack toward a decentralized internet of agents.\n\narXiv preprint arXiv:2602.13795.\n\nCited by: §1,\n§2.1,\nitem P1.,\nitem 4.,\n§9.1,\n§9.1.\n
[11]\nC. Fleming, L. Muscariello, V. Pandey, et al. (2025)\n\nA layered protocol architecture for the internet of agents.\n\narXiv preprint arXiv:2511.19699.\n\nCited by: §1,\n§2.1,\nitem P1.,\n§9.1.\n
[12]\nY. Yang, H. Chai, Y. Song, S. Qi, M. Wen, N. Li, et al. (2025)\n\nA survey of AI agent protocols.\n\narXiv preprint arXiv:2504.16736.\n\nCited by: §1,\n§2.1,\n§9.1.\n
[13]\nA. Ehtesham, A. Singh, G. K. Gupta, and S. Kumar (2025)\n\nA survey of agent interoperability protocols: MCP, ACP, A2A, and ANP.\n\narXiv preprint arXiv:2505.02279.\n\nCited by: §1,\n§2.1,\n§9.1.\n
[14]\nC. Li, J. Wu, Q. Du, S. Yu, R. Zou, K. Yu, et al. (2025)\n\nACPS: agent collaboration protocols for the internet of agents.\n\narXiv preprint arXiv:2505.13523.\n\nCited by: §1,\n§2.1,\nitem P1.,\n§9.1.\n
[15]\nAgent Client Protocol Project (2025)\n\nAgent client protocol (ACP): a protocol for connecting any editor to any agent.\n\nNote: https://github.com/agentclientprotocol/agent-client-protocol\n\nCited by: §2.1,\n§3.3,\nfootnote 1.\n
[16]\nS. Zheng and Q. Zhang (2026)\n\nAgentRFC: security design principles and conformance testing for agent protocols.\n\narXiv preprint arXiv:2603.23801.\n\nCited by: §1,\n§10.2,\n§2.2,\n§2.2,\n§9.5.\n
[17]\nZ. Anbiaee, M. Rabbani, M. Mirani, G. Piya, et al. (2026)\n\nSecurity threat modeling for emerging AI-agent protocols: a comparative analysis of MCP, A2A, agora, and ANP.\n\narXiv preprint arXiv:2602.11327.\n\nCited by: §1,\n§2.2,\n§2.2,\n§9.5.\n
[18]\nJ. A. Wibowo and G. C. Polyzos (2025)\n\nToward a safe internet of agents.\n\narXiv preprint arXiv:2512.00520.\n\nCited by: §1,\n§2.2,\n§9.5.\n
[19]\nMicrosoft (2026)\n\nAgentMesh: production-grade trust layer for multi-agent systems.\n\nNote: https://github.com/microsoft/agent-governance-toolkit/tree/main/agent-governance-python/agent-meshPart of the Agent Governance Toolkit; SPIFFE/SVID-based identity, policy engine, A2A/MCP/IATP protocol bridge\n\nCited by: 3rd item,\n§1,\n§10.2,\n§10.2,\n§2.1,\n§2.1,\nitem P1.,\n§4.2,\n§8.4,\nTable 6,\n§9.6.\n
[20]\nK. Huang, Y. Mehmood, H. Atta, J. Huang, et al. (2025)\n\nFortifying the agentic web: a unified zero-trust architecture against logic-layer threats.\n\narXiv preprint arXiv:2508.12259.\n\nCited by: §1,\n§2.1,\n§2.1,\n§9.6,\n§9.6.\n
[21]\nS. Prakash (2026)\n\nAIP: agent identity protocol for verifiable delegation across MCP and A2A.\n\narXiv preprint arXiv:2603.24775.\n\nCited by: 1st item,\n3rd item,\n§1,\n§4.2,\n§8.4,\nTable 6,\n§9.4,\n§9.4.\n
[22]\nH. Ramachandran and G. Mishra (2026)\n\nIdentity-aware governance for autonomous AI agents: a framework for enterprise authorization, delegation, and audit.\n\nSSRN (6439998).\n\nCited by: 3rd item,\n§1,\n§2.2,\n1st item,\n§9.3.\n
[23]\nZ. Zou, Z. Liu, L. Zhao, and Q. Zhan (2025)\n\nBlockA2A: towards secure and verifiable agent-to-agent interoperability.\n\narXiv preprint arXiv:2508.01332.\n\nCited by: 4th item,\n§1,\n§2.2,\n§3.1,\n§7.3,\n§8.4,\nTable 6,\n§9.7.\n
[24]\nS. Nagabhushanaradhya (2025)\n\nOpenID connect for agents (OIDC-A) 1.0: a standard extension for LLM-based agent identity and authorization.\n\narXiv preprint arXiv:2509.25974.\n\nCited by: 1st item,\n§2.3,\n§9.2.\n
[25]\nT. South S. Nagabhushanaradhya et al. (2025)\n\nIdentity management for agentic AI: the new frontier of authorization, authentication, and security.\n\narXiv preprint arXiv:2510.25819.\n\nNote: OpenID Foundation whitepaper\n\nCited by: 1st item,\n§2.3,\n§9.2.\n
[26]\nD. R. Saavedra (2026)\n\nInteroperable architecture for digital identity delegation for AI agents with blockchain integration.\n\narXiv preprint arXiv:2601.14982.\n\nCited by: 3rd item,\n§4.2,\n§9.4.\n
[27]\nM. B. Jones, B. Campbell, J. Bradley, and N. Sakimura (2020)\n\nOAuth 2.0 token exchange (RFC 8693).\n\nNote: IETF RFC 8693\n\nCited by: 3rd item.\n
[28]\nV. Srinivasan (2026)\n\nBridging protocol and production: design patterns for deploying AI agents with model context protocol.\n\narXiv preprint arXiv:2603.13417.\n\nCited by: §2.1.\n
[29]\nR. Georgio, C. Forder, S. Deb, A. Rahimov, et al. (2025)\n\nCoral protocol: open infrastructure connecting the internet of agents.\n\narXiv preprint arXiv:2505.00749.\n\nCited by: §2.1,\n§9.1.\n
[30]\nH. Derouiche, Z. Brahmi, and H. Mazeni (2025)\n\nAgentic AI frameworks: architectures, protocols, and design challenges.\n\narXiv preprint arXiv:2508.10146.\n\nCited by: §2.1,\n§9.1.\n
[31]\nCopilotKit (2025)\n\nAG-UI: the agent-user interaction protocol.\n\nNote: https://github.com/ag-ui-protocol/ag-ui\n\nCited by: §2.1,\n§3.3.\n
[32]\nIBM (2026)\n\nContextForge: an AI gateway, registry, and proxy for MCP, A2A, and REST/gRPC APIs.\n\nNote: https://github.com/IBM/mcp-context-forge\n\nCited by: §2.1.\n
[33]\nWild Card AI (2025)\n\nAgents.json: an open specification for API and agent interaction contracts.\n\nNote: https://github.com/wild-card-ai/agents-json\n\nCited by: §2.1.\n
[34]\nD. Hardt (2012)\n\nThe OAuth 2.0 authorization framework (RFC 6749).\n\nNote: IETF RFC 6749\n\nCited by: §2.3.\n
[35]\nOpenID Foundation (2014)\n\nOpenID connect core 1.0.\n\nNote: https://openid.net/specs/openid-connect-core-1_0.html\n\nCited by: §2.3.\n
[36]\nT. South, S. Marro, T. Hardjono, R. Mahari, et al. (2025)\n\nAuthenticated delegation and authorized AI agents.\n\narXiv preprint arXiv:2501.09674.\n\nCited by: §2.3,\n§9.2,\n§9.4.\n
[37]\nB. Bhushan, K. Pappu, and A. Mittal (2025)\n\nA conceptual framework for authentication in agentic AI ecosystems: protocol analysis and taxonomy.\n\nIn IEEE ICCA,\n\nCited by: §2.3,\n§9.2.\n
[38]\nE. Rescorla (2018)\n\nThe transport layer security (TLS) protocol version 1.3 (RFC 8446).\n\nNote: IETF RFC 8446\n\nCited by: §2.3.\n
[39]\nK. Huang and C. Hughes (2025)\n\nAgentic AI identity security.\n\nIn Securing AI Agents,\n\nExternal Links: Document\n\nCited by: §2.3,\n§9.3.\n
[40]\nK. Pappu, B. Bhushan, and A. Mittal (2025)\n\nSPIFFE-based zero-trust authentication for AI agent ecosystems.\n\nIn IEEE ICCA,\n\nCited by: §2.3,\n§2.3,\n§4.2,\n§9.3.\n
[41]\nK. Huang, V. S. Narajala, J. Yeoh, J. Ross, et al. (2025)\n\nA novel zero-trust identity framework for agentic AI: decentralized authentication and fine-grained access control.\n\narXiv preprint arXiv:2505.19301.\n\nCited by: §2.3,\n§9.3.\n
[42]\nD. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and T. Polk (2008)\n\nInternet X.509 public key infrastructure certificate and certificate revocation list profile (RFC 5280).\n\nNote: IETF RFC 5280\n\nCited by: §2.3.\n
[43]\nS. R. Garzon, A. Vaziry, E. M. Kuzu, D. E. Gehrmann, et al. (2025)\n\nAI agents with decentralized identifiers and verifiable credentials.\n\narXiv preprint arXiv:2511.02841.\n\nCited by: §4.2,\n§9.3.\n
[44]\nW3C (2025)\n\nVerifiable credentials data model v2.0.\n\nNote: https://www.w3.org/TR/vc-data-model-2.0/W3C Recommendation, 2025-05-15\n\nCited by: §5.4.\n
[45]\nGoogle (2026)\n\nAgent payments protocol (AP2): building a secure and interoperable future for AI-driven payments.\n\nNote: https://github.com/google-agentic-commerce/AP2\n\nCited by: §10.2,\n§7.2,\n§9.1.\n
[46]\nD. Dolev and A. C. Yao (1983)\n\nOn the security of public key protocols.\n\nIEEE Transactions on Information Theory 29 (2), pp. 198–208.\n\nExternal Links: Document\n\nCited by: §8.1.\n
[47]\nOpenAgents (2026)\n\nOpenAgents network model.\n\nNote: https://openagents.org/docs/zh/concepts/openagents-network-modelVersion 1.0; updated May 8, 2026\n\nCited by: §9.1.\n
[48]\nC. Du, C. Wang, Y. Chao, X. Xie, and Y. Cui (2025)\n\nAI agent communication from internet architecture perspective: challenges and opportunities.\n\narXiv preprint arXiv:2509.02317.\n\nCited by: §9.1.\n
[49]\nC. Jeong (2025)\n\nA study on the MCP x A2A framework for enhancing interoperability of LLM-based autonomous agents.\n\narXiv preprint arXiv:2506.01804.\n\nCited by: §9.1.\n
[50]\nQ. Duan and Z. Lu (2026)\n\nAI agent communications in the future internet—paving a path toward the agentic web.\n\nFuture Internet (MDPI) 18 (3), pp. 171.\n\nCited by: §9.1.\n
[51]\nZ. Liang, E. Cui, Q. Wei, R. She, T. Li, M. Guo, et al. (2026)\n\nA2H: agent-to-human protocol for AI agent.\n\narXiv preprint arXiv:2602.15831.\n\nCited by: §9.1.\n
[52]\nS. Guo, Y. Wang, Z. Su, Y. Pan, Q. Hu, and T. H. Luan (2026)\n\nAgent discovery in internet of agents: challenges and solutions.\n\nIEEE Network.\n\nNote: arXiv:2511.19113\n\nCited by: §9.1,\n§9.5.\n
[53]\nT. South, S. Marro, T. Hardjono, R. Mahari, et al. (2025)\n\nPosition: AI agents need authenticated delegation.\n\nIn ICML,\n\nNote: Position paper\n\nCited by: §9.2,\n§9.4.\n
[54]\nA. Aydeger E. Zeydan et al. (2026)\n\nDecentralized digital identity management for large language model agents.\n\nIEEE Communications Standards Magazine.\n\nCited by: §9.2.\n
[55]\nAGNTCY (2026)\n\nAGNTCY identity: onboarding, creating, and verifying identities for agents and MCP servers.\n\nNote: https://github.com/agntcy/identity\n\nCited by: §9.2.\n
[56]\nBillionsNetwork (2026)\n\nVerified agent identity: decentralized identity management for AI agents using iden3.\n\nNote: https://github.com/BillionsNetwork/verified-agent-identity\n\nCited by: §9.2.\n
[57]\nK. Huang, V. S. Narajala, I. Habler, et al. (2025)\n\nAgent name service (ANS): a universal directory for secure AI agent discovery and interoperability.\n\narXiv preprint arXiv:2505.10609.\n\nNote: arXiv:2505.10609\n\nCited by: §9.3.\n
[58]\nB. Bhushan (2025)\n\nAn explainable zero trust identity framework for LLMs, AI agents, and agentic AI systems.\n\nEuroLexis Open Access Journal.\n\nCited by: §9.3.\n
[59]\nD. R. Palavali (2025)\n\nAgentic AI for self-sovereign identity: a decentralized zero trust framework for autonomous microservices.\n\nIJCMI.\n\nCited by: §9.3.\n
[60]\nS. Prakash (2026)\n\nLDP: an identity-aware protocol for multi-agent LLM systems.\n\narXiv preprint arXiv:2603.08852.\n\nCited by: §9.4.\n
[61]\nA. Dalugoda (2026)\n\nHDP: a lightweight cryptographic protocol for human delegation provenance in agentic AI systems.\n\narXiv preprint arXiv:2604.04522.\n\nNote: IETF Internet-Draft draft-helixar-hdp-agentic-delegation-00\n\nCited by: §9.4.\n
[62]\nT. Chaffer (2025)\n\nKnow your agent: governing AI identity on the agentic web.\n\nNote: SSRN Working PaperSSRN 5162127\n\nCited by: §9.5.\n
[63]\nOpenAI (2025)\n\nOpenAI agents SDK: a lightweight framework for multi-agent workflows.\n\nNote: https://github.com/openai/openai-agents-python\n\nCited by: §10.2.\n
[64]\nGoogle (2025)\n\nAgent development kit (ADK): an open-source python toolkit for building AI agents.\n\nNote: https://github.com/google/adk-python\n\nCited by: §10.2.\n

InterSAGE\n\nThe Secure and Verifiable Interoperability Protocol \nfor An Internet of Agents\n\nA Paper from the DeepKernel Lab

Abstract

1 Introduction

2 Background & Threat Landscape

2.1 The Agent Interaction Landscape

2.2 Agent-Specific Threat Model

2.3 Why Traditional Internet Security Falls Short

3 InterSAGE: Design Philosophy & Protocol Suite Overview

3.1 Design Principles

3.2 Protocol Suite Architecture

3.3 Relationship to Existing Protocols

4 Layer 0: Persistent Agent Identity

4.1 Agent Identity Card (AIC)

4.2 Four-Dimensional Identity Binding

4.3 Global Agent Registry (GAR)

4.4 Key Protection Tiers

4.5 Identity Lifecycle

5 Layer 1: Registration, Discovery & Semantic Interoperability

5.1 Capability-Aware Registration

5.2 Semantic Capability Tagging

5.3 Capability-Aware Discovery

5.4 Verifiable Skill & Tool Manifests

6 Layer 2: Trust Negotiation

6.1 Mutual Attestation Protocol

Remark (Deployment Topologies).

6.2 AIC Delegation Chain

6.3 Two-Tier A2A Access Control

6.4 The Capability Narrowing Chain

7 Layer 3: Accountability & Economics

7.1 Token-Usage Tracing

7.2 Payment Primitives

7.3 Action Accountability

7.4 Non-Repudiation

8 Security Analysis

8.1 Threat Model and Assumptions

8.2 Property-Centric Security Evaluation

8.3 Security under Composition

8.4 Comparison and Residual Risks

9 Related Work

9.1 Communication Stacks vs. Security-First Substrates

9.2 Single-Dimension IAM vs. Multi-Dimensional Binding

9.3 Directory Discovery vs. Capability-Aware Manifests

9.4 Policy-Evaluated vs. Structurally-Attenuated Delegation

9.5 Conformance Testing vs. Cryptographic Enforcement

9.6 Single-Plane Overlays vs. Two-Tier Authorization

9.7 Our Prior Work: BlockA2A

9.8 Summary: the Joint-Coverage Argument

10 Discussion & Future Directions

10.1 Limitations

10.2 Future Directions

11 Conclusion

References

InterSAGE\n
\nThe Secure and Verifiable Interoperability Protocol \n
for An Internet of Agents\n
\nA Paper from the DeepKernel Lab