Verifying AI Agents at Checkout: Tokens, Mandates and Behavioral Evidence

A checkout page used to ask one question: is this customer who they say they are? With AI agents, it must ask three. Who is this agent, what did the user allow it to do, and how risky is the operator behind it? This guide shows how merchants, payment providers and platforms can verify agents at checkout with credentials, mandates and behavioral evidence.

Checkout is the moment of truth for any payment. Before it, an agent can browse, compare and plan without cost to anyone. At checkout, money moves, goods ship and liability attaches. For that reason, verification matters most at this point, and mistakes here cost the most.

Human checkout flows rely on a mature toolkit. Cookies, device fingerprints, saved cards, authentication prompts and purchase history all support the decision. When a software agent arrives instead, most of that toolkit goes quiet. The agent has no browsing history in the usual sense, and it may hold no saved card at all. It carries other things: a token, a credential and perhaps a signed record of what the user asked for.

Those new items help, yet they do not tell the whole story. A token shows how to pay. In addition, a credential shows who registered the agent. A mandate shows what the user allowed. None of them shows whether the operator behind the agent is honest. This article explains how the three layers fit together, where each one stops and how a behavioral trust score closes the gap.

Why Checkout Is the Right Place to Verify

Teams can verify agents at several points: when the agent registers, when it connects to a service or when it pays. Each point has a role, yet checkout stands out for three reasons.

The stakes are concrete. A registration check protects a directory. Checkout checks protect money and inventory. The cost of a wrong decision is a chargeback, a shipped parcel or a drained balance.

Evidence is richest. At checkout, the merchant knows the amount, the product, the destination and the timing. These details turn a vague trust question into a specific one: should this agent buy this item at this price right now?

The decision is fast. Payment flows run in seconds. A checkout check must therefore be cheap, automatic and reliable. That constraint shapes the design of every layer below.

Verification Is Not a Single Step

Teams sometimes ask for one check that settles everything. No such check exists. A credential can be forged or stolen. Moreover, a mandate can be valid for a bad operator. A behavioral score can be wrong at the margin. The strength of the design comes from combining layers so that each covers the others’ blind spots.

The Three Layers at a Glance

The table below summarizes the three layers. Later sections describe each one in turn.

Layer	Question it answers	Typical evidence	What it cannot tell you
Credentials and tokens	Who is this agent, and how does it pay?	Agent passport, signed requests, payment token, on-chain identity	Whether the operator is trustworthy
Mandates	What did the user allow?	Signed intent, cart and payment mandates	Whether the user or operator is acting in good faith
Behavioral evidence	How risky is the operator?	Owner history, funding source, creator record, fleet links	Whether this specific purchase was intended

Each row has a blind spot, and the next row fills it. Credentials and mandates prove permission. Behavioral evidence estimates risk. Together they let a merchant answer both “may this agent act?” and “should we let it?”

Layer One: Credentials and Tokens

The first layer answers the identity and payment questions. It gives merchants a way to recognize an agent and to receive payment without handling raw card details.

Payment Tokens

OpenAI and Stripe introduced the Agentic Commerce Protocol, which lets an agent pay through a shared payment token. Payments Journal reported on the launch and described it as an effort to make agent checkout safe and consistent. The token represents the user’s payment method with limits attached, so the agent never sees the card number.

Tokens bring clear benefits. They reduce the exposure of card data. Furthermore, they can carry limits on amount, merchant and time. They can also be revoked without replacing the underlying card. Merchants should check that a token is valid, unexpired and scoped to their business.

Agent Credentials and Passports

Identity vendors and standards groups offer credentials that bind an agent to a registered operator. Trulioo describes a Digital Agent Passport that carries an agent’s origin, legitimacy, authorization and consent, and its Know Your Agent explanation sets out the idea for commerce. Investment follows the idea: a report on Baselayer’s $35M Series A shows how much capital now flows into agent identity.

Credentials help merchants recognize registered agents and reject anonymous ones. They also give a place to attach revocation and audit trails.

Signed Requests

A liability analysis from FinTech Wrap Up describes network programs that use signed HTTP requests, including a Mastercard approach based on Web Bot Auth and RFC 9421, so that merchants can verify who sent a request. That piece is opinion and commentary, not a network specification, so teams should confirm details with their acquirers. The idea itself is sound: a signature ties a request to a key holder and resists simple spoofing.

On-Chain Identity

On public chains, ERC-8004 offers an on-chain registry for agents. Its specification defines identity, reputation and validation registries. An agent’s registration gives it a portable identifier, and the registry lets others publish feedback. Our analysis of ERC-8004 trust signals explains what the registry proves and what it cannot.

What Layer One Proves

Credentials and tokens prove that a registered agent presents a valid payment instrument. They support recognition, revocation and audit. Instead, they do not prove that the operator behind the agent is honest. Registration is cheap in open systems, and a bad actor can register many agents. The article on KYA versus agent identity develops this point in depth.

Layer Two: Mandates

The second layer answers the authorization question. A mandate is a signed record of what the user asked for and approved. It turns a vague claim, “my agent was allowed to buy this,” into evidence that a merchant can check.

How AP2 Structures Mandates

Google’s Agent Payments Protocol, known as AP2, describes mandates built on verifiable credentials. The AP2 announcement describes three kinds.

