InterSAGE: Trust Substrate for the Internet of Agents
Your agent can call MCP tools, negotiate over A2A, and stream events through AG-UI. It still cannot prove who it is to the counterparty.
InterSAGE: Trust Substrate for the Internet of Agents
Your agent can call MCP tools, negotiate over A2A, and stream events through AG-UI. It still cannot prove who it is to the counterparty. That four-part gap — persistent identity, discovery, trust negotiation, accountability — is what the InterSAGE proposal targets in arXiv:2608.13030, reviewing more than 50 prior efforts before concluding none unify the layers.
The framing matters because the Internet of Agents is being assembled from protocols that were never designed together. MCP handles tool exposure. A2A handles peer discovery and delegation. ANP proposes a decentralized substrate. AG-UI wires human interfaces. None of them ship an identity model strong enough for the NIS2 obligations on supply-chain accountability that now apply to essential and important entities across the EU.
Four layers, one substrate
InterSAGE proposes Agent Identity Cards bound to Decentralized Identifiers, with Verifiable Credential manifests describing what each agent is entitled to invoke. Capability attenuation runs on two tiers: coarse admission at the boundary, fine-grained per-tool checks at the kernel. Every interaction produces a cryptographic audit record — but the design refuses a consensus ledger, arguing accountability can be enforced through kernel mediation without paying blockchain latency or governance costs.
That last choice deserves attention. ENISA’s 2024 threat landscape flags supply-chain and identity abuse as top vectors; a ledger-free audit trail is easier to align with GDPR erasure obligations than a public chain would be. For teams building on CAI-AUTH primitives, the InterSAGE shape maps cleanly onto DID-based session negotiation we already deploy.
agent_identity_card:
did: did:web:agents.caitech.eu:planner-07
manifest_hash: sha256:9f0a3d17c412e88b1a2c7fd0e5b4a911
capabilities:
- tool: invoice.read
scope: tenant=acme
attenuation: read_only
- tool: invoice.pay
scope: tenant=acme
attenuation: requires_human_approval
audit_kernel: cai-auth-kernel-v3How the layers compose
The design matches how NIST SP 800-207 zero-trust guidance treats every request as unverified until a policy engine authorizes it — except the subject is now a delegated agent, not a human. Discovery becomes the harder problem: an agent must locate a counterparty and verify its credentials before any negotiation happens, which is why InterSAGE promotes discovery to a first-class layer rather than a DNS afterthought.
Where CAI Technology lands
We ship this differently than the paper describes, and on purpose. Our position: the audit kernel is the only component you cannot outsource. Identity cards, credential manifests, and discovery registries can be plural and vendor-mixed, but the signing kernel that binds an agent’s action to its DID has to sit inside your trust boundary — otherwise accountability is theatre. That is why our agent topology work treats the kernel as infrastructure, not middleware.
If you are wiring agents against MCP or A2A this quarter, the CAI-AUTH deployment brief shows how the substrate lands in a mid-market stack.