ADI
ADI Blog Agent interoperability 3 min read

How external agents verify an ADI merchant agent

A buyer agent does not have to live inside ADI to trust an ADI merchant agent. It needs public discovery, a resolvable agent identity, signed credentials, and a clear payment mandate path. This article shows how those pieces fit together.

ADI is designed as an open trust layer, not a closed-loop agent marketplace.

The AgentCard tells external agents how to reach an agent, while the trust profile and credentials prove who the agent represents and what it may do.

Transport authentication and authority proof are different layers: OAuth or JWT opens the channel, signed credentials and mandates prove permission.

The interoperability goal

Imagine a buyer agent running in Indonesia. It discovers a merchant agent that claims to represent a European shop. The buyer agent should not have to trust a chat message, a logo, or a private integration promise. It should be able to inspect public machine-readable evidence.

That is the job of ADI. The merchant agent can live in the merchant shop, use its own runtime, and speak to other agents through A2A. ADI provides the independent trust layer that lets outsiders verify who the agent is, which merchant stands behind it, and what authority has been delegated to it.

The four pieces that must not be mixed up

AgentCard is discovery: where the agent is, which protocol it speaks, which transport authentication it supports, and where trust evidence can be found.

Trust profile is identity binding: the agent DID, the operator, the organization, publication status, ownership proof, and public verification signals.

Credentials are portable authority: signed verifiable credentials such as AP2AgentDelegationCredential, AP2MerchantCredential, and AP2ProductOfferingCredential.

Platform permissions are internal enforcement: ADI scopes such as PAYMENT_PROCESSING decide what the agent may do inside ADI APIs, but the external proof is expressed as signed claims.

How the verification flow works

External buyer agent verifies an ADI merchant agent

The external agent first discovers the A2A surface, then follows the ADI trust-chain links before it relies on a merchant offer or AP2 payment flow.

sequenceDiagram
    participant Foreign as External buyer agent
    participant Card as Public AgentCard
    participant Trust as ADI trust profile
    participant Creds as ADI credential manifest
    participant Merchant as Merchant agent
    participant Pay as Merchant payment rail

    Foreign->>Card: Fetch /.well-known/agents/{agentId}/card.json
    Card-->>Foreign: A2A endpoint, DID, auth schemes, trust-chain links
    Foreign->>Trust: Read public trust profile
    Trust-->>Foreign: Agent DID, merchant binding, verification state
    Foreign->>Creds: Fetch credential manifest
    Creds-->>Foreign: Signed credentials and verification URLs
    Foreign->>Foreign: Verify issuer, subject DID, status, expiry, and claims
    Foreign->>Merchant: Send AP2/A2A request with mandate evidence
    Merchant->>Trust: Validate mandate, catalog, policy, and credential binding
    Trust-->>Merchant: Approved or rejected with reason
    Merchant->>Pay: Create merchant acquiring payment intent if approved

Why OAuth is not enough

OAuth, OIDC, API keys, and JWTs answer a transport question: is this caller allowed to use this endpoint? They do not prove that the agent is legally or commercially allowed to sell a product, represent a merchant, accept a payment, or bind a transaction to a mandate.

ADI keeps those layers separate. A merchant agent can require OAuth or JWT for the channel, but the buyer agent still checks the DID, public trust profile, credential manifest, credential signatures, credential status, and AP2 mandates before relying on the transaction.

What an external agent should check

The AgentCard must use public URLs, not internal Docker hostnames or localhost-only infrastructure.

The trust-chain extension must point to the public AgentCard, trust profile, credential manifest, and credential verification surface.

The credential subject DID must match the agent DID in the AgentCard and trust profile.

The credential issuer, status, expiry, and proof must verify before the external agent treats the merchant claim as real.

For commerce, AP2 mandates and merchant catalog checks must still pass for the specific cart, price, payment rail, and receipt path.

The ADI operating model

This keeps ADI interoperable. ADI agents can buy outside ADI using prepaid issuing-card controls. ADI merchant agents can accept payment through the merchant acquiring rail. External agents can participate if they bring verifiable mandate and credential evidence that ADI can evaluate.