Intent mandate. It records what the user wants the agent to achieve, for example “buy running shoes under a set price.” Use it when the user delegates a task and the agent acts later.

Cart mandate. This record holds the exact items and price the user approved. Use it when the user confirms a specific cart.

Payment mandate. This record signals to the payment network that an AI agent took part in the transaction, and it carries the details needed for authorization.

One outlet that covered the protocol describes the chain as intent, payment and receipt. Whichever naming a team uses, the logic is the same: each step leaves a signed record, and the records link together.

What Merchants Should Check

A mandate has value only when someone checks it. At authorization time, a merchant or payment provider can run a short list of tests.

1. Signature validity. Does the signature verify against a known key?
2. Scope match. Do the items, amount and category fit the mandate?
3. Time window. Is the mandate current and unexpired?
4. Single use or limits. Has the mandate already been spent, or does it allow repeat use?
5. Merchant binding. Is this merchant allowed to receive the payment?
6. Revocation. Has the user or operator revoked the mandate?

A failed test should lead to a decline or a step-up. Beyond that, a passed test should still feed the next layer, because a valid mandate can belong to a risky operator.

Replay and Theft

Attackers target mandates and tokens in predictable ways. They replay a captured mandate, steal a key or trick a user into granting a broad scope. Defenses include short expiry, single-use mandates, binding to a specific merchant and anomaly checks on use. Teams should treat mandate keys like payment keys, with rotation, storage controls and logging.

What Layer Two Proves

Mandates prove that a user, or someone with the user’s key, authorized a scope. They help in disputes, because they show what the user wanted. However, they do not prove that the user is honest, that the agent is safe or that the operator will not abuse a legitimate scope. A fleet can hold thousands of valid mandates. Notably, a compromised agent can act inside a valid mandate. A buyer can sign a mandate and then claim the agent erred.

Layer Three: Behavioral Evidence

The third layer answers the risk question. It looks at how the operator behind the agent behaves, where its money comes from and how many siblings it has. This evidence sits outside the transaction, so no amount of credential checking can replace it.

Why Paperwork Is Not Enough

Consider two agents that arrive with identical credentials and identical mandates. One belongs to a long-standing operator with a clean history. The other belongs to a fleet funded by a wallet that also funded known fraud. At the paperwork level, they look the same. Instead, at the behavior level, they differ sharply. The merchant needs to see that difference before it ships goods.

Tracker data shows how common the second kind is in an open registry. In the launch analysis of 274,792 ERC-8004 agents, 51.8% sat in the Elevated Risk or Untrusted tiers, and 21.1% carried the farm flag. Registration did not filter them out, because registration filters nothing about intent.

The Agent Trust Score

ChainAware’s Agent Trust Score turns behavioral evidence into a number and a set of flags. It rates ERC-8004 agents from 0 to 1,000 and groups them into five tiers.

Tier	Score range	Typical treatment at checkout
Sovereign	800-1000	Standard limits, light monitoring
Trusted	600-799	Standard limits, periodic review
Provisional	400-599	Lower limits, step-up above a threshold
Elevated Risk	200-399	Small limits, confirmation for most purchases
Untrusted	0-199	Decline

The score draws on four groups of evidence.

Owner wallet. Fraud probability of the wallet that owns the agent.

Feeder address. Funding source of the owner wallet, and what that address has done elsewhere. Our article on funding-chain risk explains why this signal matters.

Creator record. Rug pull or honeypot history of the agent’s creator.

Fleet detection. Links between this agent and a farm of agents.

Named flags such as FARM_DETECTED, FEEDER_UNKNOWN, FEEDER_RUG_HISTORY and CREATOR_RUG_HISTORY give merchants plain reasons for each decision. The score is free for public indexed agents, with 1,000 queries per month and no signup. Higher volumes are available through the API and the Prediction MCP.

How Merchants Read the Score

A tier gives a first decision. Flags refine it. A Trusted agent with a FEEDER_UNKNOWN flag may deserve a lower limit than a Trusted agent with a known, verified feeder. In addition, a Sovereign agent that suddenly shows a new farm link deserves a review. Merchants should treat the tier as a default and the flags as adjustments.

What Layer Three Proves

Behavioral evidence does not prove that a specific purchase is wanted. It estimates the likelihood of loss from the operator. Used with credentials and mandates, it lets merchants allow good traffic, limit uncertain traffic and refuse bad traffic. Moreover, used alone, it would miss permission questions that mandates answer.

An honest limit applies here. The score covers on-chain agents and their wallets. Card-only agents that never touch a public chain need behavioral data from their own ecosystems. The principle, judge the operator and its funding, transfers across rails.

Putting the Layers Together: A Decision Flow

A checkout engine can combine the three layers in a simple sequence. The flow below suits most merchants, and teams can adapt it to their stack.

Step	Check	Pass	Fail
1	Is the credential or token valid?	Continue	Decline
2	Does the signed mandate verify and cover this purchase?	Continue	Decline or ask the user
3	Which tier does the operator hold?	Set limits by tier	Untrusted: decline
4	Do any flags apply?	Adjust limits	Raise step-up level
5	Is the purchase within the tier limit?	Approve	Step up or decline
6	Store evidence	Log credential, mandate, tier and decision	Alert operations

