Cross-Org Agent Trust

The Problem

When your AI agent needs to negotiate with another company’s system, that system has no reliable way to verify:

• Which agent it is — Multiple agents share generic service account credentials
• Which organization it represents — No cryptographic proof of organizational affiliation
• What it’s authorized to do — Permissions aren’t bound to the agent, just the account
• Whether that authorization is still valid — No real-time revocation check

This isn’t a future problem. Insurance companies underwrote $1.6 billion in specialty premium via agentic AI with no clean way to prove which agent acted for which organization. When agents cross company boundaries today, trust relies on out-of-band verification, VPN tunnels, or simply hoping the other side is who they claim to be.

The status quo:

• Agent A (at Bank X) wants to settle a trade with Agent B (at Bank Y)
• Both banks trust their own agents, but neither bank can cryptographically verify the other’s agent
• The handshake happens anyway, logged generically as “API integration” or “system action”
• Auditors later ask: “Which specific agent executed this? Under whose authority? Was that authorization valid at execution time?”
• The answer: “We don’t know.”

Why It Matters Now

Regulators aren’t waiting:

• MAS SAFR (Singapore Monetary Authority, Jul 2026): Mandates runtime controls for inter-institutional agent workflows. Co-authored with HSBC, JPMorgan, Mastercard, Visa, and OCBC—this isn’t a proposal, it’s an enforceable requirement.

• eIDAS 2.0 (EU, 2027): Requires verifiable digital identity for automated systems across member states. ~450 million wallets will need agent identity infrastructure that works cross-border.

• Four independent jurisdictions (Singapore, EU, US via Utah SEDI, China via AI-Agent Identity Framework) have converged on identical architectural primitives: self-owned agent identity + runtime authorization queries. When regulators in vastly different systems independently arrive at the same technical requirements, it signals consensus—not coincidence.

Technical Deep Dive What are Decentralized Identifiers (DIDs)? DIDs give agents cryptographic identities that work across organizational boundaries—no central authority required.

---

How Affinidi Enables Cross-Org Agent Trust

The shift: from trusting a shared infrastructure (VPN, directory federation) to trusting cryptographic proof that travels with every request.

Before Affinidi:

[Your Agent] → [Shared VPN or federated directory] → [Partner's System]
              ↓
         Hope they're who they say they are

With Affinidi:

[Your Agent] → [Agent Gateway: assigns DID + signed mandate]
                   ↓
             [Trust Spanning Protocol: metadata-private routing]
                   ↓
             [Partner's System: verifies DID signature]
                   ↓
             [Trust Registry (TRQP): "Is this agent authorized RIGHT NOW?"]
                   ↓
             [Transaction proceeds with cryptographic proof logged]

The Key Difference

Instead of trusting a shared VPN or federated directory, each agent carries cryptographic proof of its identity and authorization. The receiving system verifies this proof independently, in real time.

What makes this work:

1. Agent Gateway issues each agent a DID (Decentralized Identifier) based on did:webvh—tamper-evident, time-travelable identifiers with safe key rotation. No central registry required.

2. Every request carries a signed mandate (a W3C Verifiable Credential) stating:

   • “This agent is authorized by [Organization]”
   • “To perform [Specific Actions]”
   • “Until [Expiry or Revocation]”

3. Trust Registry responds to TRQP queries (Trust Registry Query Protocol):

   • “Is this agent authorized right now?”
   • Returns current status, accounting for any revocations or policy changes
   • No directory merge—each org maintains its own registry

4. Trust Spanning Protocol (TSP) routes agent messages across boundaries with metadata privacy—the message reaches the partner without revealing routing details to intermediaries. Affinidi ships the first production TSP integration in the wild.

Technical Deep Dive How Trust Registries Work (TRQP) TRQP lets one organization's systems query another's authorization policies in real time—without sharing internal directories.

Technical Foundation

• did:webvh: Web-based DIDs with verifiable history. Safe key rotation without breaking existing signatures. Tamper-evident audit trail built in.
• W3C Verifiable Credentials: Standard credential format (not a custom token scheme). BBS+ selective disclosure available for privacy-preserving presentations.
• DIDComm v2.1: Encrypted, authenticated messaging between agents. End-to-end encryption; intermediaries can’t read content.
• TRQP (Trust Registry Query Protocol): Real-time authorization lookups. “Is agent X still authorized?” answered in milliseconds, not hours.
• Post-Quantum Ready: ML-DSA and SLH-DSA integrated into the verifiable-history layer. Future-proofed cryptography.

Technical Deep Dive DIDComm Messaging Protocol Encrypted agent-to-agent communication that works across organizational boundaries without a central server.

---

Proof It Works

This isn’t theory:

• 18,500+ signed credentials across live trust networks
• First TSP integration in production (Trust Spanning Protocol)—not a whitepaper, actual code shipping
• MAS SAFR alignment validated by co-authoring institutions (HSBC, JPMorgan, Mastercard, Visa, OCBC)
• Self-hostable: Deploy on your infrastructure, not ours. No vendor lock-in.

Affinidi is the only vendor shipping the full stack: agent identity + cryptographic mandates + runtime policy enforcement + cross-org trust registries + metadata-private routing—all in production.

---

What This Isn’t

Not a VPN replacement. VPNs secure the network layer; this secures the agent layer. You can use both, but VPNs alone can’t answer “which agent acted, and were they authorized?”

Not directory federation. You don’t merge directories or expose internal IAM schemas. Each org keeps its own trust registry; TRQP queries work across boundaries without data leakage.

Not a wallet alone. Wallet-only solutions give agents identity but don’t handle runtime policy enforcement, revocation checks, or cross-org authorization queries. You need the full stack.

Not an agent runtime. AWS AgentCore, Cloudflare Workers for AI, and similar platforms execute agents—they’re excellent at that. But they don’t solve inter-organizational trust. Affinidi sits alongside runtimes, not replacing them.

---

Get Started

Whether you’re a developer prototyping agent workflows, a security team evaluating compliance, or an enterprise planning cross-org automation—there’s a path in.

• Developers — give an agent a verifiable identity in minutes with Agent Gateway, then start building in the Affinidi Portal.
• Security & compliance — see how runtime authorization is enforced with Trust Registries and TRQP, or book a walkthrough.
• Enterprises — planning cross-org automation across partners or regions? Talk to our team about a self-hosted deployment.

New to the underlying standards? Start with Decentralized Identifiers, then explore Trust Registries (TRQP) and DIDComm Messaging.

---

Related Resources

Technical Deep Dives

• Decentralized Identifiers (DIDs) — How agents get cryptographic identities that work across organizations
• DIDComm Messaging — Encrypted agent-to-agent communication without a central server
• Trust Registries & TRQP — Real-time authorization queries across organizational boundaries

Related Solutions

• Per-Agent Attribution — Prove which agent did what, and who authorized it
• Runtime Agent Governance — Control before action, not logs after the fact

Case Studies

• H2H Connect: Privacy-First Trusted Messaging — Real-world implementation at the Summit on Human Agency