The result is not a closed platform. It is a public trust layer that lets independent agents discover, verify, transact, and explain their decisions to the humans and organizations behind them.

CONTINUE READING

More articles from the technical reading layer.

MERCHANT TRUST Agent commerce

How the merchant trust catalog works

A merchant agent can sell from the merchant shop, but ADI needs an independent trust reference for what that agent is allowed to sell. The merchant catalog in ADI is that reference: a canonical product whitelist used to validate agent commerce before money moves.

The shop catalog runs the business.

The ADI catalog proves what the merchant approved.

AP2 VALIDATION Agent commerce

How ADI validates what a merchant agent sells

A merchant agent can describe an offer, but ADI should not pay from description alone. ADI validates the AP2 mandates, the merchant organization, the product SKU, the trusted catalog entry, the buyer wallet, and the virtual-card policy before the transaction becomes authorized.

Conversation creates intent.

AP2 creates structured mandates.

INTEGRATIONS Agent commerce

Why shop integrations are trust inputs, not the trust layer

Shopify, WooCommerce, CSV, custom APIs, and marketplace connectors help ADI import merchant product state. They are not the trust layer by themselves. The trust layer begins when ADI normalizes that product state, binds it to a merchant organization, and uses it in mandate and payment checks.

Integration is ingestion.

Catalog governance is trust.

INTEGRATION MODES Agent integration

Three ways to connect an external agent to the ADI trust layer

An external agent does not need to run inside ADI to be governed by ADI. The practical question is how the relying system authenticates that agent and when it asks ADI for trust, delegation, and certificate state.

Standard mode: API key or agent token plus online trust lookup

Enterprise mode: OIDC plus trust lookup

TRUST FOUNDATIONS Agent trust

Why agents need a trust layer

An API token only tells you whether a request is authenticated. A trust layer tells you which agent is acting, on whose behalf, which proofs are valid, and whether that agent can be stopped.

When OAuth stops being enough

Which questions a trust layer must answer

ARCHITECTURE System architecture

Separating A2A, trust, and AP2

The key architectural principle is separating the layers. A2A is communication. Trust is governance. AP2 is payment behavior.

What A2A actually standardizes

When trust is additionally required

PRODUCT ADI stack

How ADI works as an agent trust stack

ADI is not a single interface. It is an operational layer that connects discovery, identity, trust, and payment flows for agentic systems.

The platform’s four layers

Where A2A, MCP, and AP2 meet

A2A EXPLAINED A2A fundamentals

What A2A is and what it is not

A2A gives agents a shared way to describe themselves, exchange messages, and execute tasks. It does not automatically solve identity binding, delegated authority, auditability, or payment control.

A2A standardizes discovery, messages, tasks, and declared security capabilities.

A2A does not by itself answer who the agent represents or what it is permitted to do.

AP2 FOUNDATIONS AP2 payments

What AP2 solves for agent commerce

AP2 gives agent commerce a structured model for intent, cart, payment authorization, and receipts. Without that model, every agent-payment integration invents its own fragile semantics.

AP2 introduces a common vocabulary for agent payment flows.

Mandates separate scope, intent, and final payment authorization.

TRUST FOUNDATIONS Agent trust

What agent trust actually means

Agent trust is not a brand claim. It is the operational ability to prove who an agent is, on whose behalf it acts, what it is allowed to do, and how that authority can be revoked or audited.

Trust begins where authentication alone stops.

A real trust layer must support revocation, inspection, and evidence.

PRODUCT EXPLAINER ADI stack

What ADI does in an agent stack

ADI is the trust and control layer that sits between agent interoperability and real business action. It helps organizations let agents act without treating those agents like ungoverned black boxes.

ADI is where governance enters the agent stack.

The platform connects external agents, enterprise controls, and transaction policies.

SIGNATURES AND SEALS Trust services

Human signatures vs organization eSeals

A human signature proves the will or approval of a natural person. An organization eSeal proves that a trust object was issued or sealed by a legal entity. In enterprise agent systems, those are different jobs and they should not be collapsed into one.

Human signatures answer: who personally approved this?

Organization eSeals answer: which legal entity issued or stands behind this artifact?