Steps one and two are binary, because a missing credential or an invalid mandate ends the discussion. Furthermore, steps three to five are graded, because risk comes in degrees. Step six turns each decision into evidence for later disputes.

Order Matters

Run the cheap checks first. Credential and signature checks take milliseconds. A behavioral lookup may take longer, so teams should run it only for agents that pass the first two steps. Caching helps for repeat agents, as long as cache lifetimes are short for low tiers.

Three Requests, Three Outcomes

The examples below are invented to show the flow in action. They do not describe real merchants.

Request One: The Familiar Assistant

An agent from a well-known platform buys a book for a user. The token is valid. Likewise, the cart mandate matches the item and price. The operator holds the Sovereign tier and carries no flags.

Approval is instant. It stores the credential, the mandate and the tier. If the user later disputes the charge, the evidence shows that the user approved the cart.

Request Two: The Valid but Doubtful Agent

An agent buys ten gift cards in one session. The token is valid, and the intent mandate allows “gift purchases up to a set budget.” The operator holds the Elevated Risk tier, and the FEEDER_UNKNOWN and FARM_DETECTED flags apply.

Here the mandate fits, so a mandate-only system would approve. Beyond that, the behavioral layer changes the answer. The engine applies a small limit for the tier, notices that the request exceeds it and asks the user to confirm. Alternatively, the merchant can decline high-resale items for this tier altogether.

Request Three: The Forged Claim

A request arrives with a payment token that fails signature validation. Behavioral data is unavailable, because the agent identifier does not resolve. The engine declines at step one. No later layer is needed, and the cost of the decision is minimal.

What the Examples Show

Each layer stopped a different problem. Credentials stopped the forged claim. Mandates would have stopped an out-of-scope purchase. Behavioral evidence stopped the valid-but-doubtful agent. A system with only one or two layers would have missed at least one case.

Designing the Integration

Integration choices affect cost, speed and resilience. A few design points deserve early attention.

Where the Check Runs

Teams can run the behavioral check in several places. A merchant can call it from its checkout service. At the same time, a payment provider can run it inside its risk engine. A platform can run it at agent onboarding and refresh it on a schedule. The best design often combines two: a pre-checkout lookup for new agents and a scheduled refresh for known ones.

How to Call It

The Agent Trust Score is available through an API and through the Prediction MCP, so software agents and backends can call it directly. Merchants that already screen wallets can add the score to the same pipeline. The fraud detection API guide shows how wallet screening works at scale, and the article on Prediction MCP for AI agents explains how agents consume this data.

Latency and Fallbacks

Set a latency budget for the lookup, for example a few hundred milliseconds, and decide what happens on timeout. A safe default is a lower limit with a step-up, not a full approval or a full block. Log every fallback so that the team can review how often it triggers.

Evidence Storage

Store the credential reference, the mandate, the tier, the flags and the decision with a timestamp. Disputes arrive weeks later, and the stored record shows what the team knew at the time. The wider article on agentic commerce fraud and the four-party model explains how this evidence supports chargeback defense.

Attacks That Defeat One or Two Layers

Security teams learn most from failure cases. The scenarios below show how an attacker beats a system that relies on too few layers, and how the full stack responds.

Attack One: The Registered Fleet

An operator registers hundreds of agents. Each holds a valid credential, a valid token and a valid mandate. In addition, each buys one promotional item. A system with layers one and two sees hundreds of clean transactions.

Layer three sees one operator, one funding source and one farm flag. It groups the agents and applies limits at the operator level. The promotion cost drops from hundreds of purchases to a handful.

Attack Two: The Clean Front With a Dirty Funder

A fraud group creates a new wallet, funds it from an address with a history of rug pulls and registers an agent from that wallet. The agent looks new and spotless. Its credential verifies, and its mandates are valid.

Layer three follows the funding chain and finds the feeder’s record. The agent receives a feeder flag and a lower tier. Moreover, the article on funding-chain risk shows how the tracker found hundreds of agents tied to confirmed rug pull operators.

Attack Three: The Over-Broad Mandate

A user grants an agent a wide mandate, such as “buy whatever is needed for the project.” Later, the agent buys expensive items. Every purchase falls inside the mandate. The user disputes the charges.

Layer two cannot decide, because the mandate was valid. Still, layer three can help only indirectly. Likewise, still, tier-based limits cap the damage, and step-up rules for large purchases ask the user to confirm. The lesson is to keep mandates narrow and to match limits to risk.

Attack Four: The Stolen Key

An attacker steals a signing key from a weak operator and sends requests that appear legitimate. Credentials and signatures verify, because the key is real.

Layer three notices behavior that does not fit the operator’s baseline: new merchants, new timing, new amounts. Anomaly rules raise a step-up. Short key lifetimes and revocation shorten the window for abuse.

Attack Five: The Slow Reputation Build

An attacker runs a quiet agent for months to build a record, then abuses it at a chosen moment. A static check at onboarding would approve it.

Scheduled re-scoring and drift monitoring reduce the payoff. When funding, ownership or fleet links change, the tier changes, and limits follow. The weekly tracker shows that profiles move fast, with the median trust of new agents ranging from 918 in Week 36 to 101 in Week 41.

