Identity Is Not Trust: The Missing Layer in Agentic Payments

A technical note from SENTINEL — the agent-to-agent transaction safety oracle.


The question every payment protocol answers — and the one none of them do

By mid-2026 the agentic payments stack has consolidated around a clear division of labor. x402 moved HTTP's dormant 402 status code into production as the settlement rail. ERC-8004 gave agents a portable on-chain identity. And nearly every major payments company joined the x402 Foundation, each bringing its own answer to one specific question: who is this agent?

Visa's Trusted Agent Protocol signs an agent's identity into HTTP headers so a merchant can check it against a Visa-operated directory. Mastercard's Agent Pay binds a tokenized credential to a specific agent. Google's AP2 binds a cryptographic mandate to the human who instructed the agent. The Agentic Commerce Protocol from Stripe and OpenAI issues single-use, amount-capped tokens.

These designs differ in mechanism but share one property: they all answer who is calling and on whose authority. That is the identity question, and the industry is solving it well.

There is a second question none of them answer: is this counterparty trustworthy?

Identity and trust are different problems

Knowing who an agent is tells you nothing about whether it delivers what it charges for. A verified identity can still be attached to a service that takes payment and returns nothing, advertises one price and charges another, or has a pattern of non-delivery that only becomes visible across many transactions.

In human commerce we separate these instinctively. A passport proves identity. A credit rating expresses trustworthiness. No one confuses the two, and no one would extend credit on the strength of a passport alone. The agentic economy has built excellent passports. It has not yet built the rating.

This gap is not hypothetical. A payment endpoint that verifies an agent's identity and then settles a payment has confirmed authorization — that the agent is who it claims and is allowed to spend. It has not confirmed that the counterparty on the other side will honor the transaction. When the buyer is software executing at machine speed, with no human to notice that the data never arrived or the price was wrong, the cost of that unconfirmed assumption compounds silently.

What a trust layer requires

A trust signal that actually protects an autonomous transaction has to do more than assert a score. It has to be:

Behavioral, not declarative. Trust is earned through observed conduct — payment history, delivery record, incident history — not through self-description. Any party can claim to be reliable. A trust layer measures whether they have been.

Backed by verifiable evidence. A score with no auditable trail is an opinion. When a trust layer marks a counterparty as risky, the party relying on that judgment should be able to inspect why — the specific incidents, with commitments that cannot be quietly edited after the fact.

Composable at machine speed. The judgment has to be available in the transaction's hot path without a human in the loop, ideally verifiable offline and readable on-chain, so a smart contract or a settlement hook can gate on it directly.

Resistant to gaming. If trust can be purchased — by farming many small legitimate payments to inflate a score before a single large abuse — it is not trust. Maturity has to be gated on time and conduct that cannot be bought.

Where SENTINEL fits

SENTINEL is built for the second question. It scores x402 payment counterparties on Base from behavioral signals, issues those scores as ES256 attestations that verify offline against a published key, publishes them on-chain for smart-contract composability, and — critically — keeps an append-only, hash-anchored registry of verified incidents rather than only predictive scores.

It is not a competitor to the identity protocols. It is the complementary layer they leave open. Visa's protocol verifies the agent and moves no money; SENTINEL verifies the counterparty and issues no identity. AP2 proves the human authorized the purchase; SENTINEL assesses whether the service on the other end deserves it. Used together, an agent can know both who it is dealing with and whether it should.

The passports are built. This is the rating.


SENTINEL is live at sentinel-agent.dev. On-chain oracle, signed attestations, and the public incident registry are self-serve and require no signup. SENTINEL is the reference implementation of the x402 trust-provider extension proposed in x402 issue #2299.