Protocol adapters
Apply the gateway across the agent-interop surface, spanning identity, messaging, authorization, content, and commerce.
Agents don't only call REST tools. They speak emerging interop protocols and take real-world actions: verifying another agent's identity, accepting a payment mandate, honoring a content license. Protocol adapters extend the gateway across that surface, so the same inspect → decide → record flow applies no matter how the action is expressed.
The adapter as the unit
Each adapter teaches AxioRank to understand one protocol: how to parse its wire format, which signals matter (issuer, signature validity, scopes, endpoints), and how to map them into the shared risk and policy layer. Adapters are not protocol client libraries you install. They're how the gateway makes sense of a protocol message when it scores a call.
Six planes
The agent ecosystem collapses into six planes; every governed protocol sits in one.
| Plane | The question it answers |
|---|---|
| Discovery | What can this agent or service do? |
| Identity | Who is it, cryptographically? |
| Messaging | How do agents talk to each other? |
| Authorization | What may it do, and on whose behalf? |
| Content permission | May it use this content? |
| Commerce | Can it pay? |
A sample of what's covered today, by plane:
- Discovery: A2A Agent Card, MCP Server Card, Agent Skills (
SKILL.md), NANDA Index + AgentFacts, Agent Name Service. - Identity: Web Bot Auth (RFC 9421), W3C DIDs (
did:wba), W3C Verifiable Credentials 2.0, SD-JWT VC, Visa Trusted Agent Protocol. - Messaging: A2A Messaging, MCP Transport, Agent Network Protocol.
- Authorization: OAuth Protected Resource (RFC 9728), AP2 Mandates, Cross-App Access (ID-JAG), Resource Indicators (RFC 8707).
- Content permission:
robots.txt/llms.txt, IETF AI Preferences, Really Simple Licensing, Content Signals Policy. - Commerce: x402, Agentic Commerce Protocol, AP2 Payments.
Live coverage map
The full, current set, with each protocol's plane and status (live, beta, planned,
watching), is published at /protocols and served as JSON from
GET /api/v1/protocols. Treat that as the source of
truth; it changes as adapters ship.
How you exercise them
You don't call adapters directly. You call the gateway, and it applies the right adapter for what it's looking at:
- Outbound: preflight a remote agent or server before your agent trusts it
with
verifyCard/verify_card(POST /api/v1/gateway/verify-card). The gateway resolves the card's identity, validates signatures, and scores it. - Inbound: verify the agents reaching your own surface with
axioGuard/POST /api/v1/gateway/verify-request, which checks identity signals like Web Bot Auth.
Next steps
- Gateway API: the
verify-cardandverify-requestcontracts. - MCP server: call
verify_cardand read protocol coverage as tools. - Response engine: cross-tenant intel that enriches card verdicts.