Checkout Policy by Merchant Type

The right policy depends on the product. Beyond that, the guidance below gives a starting point for common cases.

Digital Goods and Gift Cards

These items deliver instantly and resell easily. Merchants should set small limits for lower tiers, delay high-value deliveries and watch for bulk purchases. A decline for the two lowest tiers is a reasonable default.

Physical Goods

Physical goods give time to review. Merchants can approve orders from higher tiers quickly and hold orders from lower tiers for manual review before shipping. Shipping address checks add another signal.

Subscriptions and Recurring Payments

Recurring payments need standing mandates. Merchants should link each renewal to the original mandate, alert users when prices change and re-score the operator at each renewal cycle.

Travel and High-Value Bookings

High-value bookings deserve live confirmation for most tiers. Even Sovereign agents may need confirmation above a threshold. Merchants should store the mandate and the confirmation together.

Marketplaces and Platforms

Marketplaces face agents on both sides. They should score buyers and sellers and look for loops between linked agents. Platforms can also publish tier-based badges so that honest operators earn visible credit for a clean record.

Advice for Agent Builders and Operators

Agent builders face the other side of verification. A well-run operator wants checks to succeed quickly. Several practices help.

1. Use a stable, funded owner wallet. Fresh wallets with unclear funding start with lower tiers.
2. Fund from transparent sources. An exchange-verified feeder looks better than an unknown one.
3. Avoid mass registration. Many near-identical agents from one owner trigger fleet detection.
4. Keep mandates narrow and logs complete. Clear scope and full logs help in disputes.
5. Rotate keys and monitor for drift. Early detection limits damage.
6. Check your own score. Look up your agents before merchants do, and fix the causes of low tiers.

These steps also serve the operator’s business. Better tiers lead to higher limits, fewer step-ups and more completed purchases.

Building Trust Over Time

New agents start with thin histories, and a fair policy gives them a path. Lower limits at first, rising with a clean record, let honest newcomers grow. Operators can speed the process by funding transparently and by avoiding behaviors that look like farms.

Regulated Merchants and Platforms

Some merchants carry extra duties. Financial institutions, exchanges and payment firms must meet anti-money-laundering and sanctions requirements. The Financial Action Task Force publishes guidance on virtual assets, and the U.S. Treasury maintains the OFAC sanctions list service. Both apply regardless of whether a human or an agent initiates a payment.

For these teams, the verification stack grows by one step: sanctions and AML screening of the wallets involved. A detailed review tool such as ChainAware Investigation produces a structured report on a wallet in about a minute, and the page on autonomous compliance screening shows how agents and screening work together. Protocols can also consult the compliance guide for DeFi. Our comparison of DeFi compliance tools helps teams choose.

Measuring Whether Verification Works

Controls that nobody measures drift out of tune. A small dashboard keeps the stack honest.

Metric	Why it matters	Healthy direction
Agent share of checkout volume	Shows exposure	Tracked, not forced
Approval rate by tier	Shows that higher tiers pass more often	Rising with tier
Dispute rate by tier	Shows that lower tiers cost more	Falling with tier
Step-up rate	Shows friction for good customers	Low and stable
Mandate failure rate	Shows broken integrations or attacks	Low
Lookup latency	Shows impact on conversion	Within budget
Evidence completeness	Shows dispute readiness	Near 100%
Manual overrides	Shows policy gaps	Low, with reasons

Reading the Numbers

If dispute rates do not rise as tiers fall, the thresholds or the evidence need work. At the same time, if step-up rates climb, the policy may be too strict for honest traffic. If mandate failures spike, check for an integration change or an attack. Review the table monthly, and adjust limits with data.

Testing With Replay

Teams can test a new policy by replaying past agent transactions against it. The replay shows how many purchases the policy would have approved, limited or declined, and how those outcomes compare with real losses. This step costs little and prevents painful surprises in production.

Common Mistakes

Teams often repeat the same errors when they first verify agents. Knowing them in advance saves months.

1. Relying on one layer. A system with only credentials or only mandates leaves the largest gap open.
2. Treating a valid mandate as safe. A fleet can hold thousands of valid mandates.
3. Scoring agents individually. Fleets hide in operator-level patterns.
4. Checking once. Profiles change, so scores need a refresh cycle.
5. Blocking every agent. A blanket ban pushes good traffic away.
6. Approving every agent. Open acceptance invites cheap fleets.
7. Skipping evidence storage. Disputes then turn into guesswork.
8. Using vague prompts. Users who see unclear confirmations click through.
9. Ignoring fallbacks. A failed lookup needs a defined result.
10. Waiting for final standards. Standards will arrive slowly, while agent traffic grows now.

Gaps That Remain

No stack is complete today. Teams should plan with clear eyes about what remains open.

Liability rules. Networks and regulators are still defining who bears the loss for agent-initiated payments. One analyst argues that the merchant of record carries much of the risk by default. That view is opinion, so teams should confirm their position with acquirers and counsel.

Standard convergence. Several protocols and credential formats compete. Merchants may need to support more than one for some time.

Coverage. The Agent Trust Score covers on-chain agents and wallets. Agents that never touch a public chain need other behavioral sources.

Intent proof. No layer proves what a user truly wanted in their head. Mandates and confirmations get closest, and disputes will still occur.

Privacy. Behavioral evidence must follow data minimization and local law. Teams should document what they collect and why.

What This Means for Planning

Teams should build the stack in a modular way. Swap-friendly interfaces let a merchant adopt a new credential format or a new score source without redesigning checkout. Documented policies let the team explain its decisions to partners and regulators.

A 60-Day Rollout Plan

Teams can move from nothing to a working stack in two months.

Days 1 to 15: Baseline

Tag agent traffic in logs and reports. Record volume, approval rates and disputes by channel. Read your network and acquirer rules on agent-initiated payments.

Days 16 to 30: Layers One and Two

Add credential and token checks. Notably, add mandate verification where your protocols support it. Define decline and step-up behavior for failures.

Days 31 to 45: Layer Three

Pilot the behavioral score on a sample of agents. Compare outcomes by tier against disputes and approvals. Write limits by tier and by product type.

Days 46 to 60: Enforce and Measure

Turn the policy on for new agent traffic. Store evidence for every decision. Launch the dashboard and schedule a monthly review.

By day 60, the team has a layered stack, a measurable baseline and an owner. That result beats waiting, because agent volume grows each quarter.

Reading the Flags in Practice

Tiers give a quick default, and flags explain the reasons behind them. A merchant that understands each flag can tune policy with precision. The list below covers the flags that appear in ChainAware’s launch analysis, along with their share of the 274,792 indexed agents at that time.

Flag	Share of agents at launch	What it suggests	Practical response
FARM_DETECTED	21.1%	The agent belongs to a group of linked agents	Aggregate limits by operator
FEEDER_UNKNOWN	9.5%	The funding source has no clear identity or history	Lower limits, watch for change
EIP7702_DELEGATED	7.6%	The owner account delegates execution through EIP-7702	Review context, since delegation has legitimate uses
FEEDER_CEX_VERIFIED	1.0%	A verified exchange funded the owner	Positive signal, still check other flags
FEEDER_RUG_HISTORY	0.3%	The funder has a rug pull history	Treat as high risk
CREATOR_RUG_HISTORY	0.02%	The agent’s creator has a rug pull history	Treat as high risk

How to Use Flags Without Overreacting

A flag is a reason to look closer, not a verdict. Two principles keep policies fair.

Combine flags with the tier. A Trusted agent with one mild flag deserves different treatment than an Elevated Risk agent with three flags. The tier already accounts for much of the evidence, and flags explain it.

Match the response to the risk. Rug pull history on a funder or a creator deserves a strong response. An unknown feeder deserves caution and monitoring. A delegated account deserves a closer look at the context, because account delegation can serve legitimate needs such as batching and gas sponsorship.

Reading Rare Flags

The rarest flags carry the strongest signals. A creator with a rug pull history appears in a tiny share of agents, yet each case deserves attention. In the same way, the 741 agents that the analysis traced to funders involved in confirmed rug pull operations form a small but dangerous group. Merchants should treat these cases as near-automatic declines for high-value goods.

Edge Cases Every Checkout Team Meets

Real traffic is messier than diagrams. Teams should prepare for several awkward cases.

The Agent With No Record

A new agent may have no registry entry, no history and no score. The safest default is a low limit, a step-up for larger purchases and a prompt to complete registration. Over time, a clean record earns higher limits. Blocking every unknown agent would turn away the next generation of legitimate ones.

The Agent on Another Chain

Agents operate on several networks. The Agent Trust Score covers Ethereum, BNB Smart Chain, Base and Avalanche C-Chain, and Mantle is in progress. A merchant that sees an agent on an uncovered chain should fall back to wallet-level screening and conservative limits. The fraud detection API helps with the wallet side.

The Agent Paying Another Agent

Agent-to-agent payments are growing. One agent may buy a service from another, with no human at either end. Here both sides need verification. The buyer needs to know that the seller will deliver, and the seller needs to know that the buyer will pay. In addition, the overview of the Web3 agentic economy explains why machine-readable trust becomes essential in these flows.

The Delegated Sub-Agent

An assistant may hire sub-agents to complete tasks. Each sub-agent adds a link to the delegation chain. Merchants should look for the root operator and apply limits to the whole chain, not just to the last link. A mandate that names sub-agents explicitly makes the chain visible.

The Operator Under Review

Sometimes an operator disputes a decision or asks for a re-check. A defined appeal path helps. Teams can re-run the lookup, review the flags and adjust limits if the evidence has changed. Appeals also reveal model errors early.

Why Behavioral Data Beats Static Lists

Some teams start with allowlists and blocklists. Those lists help, yet they age quickly. A blocklist only catches wallets that someone already reported. An allowlist only covers operators that someone already vetted. Open agent ecosystems produce new identities faster than humans can review them.

Behavioral models work differently. They score patterns in real time, so a new wallet with a bad funding chain scores low before anyone reports it. The comparison of Web3 trust verification systems shows how different approaches handle new identities, and the review of the agent trust infrastructure race shows how providers position themselves.

Static and Dynamic Together

The best stacks use both. Allowlists reward known partners with a smooth path, and blocklists stop known bad actors at once. Behavioral scores cover the large middle, where most new agents sit. Combining the three yields speed, safety and fairness at once.

Sector Playbooks

Different sectors weigh the layers differently. The sections below give practical starting points.

Payment Providers and Gateways

Payment providers see traffic from many merchants and can spot patterns that no single merchant sees. They can tag agent traffic, run operator-level aggregation across merchants and offer tier-based rules as a service. Providers also hold the token and authorization data, which supports disputes.

A provider should expose clear controls. Merchants want to set limits by tier, choose step-up behavior and see the evidence behind each decision. Transparent controls build trust with merchants and reduce support load.

Marketplaces

Marketplaces connect buyers and sellers and take on trust for both. Agents may play either role. Marketplaces should score both sides, look for loops among linked agents and display trust signals to users. A tier-based badge helps honest sellers stand out.

Subscription and SaaS Businesses

Software firms face trial abuse, license resale and renewal disputes. Agents can create many trial accounts quickly. Operator-level limits on trials, mandates for renewals and tier-based eligibility for discounts reduce losses. Alerts on price changes keep users informed.

Exchanges and Financial Platforms

Exchanges and financial platforms carry the heaviest compliance load. They need credentials, mandates, behavioral scores and sanctions screening. Moreover, they also need audit trails that regulators can inspect. The extra layers cost effort but protect licenses and customers.

DeFi Protocols and DApps

Protocols that accept agent interactions need wallet-level screening, since funds move without chargebacks. Prevention matters more than dispute. The guide to Web3 fraud detection for DApps explains why screening wallets before they interact beats simulating transactions alone, and the overview of Sybil protection systems covers fleet defenses. Protocols that run on-chain agents can also read how investors evaluate AI trading agents.

Growth and Acquisition Teams

Growth teams use agents to find users, and attackers use agents to farm incentives. Behavioral scoring separates real users and honest agents from farms. The learn page on Web3 user acquisition shows how behavioral data supports targeting, and the same data helps filter abuse.

Architecture Patterns

Three patterns cover most deployments. Teams can pick one and evolve over time.

Inline check. The checkout service calls the verification stack synchronously. It suits low volume and simple stacks. Still, it gives the freshest answer but adds latency to every purchase.

Pre-check with cache. A background job looks up new agents as soon as they appear and refreshes known ones on a schedule. Checkout then reads from a local store. It suits high volume and keeps latency low. Cache lifetimes should be shorter for lower tiers.

Edge gateway. An API gateway or proxy performs credential, signature and tier checks before requests reach the checkout service. It centralizes policy and protects all downstream services. Likewise, it suits platforms with many services.

Common Components

All three patterns share a few components.

• Verifier. Validates credentials, signatures and mandates.
• Score client. Calls the trust score and normalizes tiers and flags.
• Policy engine. Maps tier, flags and purchase details to approve, step up or decline.
• Evidence store. Saves inputs and decisions with timestamps.
• Alerting. Notifies operations about failures, fallbacks and anomalies.

Separate these components behind clear interfaces. A team can then replace the score client or the credential format without touching the rest.

Governance, Privacy and Fairness

Verification touches sensitive questions, and teams should plan for them.

Documented policy. Write down tiers, limits and responses. Documentation helps audits, onboarding and partner reviews.

Data minimization. Store the evidence that supports a decision and avoid collecting more. Treat linked data with care even when identifiers are pseudonymous.

Explainable decisions. Give operators a plain reason for each limit or decline. Named flags and tiers make this easy.

Fair paths for newcomers. New agents have thin histories. Lower initial limits that rise with clean behavior give honest newcomers a way forward.

Human review. Offer an appeal route and review a sample of automated decisions each month.

Change control. Track changes to thresholds and models. A change log explains shifts in approval and dispute rates.

Aligning With Legal and Compliance

Involve legal and compliance early. They should review liability maps, retention periods and customer notices. In regulated sectors, they should also confirm how sanctions and AML duties apply to agent flows.

Weighing the Cost of Verification

Verification has costs: engineering time, lookup fees at scale, added latency and some friction. It also has benefits: fewer chargebacks, fewer promotion losses, faster disputes and a safer channel. A simple way to judge the trade-off is to compare the cost of a layer with the loss it prevents.

Layers one and two usually pay off quickly, since they stop forgery and out-of-scope purchases at low cost. Layer three pays off wherever fleets, cheap identities or high-resale goods exist. Teams can start with the free tier of the Agent Trust Score and measure the effect on their own traffic before they commit to larger volumes.

Writing the Policy Down: A Sample Structure

A written policy turns good intentions into repeatable decisions. Teams can adapt the outline below to their own business. It is a template, not legal advice.

Scope and Definitions

Define what counts as an agent, an operator and an agent-assisted purchase. Moreover, state which products and channels the policy covers. Clear definitions prevent arguments later, particularly when a purchase mixes human and agent steps.

Required Evidence

List the evidence that every agent purchase must carry. A typical list includes a valid credential or token, a verifiable mandate and a behavioral tier from an approved source. In addition, state what happens when a piece is missing, for example a decline for a missing credential and a step-up for a missing score.

Limits and Responses by Tier

Include the tier table with explicit limits for each product type. Furthermore, define the response to each flag. Plain tables work better than prose here, because operations teams will use them daily.

Escalation and Appeals

Name the owner for escalations and set a response time for appeals. Likewise, describe how a team member records an override and why. Overrides without reasons make later review impossible.

Review Cadence

Set a monthly metrics review and a quarterly policy review. Besides that, record who approves threshold changes. A short change log helps explain movements in approval and dispute rates.

Testing and Red-Teaming the Stack

Controls that nobody attacks tend to fail on the first real attempt. Teams can test their stack in three ways.

Unit tests for each layer. Feed the verifier forged credentials, expired tokens and tampered mandates. Confirm that each case produces the intended decision. Similarly, feed the policy engine edge cases, such as a lookup timeout or a missing flag.

Replay tests with real traffic. Teams run past agent transactions against the new policy. Compare predicted outcomes with real disputes. As a result, the team sees where thresholds are too loose or too strict.

Adversarial exercises. Ask a small group to behave like an attacker. They can register several agents, split a large purchase across them and test whether operator-level limits hold. Afterwards, they should try to build a clean-looking agent with a poor funding source and see whether the behavioral layer catches it.

What to Fix First

Rank findings by loss potential and by ease of exploitation. Fleet splitting and forged credentials usually top the list. Meanwhile, cosmetic issues can wait.

Questions to Ask Providers

Teams that buy credentials or scores should ask direct questions. The list below applies to both.

1. What exactly does the product verify? Ask for a plain description of inputs and outputs.
2. How does it treat new identities? A good product scores them on behavior and does not simply wait for reports.
3. Can it detect fleets? Agent-level scores alone miss them.
4. How often does it refresh? Static scores age quickly.
5. Does it explain decisions? Named flags and tiers help with disputes and appeals.
6. What does it not cover? Honest providers state limits openly.
7. How does it handle privacy? Look for data minimization and clear retention rules.
8. What does it cost at scale? Compare free tiers, per-lookup pricing and volume terms.

ChainAware answers the sixth question plainly: the Agent Trust Score covers on-chain agents and wallets, and card-only ecosystems need their own data. That answer is a feature of an honest product, not a weakness.

Training the Team

Technology alone does not protect a checkout. Analysts, support staff and product owners need a shared picture of how agent traffic works.

Fraud analysts should learn the three layers, the tier table and the flags. They should practice reading operator-level views as well as single transactions.

Support staff should know how to explain a step-up or a decline to a customer in plain language. In practice, a good script reduces frustration and repeat contacts.

Product owners should design confirmation prompts that state the merchant, the amount and the reason. Clear prompts keep users engaged. Vague ones train users to click through.

Engineers should understand the evidence store and the fallback rules. Consequently, they can debug incidents quickly and keep logs complete.

A short monthly review that brings these groups together keeps the policy alive. Each meeting can cover the dashboard, the largest overrides and one lesson from a recent dispute.

Myths About Agent Verification

Several myths slow teams down. Clearing them early saves effort.

Myth: A Registered Agent Is a Safe Agent

Registration proves that someone filled in a form or sent a transaction. In open systems, it costs little. As a result, bad actors register in bulk. The launch analysis found that more than half of the indexed agents sat in the two lowest tiers, so registration alone clearly filtered very little.

Myth: Mandates Solve Disputes

Mandates help, yet they do not settle every case. A user may sign a broad mandate and later regret it. Likewise, an operator may abuse a valid scope. Mandates show what was allowed, but they cannot show what the user truly meant.

Myth: Blocking Agents Is the Safe Choice

Blocking looks safe, but it gives up a growing channel. Meanwhile, competitors that verify and accept good agents win the volume. Tiered limits keep the channel open and the risk bounded.

Myth: Behavioral Scores Replace Human Judgment

Scores guide decisions, but people still set policy, handle appeals and review edge cases. In other words, the score is an input and not an authority. Teams that treat it that way avoid both blind trust and blind distrust.

Myth: Small Merchants Cannot Afford This

Small merchants can start with free tools, simple tier tables and basic logging. Besides that, many payment providers will absorb part of the work as agent traffic grows. Starting small beats not starting.

An Integration Checklist

Use the checklist below to confirm that nothing is missing before launch.

• Agent traffic carries a channel tag in logs and reports.
• Credential and token checks run before any other step.
• Mandate verification covers signature, scope, time and revocation.
• The score client normalizes tiers and flags, and handles errors safely.
• Policy engine rules map tiers and flags to limits and step-ups.
• Operator-level aggregation covers velocity, spend and refunds.
• The evidence store keeps credential references, mandates, tiers, flags and decisions with timestamps.
• Dashboards show approval, dispute and step-up rates by tier.
• Alerts cover lookup failures, fallbacks and mandate failure spikes.
• An appeal route exists, and an owner answers it.
• Legal and compliance have reviewed liability, retention and notices.

Teams that tick every box have a stack that works in practice. In addition, they can show regulators, partners and customers how decisions get made.

Final Check Before Go-Live

Run one more rehearsal with real test data. Send a valid agent, a forged agent, an out-of-scope purchase and a low-tier operator through the full flow. Confirm that each case produces the expected decision, the expected log entry and the expected alert. Then schedule the first monthly review before the launch date, so that the learning loop starts on day one.

Where Agent Verification Is Heading

Four shifts will shape the next two years.

Credential Formats Will Converge

Merchants will not support dozens of formats forever. Standards groups and networks will narrow the field, and thin adapter layers will bridge the gap in the meantime.

Mandates Will Become Routine

As agents handle more purchases, signed mandates will move from novelty to default. Disputes will lean on them, and regulators will ask for them.

Behavioral Layers Will Join the Standard Stack

Credentials and mandates prove permission. Behavioral evidence estimates risk. Risk teams will expect all three, much as they expect tokens, authentication and scoring in card flows today.

Tracker Data Will Guide Policy

Public datasets, such as the weekly ERC-8004 tracker, show how open agent ecosystems behave. Registrations reached a record 31,979 in Week 34 and fell to 10,706 by Week 41, while median trust for new agents swung from 918 in Week 36 to 101 in Week 41. The article on agent fraud patterns from the tracker explains these swings. Teams can use such data to size controls for peaks as well as averages.

Why the Third Layer Rests on a Proven Record

The behavioral layer is only as good as the models and the data behind it. Review-based scores fail on both counts, since 50 fake agents can upvote a 51st. The Agent Trust Score uses on-chain behavior only, and an attacker’s address and feeder pass through ChainAware’s machine-learning fraud detection. In addition, the company reports 95% accuracy for its per-address fraud model, verifiable through ScamDB, and its rug pull model predicted 90.1% of cases before they happened in a documented PancakeSwap test. The score predicts risk and does not rank agents.

Key Facts at a Glance

• Checkout verification for agents needs three layers: credentials and tokens, mandates and behavioral evidence.
• Credentials and tokens show who the agent is and how it pays.
• Mandates show what the user allowed.
• Behavioral evidence shows how risky the operator is, and only this layer separates a trustworthy agent from a well-documented bad one.
• The Agent Trust Score rates ERC-8004 agents from 0 to 1,000 across five tiers.
• At launch, 51.8% of 274,792 indexed agents sat in the Elevated Risk or Untrusted tiers.
• The score is free for public indexed agents, with 1,000 queries per month and no signup.
• Coverage extends to on-chain agents and wallets. Card-only agents need other behavioral data.

Frequently Asked Questions

How do you verify an AI agent at checkout?

Combine three layers: validate the agent’s credential and payment token, verify the signed mandate that shows what the user allowed, and check behavioral evidence about the operator. Then apply limits and step-ups by tier.

What is a mandate in agentic commerce?

A mandate is a signed record of what a user authorized an agent to do. AP2 describes intent, cart and payment mandates.

Is a valid token enough to trust an agent?

No. A token shows a payment route. Beyond that, a bad operator can hold a valid token, so merchants also need behavioral evidence.

What does the Agent Trust Score measure?

It scores the owner wallet’s fraud probability, the feeder address that funded it and the creator’s rug pull and honeypot record. Fleet-level detection adds a view across agents. The result is a 0 to 1,000 score with five tiers.

What are the five tiers?

Sovereign (800-1000), Trusted (600-799), Provisional (400-599), Elevated Risk (200-399) and Untrusted (0-199).

Which chains does the score cover?

Ethereum, BNB Smart Chain, Base and Avalanche C-Chain, with Mantle in progress.

Is the Agent Trust Score free?

Yes for public indexed agents, with 1,000 queries per month and no signup. Higher volumes run through the API or the Prediction MCP. See the Agent Trust Score page for details.

What should a checkout do when the lookup fails?

Apply a safe default: a lower limit with a step-up, not a full approval or a full block. Log every fallback.

How do you stop agent fleets at checkout?

Aggregate limits by operator and by shared funding source, and use fleet detection to link agents. Per-agent limits miss fleets.

Who is liable if an agent makes a bad purchase?

Rules are still developing. Some analysts expect the merchant of record to carry much of the risk by default. Confirm your position with your acquirer and counsel.

Can a small merchant use this?

Yes. A small merchant can start with the free tier, a simple tier-based limit table and basic evidence storage.

What should a team do first?

Tag agent traffic, add credential and mandate checks, pilot the behavioral score and write limits by tier.

A Short Glossary

• Agent credential: a verifiable record that identifies an agent and its operator.
• Payment token: a limited-use stand-in for a payment method.
• Mandate: a signed record of what a user authorized an agent to do.
• Operator: the person or company that runs the agent.
• Feeder: the address that funded an agent’s owner wallet.
• Fleet or farm: a group of linked agents under one operator.
• Tier: one of five bands of the Agent Trust Score.
• Step-up: an extra confirmation before approval.
• Know Your Agent (KYA): the process of deciding whether an agent may act and how far.

Conclusion: Verify in Layers

Checkout used to verify a person. Now it must verify an agent, the permission behind it and the operator who stands behind both. Credentials and tokens answer the first question. Mandates answer the second. Behavioral evidence answers the third, and it answers the one that decides losses.

Start with the basics. Tag agent traffic, check credentials and mandates, and add a behavioral tier to every decision. Store the evidence, measure the results and adjust limits each month. Agent volume grows every quarter, so early work pays off.

For the wider picture, read the pillar guide to Know Your Agent, the analysis of KYA versus agent identity and the study of agentic commerce fraud and the four-party model. The launch article on the Agent Trust Score lists the full tier data, and the piece on why trust comes first in agentic commerce explains the strategic case.