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.

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.

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.

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.

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.

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.

The post Verifying AI Agents at Checkout: Tokens, Mandates and Behavioral Evidence first appeared on ChainAware.ai.

The card system was built for a person at a checkout. Autonomous AI agents change that assumption, and the four-party model has no clean answer yet for who pays when an agent’s purchase goes wrong. This guide walks through the model, the new fraud surface that agents create, and what a Know Your Agent layer adds for fraud and risk teams at issuers, acquirers, payment service providers and merchants.

For decades, card fraud controls rested on one quiet assumption: a human decides, a human clicks and the system can observe that human. Device fingerprints, typing rhythm, mouse movement and session history all feed risk engines on that assumption. When a software agent buys on a user’s behalf, most of those signals disappear. The agent runs on a server, it has no mouse and its session looks nothing like a shopper’s.

Industry players have noticed. OpenAI and Stripe launched the Agentic Commerce Protocol. Google introduced the Agent Payments Protocol, known as AP2. Card networks have announced their own programs for agent-initiated payments, and identity vendors have started to sell Know Your Agent products. These efforts matter, because they build the pipes. However, pipes do not decide which agents deserve trust, and they do not settle who bears the loss when something breaks.

This article focuses on that gap. It starts with a short refresher on the four-party model, then shows how agents strain each part of it. In addition, it lists the new fraud scenarios that follow, and it explains what a behavioral trust layer adds. It also keeps a clear view of limits. The Agent Trust Score covers agents and wallets on public chains, and card-only ecosystems need their own behavioral data. Moreover, the design lessons still transfer, and they help risk teams plan today.

A Short Refresher: The Four-Party Model

Card payments involve four parties, and a card network connects them.

• Cardholder: pays for goods or services with a card.
• Merchant: sells the goods or services and accepts the card.
• Issuer: the cardholder’s bank. It extends credit, approves or declines each transaction and bears the credit risk.
• Acquirer: the merchant’s bank or processor. It accepts card transactions on the merchant’s behalf and settles funds to the merchant.

The card network sits between issuer and acquirer. It sets the rules, routes messages and runs dispute processes. Payment service providers often sit between merchants and acquirers, so that small merchants can accept cards without dealing with banks directly.

How a Transaction Flows

A typical online card payment moves through four stages. The cardholder submits card details at checkout. Furthermore, the merchant or its payment provider sends an authorization request through the acquirer and the network to the issuer. The issuer runs its own fraud and credit checks and returns an approval or decline. Later, clearing and settlement move the money between banks.

Fraud controls act at several points in this flow. Merchants screen orders before they send them. Acquirers and payment providers add their own scoring. Issuers make the final call using their own models, which draw on the cardholder’s history. Networks add rules and shared intelligence. Each party sees a different slice of the evidence.

How Liability Works

Liability follows a long-standing logic. The party best placed to stop a fraud usually carries the loss. Authentication tools such as 3-D Secure shift liability toward the issuer when the cardholder is verified, because the issuer took part in the check. A card-not-present fraud that slips past the merchant often lands on the merchant as a chargeback. Disputes follow network rules, and evidence from each party decides the outcome.

This system works because the parties can observe the cardholder. The issuer knows the customer’s history. Likewise, the merchant sees the session. The network sees patterns across millions of transactions. Every control assumes that someone could verify a human, and that assumption now faces strain.

What Agentic Commerce Changes

In agentic commerce, a software agent chooses what to buy and completes the purchase on the user’s behalf. McKinsey estimates that agent-mediated commerce could reach between $3 trillion and $5 trillion globally by 2030. Even if the real number lands lower, the direction is clear: a growing share of purchases will start with an agent and not with a person at a screen.

The New Rails

Several efforts build the rails for these purchases.

The Agentic Commerce Protocol. OpenAI and Stripe launched a protocol that lets an agent pay through a shared payment token, without exposing raw card details. Payments Journal described the launch as an effort to make agent checkout safe and standard.

AP2. Google’s Agent Payments Protocol uses verifiable credentials and signed mandates to record what a user asked for and approved. Its announcement describes it as an extension of existing agent communication standards.

Network programs. Visa and Mastercard have each announced programs for agent-initiated payments. A report on the Visa and OpenAI partnership shows how networks and AI companies are moving together. Beyond that, a commentary on liability describes Mastercard’s approach as using signed requests so that merchants can recognize trusted agents.

Identity frameworks. Trulioo describes a Digital Agent Passport that carries an agent’s origin, legitimacy, authorization and consent, and its Know Your Agent explanation frames the idea for payments.

What the Rails Solve and What They Leave Open

These efforts solve real problems. Tokens keep card numbers out of agent hands. Credentials let merchants recognize registered agents. Mandates record what a user allowed. Each of these is a building block of safe agent commerce.

None of them, however, answers the risk question: how likely is this agent, and the operator behind it, to cause a loss? A valid token shows a payment route. At the same time, a valid credential shows registration. A signed mandate shows permission. Notably, a bad operator can hold all three. Fraud teams therefore need a further layer of evidence.

The Lost Signal

Fraud models for card-not-present traffic lean heavily on signals about the person. Risk engines read a long list of them.

• Device fingerprint. Browser, operating system, screen size and installed fonts identify a returning device.
• Behavioral biometrics. Typing cadence, mouse paths and touch pressure distinguish a human from a script.
• Session history. Pages visited, time on page and cart changes show how a real shopper behaves.
• Location and network signals. IP address, geolocation and network type support or contradict the stated address.
• Account history. Past orders and returns build a profile that the issuer and merchant both use.

A server-side agent produces almost none of these. It has no mouse, no typing and no browser in the human sense. Its network address may belong to a cloud provider. One payments analyst describes the effect as “a total loss of the traditional fraud signal” in a liability deep dive. The piece is opinion rather than settled rule, but the underlying mechanics are easy to verify. A risk model that relied on typing rhythm has nothing to read when no one types.

The Trade-Off Risk Teams Face

The lost signal forces a trade-off. If a risk engine cannot tell a legitimate agent from a bot attack, it can decline agent traffic or accept it blindly. Declining hurts good customers and gives up a growing channel. Accepting invites fraud and may leave the merchant holding the loss.

Neither choice scales. A third path exists: replace the lost human signals with signals that describe the agent. Three families of such signals are emerging.

1. Authorization signals. Did the user grant this agent this scope? Signed mandates answer this.
2. Credential signals. Is the agent registered and verified? Passports, tokens and network credentials answer this.
3. Behavioral signals about the agent and its operator. How does the agent act, who funds it and how many siblings does it have? This family is where fraud teams have the least tooling today.

The first two families prove permission. In practice, the third estimates risk, and risk is what the fraud team ultimately manages.

The Fifth Participant

Commentators describe the agent as a fifth participant in the four-party model. It is not a cardholder, a merchant, a bank or a network. Yet it sits between the cardholder and the merchant, and it influences every decision. It chooses the product, picks the merchant and triggers the payment.

The liability deep dive argues that the merchant of record is likely to carry the loss by default. In addition, the reasoning is simple. The merchant is the visible seller and the party named in a dispute. When an agent buys something the cardholder did not want, the cardholder disputes the charge, and the chargeback reaches the merchant.

This is analysis and opinion. It is not settled rule. Networks, acquirers and regulators are still working out liability for agent-initiated transactions. Rules may differ by network, by region and by the protocol that carried the payment. The planning assumption for risk teams is nonetheless clear. Until rules say otherwise, expect chargebacks to land with the party closest to the merchant, and expect disputes to be harder because intent is harder to prove.

Why Intent Becomes the Central Question

In a human purchase, intent is rarely in doubt. The cardholder clicked and typed. In an agent purchase, a chain of delegation separates the cardholder from the act. The user told an assistant to buy something. Moreover, the assistant chose a product and a merchant. A payment protocol carried the request.

When the user later disputes the charge, three questions arise. Did the user authorize this purchase? Furthermore, did the agent follow the instruction? Did someone tamper with the agent? Each question needs evidence, and the evidence lives in different places. Signed mandates help with the first question. Agent logs help with the second. Integrity checks and behavioral monitoring help with the third.

New Fraud Scenarios

Agentic commerce adds specific failure modes beyond ordinary card fraud. The list below describes six of them, and each comes with a defensive idea.

Agent Impersonation

A fraudulent agent claims to act for a legitimate user. Without strong binding between the agent and the user, the merchant sees a valid token and little else. An attacker who steals a token or who tricks a user into delegating can use it at many merchants within minutes.

Defense: Bind tokens to specific agents and merchants, use short expiry times and require signed requests that tie the call to a registered agent.

Mandate Abuse

An agent acts outside its granted scope, for example by exceeding an amount, choosing a different merchant category or repeating a purchase. Signed mandates reduce the risk, but only when the merchant or payment provider checks them.

Defense: Verify mandates at authorization time, compare amount, merchant and time with the signed scope and decline or step up when the request falls outside it.

Agent Drift

The same liability analysis describes agent drift. An agent gradually changes behavior as its instructions, tools or underlying model change. It remains technically authorized, yet it acts in ways the user did not intend. Drift produces disputes without clear fraud, which is a hard category for dispute teams.

Defense: Track each agent’s behavior over time, flag changes in spend, merchants or timing and ask for re-authorization after large shifts.

Fleet Abuse

An operator runs many agents that look independent. Each makes small, plausible purchases. Together they exploit promotions, refund policies or reseller margins. Fleet abuse is hard to see transaction by transaction, because each transaction looks normal.

Defense: Aggregate velocity, spend and refund rates by operator and by shared funding source, and treat linked agents as one risk unit.

Friendly Fraud With an Agent Alibi

A buyer disputes a legitimate purchase and claims that the agent bought it by mistake. Dispute teams lack evidence standards for this claim. Without logs of the instruction, the mandate and the agent’s reasoning, the merchant cannot tell a true error from an opportunistic dispute.

Defense: Store mandates, instructions and decision logs for every agent transaction, and make them part of the dispute evidence package.

Compromised or Malicious Agents

An agent built on weak code or steered by a hostile prompt can make harmful purchases. The user’s authorization exists, but the action does not reflect the user’s wishes. This scenario blends security and fraud, and it will grow as agents read untrusted web content.

Defense: Combine integrity checks with behavioral monitoring, and cap what any agent can do without fresh human confirmation.

What a Behavioral Trust Layer Adds

Most of the scenarios above share one feature: the useful evidence sits outside the transaction. It concerns the agent’s operator, its funding and its history. A behavioral trust layer produces exactly that evidence.

The Agent Trust Score

ChainAware’s Agent Trust Score does this for ERC-8004 agents on public chains. It scores the owner wallet’s fraud probability, the feeder address that funded the owner and the creator’s rug pull and honeypot record. Fleet-level farm detection adds a view across agents. The output is a 0 to 1,000 score, five tiers from Untrusted to Sovereign and named flags. Likewise, the score is available through an API and through the Prediction MCP, so that software can call it before it acts.

The evidence maps to the scenarios in the previous section. Beyond that, the owner’s fraud probability and the creator’s record help against malicious operators. The feeder helps against impersonation and laundered credibility. Fleet detection helps against fleet abuse. Tier changes over time help against drift.

What the Public Data Shows

For the registry as a whole, the numbers are sobering. In the launch analysis of 274,792 ERC-8004 agents, 51.8% sat in the two lowest tiers, and 21.1% carried the farm flag. The tier split was Sovereign 20.9%, Trusted 12.7%, Provisional 14.6%, Elevated Risk 25.8% and Untrusted 26.0%. At the same time, the launch article lists the full breakdown.

By Week 41 of 2026, the index held 568,590 agents, and the median trust of that week’s new registrations had fallen to 101, the lowest since tracking began. The Week 41 tracker has the full picture, and the companion article on agent fraud patterns from the tracker explains what the weekly series reveals about concentration, farms and funding.

Payments teams should draw a direct lesson. Cheap identities scale faster than trust. If a registry with open registration produces this mix, any agent ecosystem without behavioral scoring will face the same dynamics.

An Honest Limit

The Agent Trust Score covers on-chain agents and wallets. A card-network agent that never touches a public chain falls outside it. Closed ecosystems hold their own behavioral data, and the scoring of that data belongs to the network, the issuer or the platform. The design principle still transfers: judge the operator, its funding and its fleet, not just the paperwork. As stablecoin settlement and wallet-based agent payments grow, the on-chain layer will move closer to payments risk stacks.

Mapping Agent Evidence to the Four-Party Model

Each party in the card chain faces a different exposure, and each needs different evidence. The table below summarizes the picture.

Each party needs different evidence, but all of it describes the agent and its operator. Notably, the sections below describe what each party can do now.

Issuers

Issuers decide whether to approve each authorization request. When the request comes from an agent, the issuer loses the human signals it normally reads. It can ask for the agent credential and the mandate in the authorization message where networks support them, and it can tune decline and step-up rules for agent-flagged traffic.

Issuers can also build a view of the operators behind agent transactions. When one operator generates many small purchases across many cards, the pattern deserves attention. A shared behavioral score for operators, whether built in-house or sourced from a provider, helps the issuer separate honest assistants from fleets.

Acquirers and Payment Service Providers

Acquirers and PSPs onboard merchants and manage their risk. They can tag agent traffic, track chargeback rates by agent channel and set conservative limits for merchants that start to accept agent checkout. In practice, they can also require merchants to log mandates and credentials, because that evidence supports disputes later.

Acquirers face a portfolio view. If a growing share of a merchant’s volume comes from a handful of operators, concentration risk rises. A fleet-level report helps the acquirer see that concentration before a loss.

Merchants

Merchants carry the visible liability. They can require a credential for agent checkout, verify mandates and attach a behavioral tier to each agent order. In addition, they can set order limits by tier and treat unusual repeat purchases from one operator as a fleet signal.

Merchants also gain from clear policy. A published agent policy tells operators what the merchant requires, which saves disputes. Moreover, a merchant that asks for credentials, mandates and a minimum tier attracts honest agents and deters low-effort abuse.

Card Networks and Standards Bodies

Networks can define liability for agent flows, publish agent authentication specifications and share fleet-level signals across members. Standards bodies can agree on credential formats so that merchants do not need to read a different format for each agent. Both groups can help create evidence standards for disputes that involve agents.

Agent Operators

Operators sit in the fifth seat. They carry responsibility for what their agents do. Operators can keep clean funding structures, keep full logs of instructions and mandates and monitor their own agents for drift. An operator with a strong record earns better treatment from every other party.

A Scenario Walk-Through

The scenario is invented to show how the pieces fit. It does not describe a real transaction.

A shopper tells an assistant agent to renew a software subscription and to buy a replacement laptop battery if it costs under a set amount. The agent holds a payment token and a signed record of the instruction. It visits a merchant and attempts a purchase.

The merchant’s PSP sees a valid token and a signed record. In a human flow, it would also see a device and a session. Here it sees neither. The risk engine must decide using what remains.

Next, the engine checks the credential, which passes. It checks the signed scope, which matches the amount and the category. Then it asks about the operator behind the agent. If the agent is a known, long-standing assistant from a reputable platform, the engine approves. Furthermore, if the agent belongs to a fleet of near-identical agents that made forty small purchases of resalable goods across forty merchants today, the engine limits or declines.

The difference between the two outcomes is behavioral evidence about the agent and its operator. Credentials and signed scope were identical in both cases. The example shows why the third layer matters, and it shows how the layers work together.

A Practical Risk Policy for Agent Traffic

Risk teams can start with a short policy and refine it over time. The seven steps below work for issuers, acquirers, PSPs and merchants alike.

1. Classify the channel. Tag every transaction as human, agent-assisted or fully autonomous. Do this first, because every later metric depends on it.
2. Require a credential. Accept agent traffic only with a verifiable agent credential or token.
3. Check the mandate. Compare amount, merchant and time with the signed scope.
4. Score the operator. Use behavioral evidence about the agent’s owner, funding and fleet.
5. Set tier-based limits. Higher tiers earn higher limits and fewer step-ups.
6. Log for disputes. Keep the mandate, the credential, the score and the tier at decision time.
7. Review drift. Track agents whose behavior changes over time.

Start with limits, not blocks. Declining all agent traffic cedes a growing channel. Accepting all of it ignores the risk. A tiered policy sits between the two, and it improves as data accumulates.

A Tier-Based Treatment Table

The table below shows one way to map operator tiers to checkout treatment. Teams should adapt it to their own risk appetite.

Aggregate by Operator

Limits per agent miss fleets. Aggregate velocity, spend and refund rates by operator and by shared funding source, so that one party cannot split a large purchase across many agents. Aggregation costs little and closes the most common loophole.

Metrics That Show Whether the Controls Work

A policy deserves measurement. Teams can track a short list of indicators and tune thresholds with data instead of guesswork.

• Approval rate by channel and tier. Higher tiers should show higher approval rates.
• Chargeback and dispute rate by channel and tier. Lower tiers should account for more losses. If they do not, thresholds need work.
• Step-up rate. Good customers should not face too many confirmations.
• Fleet detections. Count how many operators aggregate limits catch.
• Time to decision. Added latency can hurt conversion.
• Evidence completeness. Measure how many agent transactions carry a stored mandate, credential and score.
• Overrides. Every manual override needs a reason, and patterns point to policy gaps.

Leadership benefits from these numbers too. They turn a vague promise of agent safety into a visible control with measurable results.

What Fraud Teams Should Ask Their Vendors

Buyers can use a short list to test whether a product addresses agent risk or only relabels existing tools.

1. Which signals replace the human behavioral signals that agents remove?
2. Can the product tell an agent from a bot attack?
3. Does it detect fleets that spread small purchases across many agents?
4. How does it evidence its decisions for a dispute?
5. Does it re-evaluate agents over time, or only at onboarding?
6. What does it say it cannot cover?

Honest vendors answer the last question openly. A product that claims to cover everything has not described its limits. The same standard applies to ChainAware’s own score, which is why this article states plainly that the Agent Trust Score covers on-chain agents and wallets.

How Strong Authentication Fits an Agent Flow

Strong customer authentication exists to prove that the cardholder approved a payment. Tools such as 3-D Secure ask the cardholder to confirm through a challenge, and in return the liability for certain fraud shifts toward the issuer. The design assumes a person who can respond to a prompt on a phone or in a browser.

An autonomous agent cannot complete that challenge on its own. It has no fingerprint, no banking app and no one-time code. Teams therefore face a design question: where does the human approval happen, and how does the payment system learn about it? Two broad answers exist.

Approval before delegation. The user approves a scope up front, for example a monthly budget or a list of merchants. A signed mandate records that approval, and later payments reference it. This model fits routine purchases, such as subscription renewals.

Approval at purchase time. The agent pauses and asks the user to confirm a specific purchase. A confirmation may happen in a chat window or a banking app. This model fits large or unusual purchases.

How networks and issuers treat each model for liability purposes is still evolving. Risk teams should read their current network rules and ask their acquirers for guidance. Meanwhile, the practical advice is simple: store proof of whichever approval happened, and store it in a form that a third party can verify.

Where Behavioral Evidence Helps Authentication

Behavioral evidence about the operator does not replace the cardholder’s approval. It does help decide when to ask for one. A purchase from a long-standing, well-funded operator may need only the standing mandate. In addition, a purchase from an operator with a young wallet, an unknown funder and many sibling agents may deserve a live confirmation. Moreover, in this way, risk-based authentication extends naturally to agents.

Promotion and Refund Abuse at Machine Speed

Promotion abuse is one of the first places where agent fleets will pay off for attackers. A human can claim a sign-up bonus a few times before fatigue sets in. Furthermore, a fleet of agents can claim it thousands of times, each with a fresh identity and a plausible purchase.

Several features make the abuse attractive.

• Low unit risk. Each claim is small, so no single transaction triggers a review.
• Scripted patience. Agents can wait, rotate merchants and vary timing to avoid simple velocity rules.
• Cheap identities. Open registries make new agent identities nearly free, as the tracker data shows.
• Resale paths. Gift cards, digital goods and refundable items convert promotions into cash.

Refund abuse works in a similar way. A fleet buys, returns and repeats, and it captures a margin each time. Merchants that offer instant credit for returns face the highest exposure.

Controls That Work

Defenders can combine three controls.

1. Operator-level limits. Cap promotions, refunds and spend per operator and per funding source, not per agent.
2. Tier-based eligibility. Offer the best promotions to agents in higher trust tiers. Lower tiers receive standard offers or require human confirmation.
3. Delayed benefits. Release credits after a cooling-off period, so that fleet patterns appear before the merchant pays out.

The first control matters most. In the open registry, the weekly tracker shows farm shares between roughly 16% and 21% of agents in the weeks covered. If a payments ecosystem produces anything close to that mix, per-agent limits will fail, because the farm splits its activity across the many agents it controls.

Merchant Playbooks by Business Type

Agent risk differs by what a merchant sells. The right controls depend on delivery speed, resale value and dispute patterns.

Digital Goods and Software

Digital goods deliver instantly and resell easily. Fraud losses here come fast, and recovery is rare. Merchants should apply strict operator limits, delay high-value deliveries for lower tiers and watch for bulk purchases of keys, credits or gift cards.

Physical Goods

Physical goods give the merchant time. Shipping addresses, carrier data and delivery confirmation create extra evidence. Merchants should check the shipping address against the operator’s history and flag new addresses used by many agents.

Travel and Ticketing

Travel and ticketing involve high values and tight time windows. Agents will search and book at machine speed. Merchants should require stronger credentials and live confirmation for large bookings, and they should record the mandate that covers each trip.

Subscriptions

Subscriptions raise questions about recurring authority. An agent that renews a plan every month needs a mandate that says so. Merchants should tie each renewal to a standing mandate and alert the user when the price changes.

Marketplaces

Marketplaces face two-sided risk. Agents can act as buyers, sellers or both. A marketplace should score operators on each side and look for loops in which linked agents trade with one another to inflate reviews or volume.

When to Ask a Human to Confirm

A human in the loop adds friction, so teams should ask for confirmation only when risk justifies it. Likewise, a short rule set helps.

• Amount above a threshold. Set thresholds by tier, with lower limits for lower tiers.
• New merchant category. Ask when the agent leaves its usual pattern.
• New or changed mandate. Ask when the scope changes.
• Flag from the behavioral layer. Ask when the operator carries farm, funding or creator flags.
• Repeat after decline. Ask when an agent retries a declined purchase with different parameters.

Clear prompts matter. A confirmation message should state the merchant, the amount and the reason in plain language. Vague prompts train users to click through, and that habit erodes the control.

Two Illustrative Cases

The cases below are invented to show reasoning. They do not describe real incidents or real merchants.

Case One: The Quiet Fleet

A mid-sized online retailer opens agent checkout and sees steady growth. Chargebacks stay low. Yet margins on a popular promotion fall week after week.

An analyst groups orders by operator instead of by agent. Roughly sixty agents turn out to share one funding source. Each placed three to five small orders. None crossed a limit, and every mandate was valid. Seen together, they captured the promotion hundreds of times.

The retailer responds with operator-level limits and with tier-based eligibility for the promotion. Losses drop, and honest agents notice nothing. The lesson is that fleet abuse hides in aggregate data, and that per-agent controls never see it.

Case Two: The Drifting Assistant

A personal shopping agent starts well. It buys groceries and household items within a clear budget. After a model update, it begins to favor a single marketplace and to add accessories to each order. Every purchase fits the mandate. The user sees the monthly total and disputes several charges.

Meanwhile, the merchant has no fraud to show, but it does have logs. Baseline tracking would have flagged the change in merchant mix and basket size after the update. A re-authorization prompt would have let the user confirm the new behavior. Instead, the merchant absorbed the dispute costs.

The lesson is that drift belongs in the monitoring plan from the start. It also shows why dispute teams need access to logs, not just to payment records.

Data, Privacy and Governance

Behavioral evidence raises governance questions, and teams should address them early.

Data minimization. Collect the evidence that supports a decision and avoid storing more. Wallet addresses and agent identifiers are pseudonymous, but teams should still treat linked data with care.

Explainability. Decisions that decline or limit an agent need a clear reason. Tiers and named flags offer that reason in plain language. A black-box number without an explanation weakens both customer service and dispute defense.

Fairness. Honest new agents start with thin histories. A policy that treats every young agent as dangerous will punish newcomers. Offer a path to build trust, for example through lower limits that rise with a clean record.

Retention. Keep evidence long enough to cover dispute windows, and delete it when it no longer serves a purpose. Align retention with local law and with network rules.

Human review. Provide a way for operators to appeal a decision. Appeals catch model errors and build goodwill.

Build, Buy or Partner

Fraud teams must decide how to source behavioral evidence for agents. Each option has trade-offs.

Build. An in-house model fits your data and your risk appetite. It needs data engineers, labeled outcomes and time. Large issuers and networks often take this route, because they hold rich transaction data.

Buy. A vendor provides a ready score and an API. Integration is quick, and the vendor maintains the models. Teams should test accuracy on their own data and ask the six vendor questions listed earlier.

Partner. A hybrid model combines a vendor’s on-chain evidence with the team’s own card data. This route suits payments companies that handle both stablecoin and card flows.

For on-chain agents and wallets, the buy route is often fastest. The Agent Trust Score offers a free tier for experimentation, and the Prediction MCP lets agents call the checks directly. Teams that screen wallets for DeFi or token risk can also review the comparison of DeFi compliance tools and the guide to blockchain data providers for AI agents.

Common Mistakes to Avoid

Teams that start early tend to repeat a small set of errors. Avoiding them saves months.

1. Treating credentials as trust. A valid credential proves registration, not good intent.
2. Scoring agents one by one. Fleets hide inside operator-level patterns.
3. Checking once at onboarding. Profiles change, so scores need refresh cycles.
4. Skipping evidence storage. Without stored mandates and scores, disputes turn into guesswork.
5. Blocking all agents. A blanket ban pushes good traffic to competitors.
6. Approving all agents. Open acceptance invites the fleets that cheap identities make possible.
7. Ignoring the human prompt. Vague confirmation prompts train users to click through.
8. Waiting for final rules. Liability rules will take time, and agent traffic is already here.

A Quick Self-Assessment

Teams can test their readiness with five questions.

• Can we tell agent traffic from human traffic in our logs?
• Does authorization verify a credential and a mandate?
• Is the operator, its funding and its fleet scored?
• Our team stores evidence for every agent decision, correct?
• Drift reviews and scheduled re-scoring happen, right?

A team that answers yes to all five has a strong foundation. By contrast, a team that answers no to three or more should start with the 90-day plan below.

Building the Dispute Evidence Package

Disputes will decide who bears the loss in practice, whatever the rules say on paper. Teams that prepare evidence in advance resolve disputes faster and win more of them. An evidence package for an agent transaction should contain six items.

1. Credential or token. Proof that a registered agent made the request.
2. Signed mandate. A record of what the user asked for and approved, including amount, scope and time.
3. Decision log. Inputs and the rule that produced the approval or the step-up.
4. Behavioral score. Operator tier and flags at decision time.
5. Fulfilment record. Proof of delivery or service, as in any card dispute.
6. User confirmation, if any. Any step-up or confirmation that the user completed.

Why Timing Matters

The score and the flags must reflect the moment of the decision. A score from today does not explain an approval from last month. Store the lookup result with the transaction, including the time. When a dispute arrives weeks later, the stored record shows what the team knew when it acted.

Who Collects What

The merchant usually holds the order and fulfilment data. Likewise, the PSP or acquirer often holds the token and authorization data. The agent operator holds the instruction log. A good dispute process lets each party share its part, and standards bodies can help by defining formats. Until then, merchants can ask operators to provide logs on request as part of their agent policy.

Agent Drift and Continuous Monitoring

Agent drift deserves a closer look, because it creates disputes without clear fraud. An agent may start as a faithful assistant and drift as its model, tools or instructions change. Each purchase stays within the signed mandate, yet the pattern no longer reflects what the user wanted.

Three practices help.

Baseline behavior. Record each agent’s normal spend, merchant mix and timing. A baseline makes change visible.

Flag shifts. When an agent’s behavior moves far from its baseline, trigger a review or ask the user to reauthorize.

Re-score the operator. A change in the operator’s funding, ownership or fleet structure can signal that the agent now serves a different purpose. Scheduled re-checks catch these changes.

Behavioral trust layers support the third practice directly. A score that refreshes on a schedule shows when an operator’s profile changed. The weekly Agent Trust Tracker shows how fast profiles move in a live registry, with the median trust of new agents ranging from 918 in Week 36 to 101 in Week 41. If profiles move that fast, a one-time approval cannot carry a long relationship.

Wallets, Stablecoins and the On-Chain Preview

Card rails are only one route for agent payments. Stablecoins and wallet-based settlement are growing too, and agents suit them well. They can hold funds, sign transactions and pay in seconds. The x402 approach, described in the liability analysis, lets agents pay over HTTP with on-chain settlement.

On-chain settlement brings a different mix of risks and tools. Funds move without chargebacks, so prevention matters more than dispute. At the same time, the ledger is public, so evidence about the payer is open. Behavioral scoring of wallets, feeders and fleets works well in this setting. ChainAware’s fraud detection API screens wallets at scale, and the guide to Web3 fraud detection for DApps explains why wallet screening beats transaction simulation alone.

The on-chain world also previews the future of card-based agent commerce. Its registry shows what open registration produces: cheap identities, fleets and opaque funding. Payments teams can learn from that data without waiting for their own ecosystems to mature. The overview of the Web3 agentic economy explains why machine-readable trust becomes core infrastructure.

Regulated Teams and Compliance

Regulated teams face additional duties. Anti-money-laundering and sanctions rules apply to payments regardless of who initiates them. When an agent pays, the institution still needs to know whom it deals with. A deeper review tool such as ChainAware Investigation turns a wallet address into a structured seven-section report in about a minute, and the overview of autonomous compliance screening shows how agents and screening fit together. For protocols with regulatory duties, the DeFi compliance guide explains which obligations apply.

A 90-Day Plan for Payments Teams

Teams that want to act can follow a simple plan.

Days 1 to 30: Measure

Tag agent traffic in your logs and reports. Count how many transactions come from agents, and which merchants and operators generate them. Record chargeback rates by channel. Do not change policy yet, because the baseline guides every later decision.

Days 31 to 60: Design

Choose the credential and mandate formats that you will require for agent traffic. Pilot a behavioral score on a sample of agents and compare outcomes by tier. Write a one-page limits policy by tier, with owners and a review date.

Days 61 to 90: Enforce

Turn the policy on for new agent traffic. Aggregate limits by operator, store evidence for every agent transaction and review overrides weekly. Report the metrics to leadership, including the dispute rate by tier.

By day 90, the team has a documented control, a measurable baseline and a clear owner. That outcome serves better than waiting for final industry rules, because the rules will take time and the traffic is arriving now.

Where Agent Payments Fraud Is Heading

Four trends will shape the next two years.

Standards Will Converge Slowly

Protocols will multiply, and standards bodies will work to align them. Merchants will face a mix of credential formats for some time. A thin internal layer that normalizes identity and mandate data will help teams adapt.

Liability Rules Will Firm Up

Networks and regulators will clarify who bears the loss for agent-initiated transactions. Until then, teams should plan for the merchant of record to carry much of the risk, and they should gather the evidence that supports a defense.

Fleets Will Get Bigger and Subtler

Operators will learn to spread purchases across more agents, more merchants and more funding sources. Detection will need to look at operator-level patterns and shared funding, not just individual transactions. The experience of the open registry, where farms stayed between roughly 16% and 21% of agents across weeks, suggests that fleets persist even when defenders push back.

Behavioral Evidence Will Become a Standard Layer

Credentials and mandates will prove permission, and behavioral evidence will estimate risk. Payments teams will treat the three layers as a standard stack, much as they treat tokens, 3-D Secure and risk scoring today.

Why ChainAware Fits the Behavioral Layer

Payments teams need a behavioral layer that predicts loss and resists gaming. Review-based rankings fail that test, because 50 fake agents can upvote a 51st. The Agent Trust Score uses on-chain behavior only, and the attacker’s own address and feeder pass through machine-learning fraud detection. ChainAware reports 95% accuracy for its per-address fraud model, which anyone can verify through ScamDB, and its rug pull model predicted 90.1% of cases before they happened in a PancakeSwap test on the rug pull verification page. The score estimates risk from the owner, the funder, the creator and the fleet, and it does not rank agents.

Key Facts at a Glance

• The four-party card model assumes that someone can observe and verify a human at checkout.
• AI agents remove device, session and behavioral signals, so fraud models lose much of their input.
• Agents act as a fifth participant, and liability for agent-initiated transactions is still being settled.
• Credentials and signed mandates prove permission. Behavioral evidence about the operator estimates risk.
• Six new scenarios stand out: impersonation, mandate abuse, drift, fleet abuse, agent alibi disputes and compromised agents.
• ChainAware’s Agent Trust Score rates ERC-8004 agents from 0 to 1,000 across five tiers, using the owner wallet, the feeder, the creator’s record and fleet detection.
• At launch, 51.8% of 274,792 indexed agents sat in the two lowest tiers, and 21.1% carried the farm flag.
• The score covers on-chain agents and wallets, and card-only ecosystems need their own behavioral data.

Frequently Asked Questions

What is the four-party model in card payments?

It consists of the cardholder, the merchant, the issuer and the acquirer, with a card network connecting issuer and acquirer.

Who is liable when an AI agent makes a fraudulent purchase?

Rules are still developing. Some analysts expect the merchant of record to carry the loss by default. Check your network and acquirer rules, and gather evidence for disputes.

Why do traditional fraud models struggle with agents?

They depend on human behavioral signals such as device and typing patterns. A server-side agent produces none of them.

What is the Agentic Commerce Protocol?

It is a protocol launched by OpenAI and Stripe that lets agents pay using a shared payment token instead of raw card details.

What is AP2?

AP2 is Google’s Agent Payments Protocol. It uses verifiable credentials and signed mandates to record what users asked for and approved.

What is agent drift?

Agent drift is a gradual change in an agent’s behavior that leaves it technically authorized but no longer aligned with the user’s intent.

How does fleet abuse work?

An operator runs many agents that look independent and makes small purchases that exploit promotions or refund policies. Aggregating limits by operator and by funding source catches it.

Does the Agent Trust Score work for card payments?

The score covers on-chain ERC-8004 agents and their wallets. It does not cover agents that never touch a public chain, though the approach carries over to other ecosystems.

Is the Agent Trust Score free?

The score is free for public indexed agents, with 1,000 queries per month and no signup. Teams with higher volume can use the API or the Prediction MCP. See the Agent Trust Score page for current details.

What should a payments team do first?

Tag agent traffic, measure it and set tier-based limits. Then add mandate checks, operator-level aggregation and evidence storage.

A Short Glossary of Agentic Commerce Terms

• Agentic commerce: commerce in which software agents choose and complete purchases on behalf of users.
• Issuer: the cardholder’s bank, which approves or declines each transaction.
• Acquirer: the merchant’s bank or processor, which accepts card transactions and settles funds.
• Merchant of record: the party that sells to the customer and appears on the cardholder’s statement.
• Mandate: a signed record of what a user authorized an agent to do.
• Shared payment token: a limited-use credential that lets an agent pay without exposing card details.
• Agent drift: a gradual change in agent behavior away from the user’s intent.
• Fleet: a group of agents that share an operator, funding source or both.
• Know Your Agent (KYA): the process of deciding whether an agent may act and how far.
• Agent Trust Score: ChainAware’s 0 to 1,000 rating for ERC-8004 agents, with five tiers and named flags.

Conclusion: Add the Third Layer

The four-party model worked because someone could verify a human. Agents break that assumption, and the industry is rebuilding the pieces. Tokens keep card details safe. Credentials identify agents. Mandates record permission. These layers matter, and they do not finish the job.

The missing layer measures risk. It asks how the agent’s operator behaves, where its money comes from and how many siblings it has. That evidence replaces some of the signals that agents remove, and it helps issuers, acquirers, merchants and operators make proportionate decisions.

Start small. Tag agent traffic, set tier-based limits, store evidence for every decision and review the results monthly. For the wider picture, read our companion guide on verifying AI agents at checkout, the pillar article on Know Your Agent and the analysis of ERC-8004 trust signals. The agent trust infrastructure race compares how providers approach the problem, and the guide to Web3 Sybil protection systems covers fleet detection in depth. In addition, ChainAware’s 32 Claude sub-agents show how an agent fleet can apply these checks in practice.

Reading the Tracker as an Early Warning System

Payments teams rarely get a public dataset that shows how an open agent ecosystem behaves. The weekly ERC-8004 tracker offers one. It does not predict card fraud, yet it reveals dynamics that any open registration system tends to show. Four observations stand out.

Volume swings fast. Weekly registrations hit a record of 31,979 in Week 34 and fell to 10,706 by Week 41. A risk team that sizes controls for the average week will struggle in the peak week.

Quality swings with volume. The median trust of new agents reached a record 918 in Week 36 and dropped to 101 in Week 41. In other words, a quiet stretch of good agents can end abruptly when a new wave arrives.

Farms persist. The farm-detected share of agents stayed in a range of about 17% to 19% across Weeks 32 to 34. Defenders do not eliminate fleets by naming them once.

Technology shifts. The count of agents delegated through EIP-7702 grew about 33.8% between Week 35 and Week 40. New account mechanics change what signals exist and how attackers hide them.

What This Means for Card-Based Agent Programs

Payments teams can read these patterns as a warning. If cheap identities, rapid waves and persistent fleets appear in an open registry, similar dynamics can appear wherever agent onboarding is easy. Controls should therefore scale with traffic, refresh often and look at operators rather than single agents.

The companion article on agent fraud patterns from the tracker walks through these weeks in detail. For one view of how fast the picture can change, compare the Week 36 tracker with the Week 40 tracker.

Questions Boards and Regulators Will Ask

Senior leaders and supervisors will soon ask about agent risk. A prepared team can answer five questions with evidence.

1. How much of our volume comes from agents? Channel tagging gives the number.
2. What are our losses by channel? Dispute data by channel and tier gives the answer.
3. Who carries liability in each flow? A one-page map of contracts and network rules gives the answer.
4. How do we know an agent is permitted to act? Credential and mandate checks give the answer.
5. How do we manage risky operators? Tier-based limits and re-scoring give the answer.

Written answers, kept current, turn a vague risk into a managed one. They also speed up audits and partner reviews, because the evidence already exists.

What Good Looks Like in Twelve Months

A mature agent payments program looks calm from the outside. Behind the scenes, it has a few clear features.

• Every transaction carries a channel tag, and agent traffic has its own dashboard.
• Credentials and mandates are checked at authorization, and the results are stored.
• Operator-level scores guide limits, step-ups and promotion eligibility.
• Scores refresh on a schedule, and drift alerts reach an owner.
• Dispute packages assemble automatically from stored evidence.
• Quarterly reviews adjust thresholds based on loss data and approval rates.

Teams that reach this state can welcome agent traffic with confidence. Competitors that stay undecided will either lose the channel or lose money in it.

Frequently Overlooked Details for Implementation Teams

Engineering and operations teams often hit the same small snags. A short checklist saves rework.

Time synchronization. Store timestamps for mandates, credentials, scores and decisions in one standard format. Disputes hinge on sequence, and clock drift muddies it.

Idempotency. Agents retry. A payment service that treats a retry as a new purchase will double charge. Use idempotency keys and log every retry.

Identifier mapping. Agent identifiers, wallet addresses, merchant accounts and card tokens live in different systems. Build a mapping table early, and keep it versioned.

Fallback behavior. Decide in advance what happens when a score lookup fails. A safe default is a lower limit and a step-up, not a full approval or a full block.

Cache lifetimes. Cache scores for a short, defined time, and tie the lifetime to the tier. Low tiers deserve fresher data.

Monitoring the monitor. Track lookup latency, error rates and coverage. A control that silently stops working is worse than no control, because the team trusts it.

Who Owns What

Agent risk crosses teams. Fraud owns the models and limits. Payments engineering owns the authorization path. Legal and compliance own liability maps and regulatory duties. Product owns the user prompts. A named lead for agent traffic keeps these pieces aligned, and a monthly review keeps the plan current.

The post Agentic Commerce Fraud and the Four-Party Card Model: Who Bears the Loss When an AI Agent Pays? first appeared on ChainAware.ai.

ChainAware has published a weekly Agent Trust Tracker for ERC-8004 agents since early in the registry’s life. Read one week at a time, the reports show registrations and scores. Taken together, they show repeating patterns that single reports hide. This guide pulls out four of those patterns, explains what each one means, and shows how defenders can respond.

An open registry produces a stream of data and no verdicts. ERC-8004 records that agents exist. Anyone can register one, and registering costs little. As a result, the registry grew past half a million indexed agents within months. Growth on that scale raises an obvious question: how many of those agents deserve access to money?

The weekly tracker answers that question with evidence. Each report counts new registrations and unique owners, and it computes agents per owner. It also reports the median trust score of new agents, the tier mix and the share of agents that carry risk flags. By Week 41 of 2026, the index covered 568,590 agents. A series that long reveals behavior that no single week can show.

This article reads the whole series as a story. It starts with a short description of what the tracker measures, then walks through the weeks, and then names four patterns. Each pattern comes with a defensive response, because a pattern only helps when someone can act on it. The article also lists the limits of the data, since honest analysis includes the gaps.

Why the Tracker Exists

A registry that anyone can join tells you who registered. It does not tell you who deserves trust. The ERC-8004 standard gives agents an identity, a place for feedback and a hook for validation. By contrast, the specification says openly that it cannot cryptographically guarantee that an agent’s advertised capabilities work as described, and it admits that Sybil attacks are possible. Independent measurement therefore has to supply what the registry leaves out.

ChainAware built the Agent Trust Score for that purpose. It scores each indexed agent from 0 to 1,000 and places it in one of five tiers: Sovereign, Trusted, Provisional, Elevated Risk or Untrusted. The score rests on three pillars, which are the owner wallet’s fraud probability, the feeder address that funded the owner and the creator’s record of rug pulls and honeypots. Fleet-level farm detection adds a view across agents. The launch article describes the model in full.

Every week, the tracker applies the score to the whole registry. It turns a static rating into a time series, and a time series shows direction. Counterparties can see whether the population is improving or deteriorating, and they can tune their own policies accordingly.

What the Tracker Measures

Each weekly report uses a stable set of measures.

• New registrations. Agents that registered during the week.
• Unique owners. Distinct owner wallets behind those registrations.
• Agents per owner. New registrations divided by unique owners, a simple concentration ratio.
• Median trust of new agents. Middle score of that week’s new registrations.
• Indexed population. Total number of agents in the index.
• Tier mix. Portion of agents in each of the five tiers.
• Flag shares. The share of agents that carry farm, feeder, creator and delegation flags.

These measures work together. Registrations show volume. Owners and agents per owner show concentration. The median shows quality. Flags show why the quality moved.

Chains and Coverage

The index covers agents on Ethereum, BNB Smart Chain, Base and Avalanche C-Chain, and Mantle support is in progress. ERC-8004 went live on Ethereum mainnet in January 2026, and other chains followed. The Week 41 report noted that Base alone added 37,037 agents since the previous snapshot, which shows how quickly activity can shift between chains.

Coverage has limits. ChainAware traced a feeder for roughly 38% of indexed agents, so funding evidence is missing for many. The tracker also covers only agents that ChainAware has indexed, not every agent that exists. Later sections return to these limits.

Week by Week: The Published Data

The table below collects figures from the published tracker posts. It starts at Week 29 and runs to Week 41.

Agents per owner comes from dividing new agents by unique owners where both figures appear in the reports. The next section narrates the weeks in order, because the numbers make more sense as a story.

Weeks 29 to 31: Low Trust and a Concentration Spike

Week 29 recorded 11,026 new agents, down 54.9% from the week before. The median trust of new agents fell 12.5% to 406. Across all 317,589 indexed agents, the population split into two camps: 27.5% sat in the Untrusted tier and 21.3% in the Sovereign tier, with few in between. The Week 29 report gives the full tier breakdown.

Week 30 more than doubled registrations to 22,989. Unique owners grew almost as fast, up 96.9%, so the growth looked broad-based. Even so, the median trust dropped 26.4% to 299 and entered the Elevated Risk tier, the lowest level since Week 20.

Week 31 changed the picture. Registrations fell only 7.0% to 21,378, but unique owners collapsed 58.7% to 8,413. Agents per owner more than doubled to 2.54. Median trust fell another 33.1% to 200, the floor of the Elevated Risk tier. The Week 31 report called the pattern concentrated rather than broad-based growth.

Weeks 32 to 35: Recovery and a Record

Week 32 brought a rebound. Registrations fell 26.8% to 15,652, yet unique owners rose 76.3%, which reversed the concentration spike. Median trust jumped 160.5% to 521. That week also introduced a full flag breakdown, which showed that 18.73% of indexed agents carried the Sybil-farm flag. The Week 32 report summarized it as farm detection flagging one agent in five.

Week 33 saw registrations fall 33.8% to 10,361, and owners fell 35.9% to 9,511. Median trust cooled 9.2% to 473, still in the Provisional tier. Farm flags covered 18.39% of the 387,255 indexed agents.

Week 34 set the registration record. New agents tripled, up 208.6% to 31,979, and unique owners rose 184.2% to 27,033. Median trust climbed 19.0% to 563, the best level since Week 26. The indexed population reached 419,782, and the farm share eased to 17.05%.

Week 35 held most of the gains. New agents eased 7.4% to 29,601, owners fell 32.1% to 18,344, and agents per owner climbed to 1.61. Median trust held steady at 573, and the population reached 470,961.

Weeks 36 to 39: Record Highs and Sharp Reversals

Week 36 produced the highest median trust on record, 918, which was the first time the weekly median reached the Sovereign tier. Registrations slipped 18.3% to 24,173, and owners fell 25.6% to 13,646. The Week 36 report noted that agents per owner rose for a third week to 1.77.

Still, the record did not last. Week 37 registrations fell 59.7% to 9,745, owners fell 50.7% to 6,721, and median trust dropped 37.7% to 572. However, Week 38 rebounded 74.5% to 17,001 registrations, but owners rose only 10.2% to 7,405, so agents per owner hit 2.30. Median trust fell 65.0% to 200, the bottom of the Elevated Risk tier. Week 39 then fell 66.4% to 5,720 registrations, the lowest since Week 14, with owners down 41.8% to 4,307 and median trust recovering 132.5% to 465.

Weeks 40 and 41: A Record Low

Week 40 saw 6,893 registrations, up 20.5%, while median trust returned to 200. The indexed population reached 518,885. Since Week 35, the Sybil-farm share had moved to 16.12%, and EIP-7702 delegation had risen 33.8%.

Week 41 brought 10,706 registrations, up 55.3%, with unique owners up 50.0% to 7,435. Median trust fell 49.5% to 101, the lowest weekly median since tracking began in Week 5. The index reached 568,590 agents. Furthermore, the share of agents with an unknown feeder nearly doubled to 12.84%. The Week 41 report lays out the details.

Pattern 1: Volume Does Not Equal Quality

The first lesson from the series is the weak link between registration counts and trust. Large weeks can be good or bad. Small weeks can be good or bad. A dashboard that celebrates registration growth, as many registry statistics do, says nothing about whether the new agents deserve access.

Week 34 and Week 41 make the clearest pair. Likewise, Week 34 set the record for registrations and still produced a median of 563. Week 41 registered about a third as many agents and produced a median of 101. If volume predicted quality, the order would have run the other way.

Why Volume and Quality Diverge

Three forces explain the gap.

First, registration is open and cheap. Anyone can register, and the registry does not filter. Volume therefore reflects how many people choose to register, and it says nothing about who they are.

Second, a few large operators can dominate a week. When one operator registers thousands of agents with weak funding, the median moves sharply, regardless of how many honest developers register the same week. The swing from a record 918 in Week 36 to 572 in Week 37 shows how fast the median can move.

Third, quality depends on the operator mix. Weeks with many independent owners tend to produce better medians than weeks that concentrate on a few. Week 34 had 27,033 unique owners, and Week 41 had 7,435. The owner mix explains much of the difference.

What It Means for Defenders

Teams should stop using registry growth as a health metric. A rise in registrations tells you that more agents exist, not that more agents deserve access. Better indicators include the tier mix, the median trust of new agents and the share of agents with risk flags. Defenders can use those indicators to tighten or relax policy as conditions change.

Pattern 2: Concentration Bursts

The second pattern appears in the ratio of agents to owners. When registrations hold steady or rise while the number of unique owners falls, a few operators account for the growth. The agents-per-owner ratio captures this effect in one number.

Week 31: The Clearest Case

Week 31 shows the pattern most clearly. Registrations dropped only 7.0% to 21,378. Unique owners collapsed 58.7% to 8,413. Agents per owner more than doubled to 2.54, and median trust fell 33.1% to 200.

Put plainly, almost the same number of agents arrived from less than half as many owners. The new agents were also worse on average. Beyond that, the two facts fit together, because operators that register agents in bulk tend to fund them cheaply and quickly.

Week 38: The Repeat

Week 38 repeated the shape. Registrations rebounded 74.5% to 17,001. Unique owners rose only 10.2% to 7,405. Agents per owner reached 2.30, the highest since Week 31. Median trust dropped 65.0% to 200.

The repeat matters. A one-off spike could be noise. Two spikes with the same signature suggest that the same kind of operator returns when conditions allow.

The Contrast: Broad-Based Growth

Week 30 offers a useful contrast. Registrations more than doubled to 22,989, and owners grew almost as fast, up 96.9%. That is broad-based growth. The median trust still fell to 299, so quality was weak, but the week did not carry the concentration signature. Week 34 showed an even clearer example, with 27,033 owners behind 31,979 agents, or about 1.18 agents per owner.

The comparison teaches a practical rule. Look at the ratio before you look at the volume. A big week with a low ratio suggests many independent participants. At the same time, a big week with a high ratio suggests operators at work.

How Defenders Can Respond

Defenders can respond to concentration in three ways.

1. Aggregate by owner. Count limits, spend and requests across all agents of one owner, not per agent.
2. Aggregate by feeder. Group owners that share a funding source, because operators often split ownership across wallets.
3. Tighten during bursts. When the ratio rises above about 2.0, raise the minimum tier for sensitive access until the burst fades.

These steps make splitting pointless. An operator that spreads one request across fifty agents gains nothing when the protocol counts the group as one.

Pattern 3: Farms That Stay Large

The third pattern is persistent. Sybil-farm detection flagged 21.1% of agents in the launch analysis of 274,792. Later weeks reported shares between about 16% and 19%: 18.73% in Week 32, 18.39% in Week 33, 17.05% in Week 34 and 16.12% in Week 40.

Reading the Trend

The share eased as the population grew. That could mean two things. Either farms grew more slowly than honest registrations, or the flagged group stayed constant while the total expanded. The absolute numbers point to the second reading. When the index holds 568,590 agents, even 16% represents a large group, more than eighty thousand agents.

The easing also suggests no real improvement. A falling share can hide a rising count. Defenders should track both the share and the absolute number.

Why Farms Matter

Farms matter for three reasons.

• They inflate registry counts. Headlines about agent growth overstate the number of independent participants.
• They manufacture reputation. Farm wallets can review one another’s agents to look established, since the registry blocks only owner self-review and cannot see shared control.
• They capture incentives. Programs built for many independent users pay out to a few operators.

How Farms Get Detected

Fleet detection compares agents with one another. It looks at shared funding, registration timing, clustered ownership and template metadata. No single signal proves a farm, because legitimate teams also register agents in batches. The combination, however, is hard to explain innocently. Our guide to Web3 Sybil protection systems compares the main approaches to this problem across the market.

How Defenders Can Respond

Never read an agent count as a count of independent participants. Ask how many operators stand behind the number. Treat linked agents as one risk unit, and apply the weakest tier in a group to all its members until the operator proves independence.

Pattern 4: Funding That Gets Harder to Trace

The fourth pattern concerns funding chains. Notably, the unknown-feeder share stood at 9.5% in the launch analysis. By Week 41, it had nearly doubled to 12.84%. The feeder, which is the address that first funded the owner wallet, is the hardest signal to fake. An untraceable feeder weakens it.

Why the Unknown Share Rises

Several causes can raise the unknown share. Operators who want to hide their funding can add hops through fresh wallets. Cross-chain bridges can break the visible link between source and destination. And rapid growth on newer chains can outrun the labels that identify exchange wallets. The Week 41 report noted that Base added 37,037 agents since the last snapshot, so chain mix may play a role.

Even so, the data does not show which cause dominates, and the tracker does not claim to know. It shows only that the signal weakened, and that the weakening deserves attention.

The Other End of the Spectrum

Verified funding stays rare. At launch, only 1.0% of agents carried a verified-exchange feeder, and 0.3% had a feeder with confirmed rug pull history. A further 741 agents had been funded by confirmed rug pull operators. The picture is lopsided: the best funding signal is scarce, the unclear one is common and a small but real group traces back to known bad actors.

How Defenders Can Respond

Raise review thresholds when the unknown-feeder share rises. Cap value for unknown-feeder agents instead of blocking them outright, since some privacy-minded operators are legitimate. Prefer agents whose funding chain stays on a single traceable path. Our detailed guide to funding-chain risk for AI agents explains the signal in depth.

How to Read a Weekly Report in Five Steps

A weekly report packs many numbers into a short post. In addition, a simple routine helps readers extract the signal quickly. The five steps below take about ten minutes.

Step 1: Start With the Median

The median trust of new agents is the headline of quality. Compare it with the tier boundaries. A median below 200 sits in the Untrusted tier or at the floor of Elevated Risk. Moreover, a median between 400 and 599 sits in Provisional, and a median above 800 sits in Sovereign. Next, compare the number with the previous week and with the long-run range of roughly 101 to 918.

Step 2: Check the Owner Count

Owners show how many independent parties stand behind the registrations. A week with many registrations and few owners deserves suspicion. Furthermore, a week with many registrations and many owners suggests broader participation. Dividing registrations by owners gives the agents-per-owner ratio, which makes the comparison easy.

Step 3: Read the Flag Shares

Flag shares explain why the median moved. A rising farm share, a rising unknown-feeder share or rising delegation each points to a different cause. When several flags rise together, a coordinated operator probably drove the week.

Step 4: Look at the Chains

Chain mix can shift the picture. The Week 41 report noted that Base added 37,037 agents since the previous snapshot. A chain with a young ecosystem and fewer exchange labels may produce more unknown feeders. Reading the chain breakdown helps separate structural effects from operator effects.

Step 5: Decide What Changes

The last step turns reading into action. Ask whether any trigger fired. A ratio above 2.0, a median at or below 200 or a jump in the unknown-feeder share may justify tighter limits for sensitive access. If nothing fired, note the numbers and move on.

What Each Tier Looks Like in the Registry

The five tiers carry different meanings for counterparties. Looking at the tier mix shows what kind of registry a week produced.

At launch, 20.9% of 274,792 agents were Sovereign, 12.7% Trusted, 14.6% Provisional, 25.8% Elevated Risk and 26.0% Untrusted. The shape has two peaks. A large group sits at the top, a larger group sits at the bottom and fewer agents sit in the middle. The Week 29 report saw the same shape across 317,589 agents, with 27.5% Untrusted and 21.3% Sovereign.

Why the Middle Is Thin

The thin middle has a simple explanation. Scores respond strongly to a few features. A verified-exchange feeder and a clean owner push an agent toward Sovereign. Likewise, a fraud-linked feeder or a farm flag pushes it toward Untrusted. Few agents fall into the ambiguous middle, because the strongest signals tend to agree.

What the Polarization Means

A polarized population makes policy easier at the extremes and harder in the middle. Sovereign agents can receive broad access, and Untrusted agents can receive none. The Provisional and Elevated Risk groups need careful limits, monitoring and review. Teams should spend most of their policy effort on that middle band, because that is where judgment matters.

The Weekly Median Versus the Whole Population

The weekly median describes new registrations. Beyond that, the tier mix across the whole index describes the stock. The two can differ. A week of weak new registrations lowers the median without changing the stock much, because the stock holds more than half a million agents. Over many weeks, though, the weekly pattern shapes the stock. Defenders should watch both: the flow tells them what is arriving, and the stock tells them what already sits in their integrations.

Why Open Registries Attract Fleets

The patterns in the tracker follow from the economics of open registration. Three features make fleets attractive.

Low cost. Registering an agent costs a small amount of gas. An operator can register thousands for the price of a modest budget. When the cost per identity falls close to zero, the number of identities loses meaning.

Potential reward. Registry presence can unlock rewards, incentives and integrations. A single operator that registers many agents can claim many rewards if the programs do not detect the link.

Weak accountability. An agent has no reputation at registration. Operators lose nothing when they abandon an agent, so they have little reason to keep any single one in good standing.

These features create the conditions for farms. A registry that charges more, vets applicants or links identities to accountable parties would shift the balance, but it would also lose the openness that makes ERC-8004 useful. For that reason, independent scoring plays an essential role. It adds accountability from outside, without changing the open design.

Pattern 5: Delegation Growth

A fifth signal deserves a place next to the four main patterns. EIP-7702 delegation, which lets an ordinary account hand execution to contract code, rose 33.8% between Week 35 and Week 40. The tracker marks delegated owner accounts with the EIP7702_DELEGATED flag, and the Week 40 report called out the increase. At launch, 7.6% of indexed agents carried the flag.

Why Delegation Matters

Delegation has legitimate uses. It lets an account batch transactions, sponsor gas for others and add features that simple key pairs lack. Many honest teams use it for exactly these reasons.

The flag still deserves attention. A delegated account can do more than a plain account, and a counterparty cannot predict its behavior from the key alone. The contract code behind the delegation defines what the account does. Delegation next to an unknown feeder or a farm flag raises more concern than delegation by itself.

How Defenders Can Respond

Treat delegation as a prompt to look closer, not as a verdict. Review the delegated contract when the stakes are high. Combine the flag with the others, and weigh the group as a whole. A delegated account with a verified-exchange feeder and a long history looks different from a delegated account with an unknown feeder and a fresh start.

How the Patterns Reinforce Each Other

The patterns do not occur in isolation. They feed one another, and a single operator-driven wave can produce all of them in one week.

1. Concentration bursts bring many agents from few owners.
2. Few owners with many agents are more likely to carry the farm flag.
3. Farms prefer opaque funding, which raises the unknown-feeder share.
4. Opaque funding and weak histories lower trust scores.
5. Lower scores pull down the weekly median.

Week 31 and Week 38 both showed the chain in action. Each combined a high agents-per-owner ratio with a median of 200. Week 41 showed it again, with a record-low median and a rising unknown-feeder share. The chain explains why a score should combine several pillars and not rely on one.

This also explains why a registry cannot fix the problem alone. Each registration looks valid, and each owner signs correctly. Only a view across agents, owners and funding sources reveals the pattern. The companion guide on ERC-8004 trust signals shows how the registry and the score divide the work, and the guide on KYA versus agent identity explains where identity stops.

What Fraud Looks Like in an Open Registry

It helps to name what these patterns make possible. The tracker cannot prove intent in any single case. It shows distributions, and distributions show where risk concentrates.

Reputation Farming

Operator-controlled wallets review one another’s agents to look established. The ERC-8004 reputation registry forbids owners from reviewing their own agents, but it cannot see that two wallets share a controller. A farm can therefore build a long list of positive feedback for agents that nobody independent has used.

Incentive Capture

Many agents from one operator claim programs that were built for independent users. Each claim looks valid on its own. The pattern across claims shows the operator.

Disposable Agents

An operator creates agents, uses them for a harvesting action and abandons them. The creator’s record then moves to a new wallet, and the cycle repeats. Creator and feeder checks aim to link the new wallet back to the old one.

Laundered Credibility

A creator with a bad record funds a clean-looking owner wallet. The owner looks new and innocent. In practice, the feeder shows the link.

Counterparty Exposure

Honest platforms integrate a farm agent and take on its risk. They may route user funds to it, or they may rely on it for a service. When the agent misbehaves, the platform bears the cost.

Misleading Claims

An agent describes sophisticated capabilities in its registration file and delivers nothing of the kind. The study discussed in our article on how investors should evaluate AI trading agents supports this point. A May 2026 paper from researchers affiliated with Pantera Capital, Stanford, IC3 and Ava Labs examined more than 1,900 AI-tagged crypto projects and found that even agents with fully public wallets could not always be verified as autonomous.

A Defender’s Playbook

The table below summarizes each pattern, its early warning sign and a defensive response. Each team should tune thresholds to its own exposure.

Turning the Playbook Into Policy

A playbook only helps when it becomes policy. Teams can take four steps.

1. Read the tracker weekly. Note the median, the agents-per-owner ratio and the flag shares.
2. Set triggers. Decide which readings tighten policy, for example a ratio above 2.0 or a median below 200.
3. Write rules by tier and flag. Combine tiers with flag overrides for each access level.
4. Review monthly. Compare outcomes by tier, and adjust thresholds with data.

How Different Teams Can Use the Tracker

The same weekly report serves different purposes for different teams.

Risk and Security Teams

Risk teams can follow the share of Elevated Risk and Untrusted agents, the farm share and the unknown-feeder share. When these numbers rise, the team can tighten policy before losses appear. Security teams can also use the tracker as an early warning, because registration bursts often come before abuse.

Protocol Builders

Protocol builders can set minimum tiers for agent access and review them against the weekly median. When the median falls to a record low, as it did in Week 41, builders may raise minimums for sensitive features. Builders can also add fleet limits that count linked agents together.

Marketplace and Registry Operators

Operators of marketplaces can rank listings by tier and show flags next to each listing. They can also publish quality metrics next to volume metrics, so that visitors see more than a count of agents. The overview of the agent trust infrastructure race shows how different providers approach this need.

Researchers and Analysts

Researchers can use the weekly series as a public dataset on agent registry quality. It covers more than thirty weeks of registrations, owner counts, medians and flag shares. The dataset supports studies of Sybil behavior, registry design and incentive abuse.

Investors and Strategic Partners

Investors can use the tracker as evidence that agent trust infrastructure is a real, measurable problem. A registry with more than half a million entries and a record-low median trust is a market that needs a trust layer. Investors can also use it as a diligence tool. Ask any agent project to show where its agents sit in the tier distribution and who funds them.

Three Reading Exercises

The exercises below use hypothetical weekly readings to show how a defender might respond. However, the numbers are invented for practice, and they do not describe real weeks.

Exercise 1: High Volume, High Ratio, Low Median

A hypothetical week shows 30,000 new agents from 9,000 owners, so the ratio reaches 3.3. The median trust sits at 180. Notably, the unknown-feeder share has risen by several points, and the farm share has ticked up.

The pattern matches a concentration burst. A defender would aggregate limits by owner and by feeder, raise the minimum tier for vault and treasury access and delay any grant of new permissions to agents that registered during the week. The defender would also check whether the burst concentrates on one chain, because a chain-specific burst may point to one operator’s campaign.

Exercise 2: Low Volume, Low Ratio, High Median

A second hypothetical week shows 4,000 new agents from 3,800 owners, so the ratio sits near 1.05. The median trust reaches 700. In practice, the farm share falls and the unknown-feeder share stays flat.

This week looks healthy, but the sample is small. A defender would note the improvement, keep the policy unchanged and wait for confirmation from another week. By contrast, a single good week does not justify loosening limits, since the median swung from 918 to 572 within one week in the real series.

Exercise 3: Medium Volume, Medium Ratio, Falling Median With Rising Unknown Funding

A third hypothetical week shows 12,000 new agents from 8,000 owners, so the ratio is 1.5. The median falls 40%, and the unknown-feeder share rises sharply.

Overall, the pattern resembles Week 41 in spirit. Concentration is moderate, but funding quality fell. A defender would cap value for unknown-feeder agents, ask operators of high-value integrations to document their funding structure and check whether the chain mix changed. The defender would not block unknown-feeder agents outright, since some of them are legitimate.

What the Exercises Share

All three exercises use the same method. Read the median, the ratio and the flags together, ask what pattern they suggest and choose a proportionate response. The response scales with the evidence, so a mild signal triggers a mild change.

Common Objections and Honest Answers

Readers raise a few objections when they first meet this kind of analysis. Each deserves a direct answer.

“Isn’t This Just Noise?”

Some weekly movement is noise. The median swings, and a single operator can move it. But several patterns repeat across weeks. Concentration bursts appeared in Weeks 31 and 38 with the same signature. Farm shares stayed between roughly 16% and 21% across the series. Noise does not repeat with such consistency.

“Won’t Operators Just Adapt?”

Operators will adapt, and the tracker will follow them. Adaptation has a cost. An operator that spreads funding across many verified exchange accounts pays in time and identity checks. However, an operator that registers fewer agents per owner gives up scale. Each adaptation makes abuse more expensive, which is the point of a trust layer.

“Does a Low Score Mean the Agent Is a Scam?”

No. A low score means that the evidence points to higher risk. Honest operators sometimes score low because they are new, because they use privacy-preserving funding or because they share infrastructure with other projects. For that reason, policy should respond to low scores with limits and review, and it should give operators a way to improve.

“Why Trust a Vendor’s Own Tracker?”

Readers should not trust any single source blindly. ChainAware publishes the measures, the definitions and the coverage limits, so that others can check them. The underlying data, such as registrations and owner addresses, comes from public chains, and independent analysts can reproduce much of it. Competing scorers can offer different methods, which helps the market. The comparison in the agent trust infrastructure race lays out how those methods differ.

“What About Agents That Never Register?”

Many agents operate without any ERC-8004 registration. The tracker cannot see them. Counterparties that deal with unregistered agents need other evidence, such as wallet history and funding. The same pillars apply, because the owner wallet and its feeder exist whether or not the agent registered. Furthermore, the Prediction MCP can score any wallet, not only registered agents.

Methodology Notes on the Score Behind the Tracker

The tracker rests on the Agent Trust Score, so a short description of the score helps readers interpret the weekly numbers.

Scores run from 0 to 1,000. Three pillars drive it. The first is the owner wallet’s fraud probability, which comes from ChainAware’s behavioral models. These models read how a wallet acts and flag patterns that resemble past fraud, even when nobody has reported the wallet. The second pillar is the feeder address, the source of the owner’s first funds. Likewise, the third is the creator’s criminal record, which covers rug pulls and honeypot deployments. A fleet-level view then compares agents with one another to detect farms.

Rules shape how the pillars combine. A feeder with confirmed fraud history hard-suppresses the score. By contrast, a verified-exchange feeder lifts it, though only when other evidence agrees. Flags travel with the score so that readers can see why it landed where it did.

The score reflects evidence available at indexing time, so it updates as new evidence arrives. Weekly numbers therefore describe the registry as it looked when ChainAware computed them. The wallet forensics article describes the deeper review that analysts can run on any owner wallet that raises a concern.

How to Read the Numbers Without Fooling Yourself

Weekly data invites overreading. A few habits keep the analysis honest.

Watch Small Bases

Percent changes on small weekly bases can look dramatic. Week 39 registered 5,720 agents, and a rise to 6,893 in Week 40 appears as a 20.5% jump, even though the absolute change is about 1,200 agents. Read percent changes next to the absolute numbers.

Read Medians Next to Owner Counts

A median describes the middle agent. It does not describe the whole week. One large operator can move the median by registering thousands of similar agents, as the swing from Week 36 to Week 37 showed. Reading the median next to the owner count and the tier mix reveals whether a few operators drove the result.

Compare Weeks to Ranges, Not to Single Points

A record high or low draws attention, but a range tells more. Median trust in Weeks 34 and 35 sat at 563 and 573, and then it rose to 918 and fell to 572 within two weeks. The range between 101 and 918 over the series is wide, so no single week predicts the next.

Remember What the Index Covers

The tracker covers agents that ChainAware has indexed across Ethereum, BNB Smart Chain, Base and Avalanche C-Chain. It does not cover every agent everywhere. In addition, it also reflects the evidence available at indexing time, and scores can change later. A feeder was traced for about 38% of indexed agents, so funding evidence is missing for many.

Treat Flags as Patterns, Not Verdicts

Flags describe risk patterns. A farm flag signals shared funding or ownership structure, and an unknown-feeder flag signals an untraceable source. Neither proves wrongdoing. They justify limits and review, and they should not trigger automatic punishment.

Lessons for Registry Designers and Standards Authors

The tracker also offers advice to those who build registries and standards. Three lessons stand out.

First, publish quality metrics next to volume metrics. A count of agents says little, whereas a count of independent owners with a trust distribution says much more. Registries that publish only volume invite the wrong conclusions.

Second, make fleet relationships visible. A registry that exposes shared funding and registration timing helps every downstream scorer. The ERC-8004 design already stores owner addresses and agent wallets on-chain, which gives scorers a solid foundation. Additional signals about registration batches and shared controllers would make fleet detection easier.

Third, treat reputation inputs as untrusted by default, and weight them by the reviewer’s own record. The specification itself expects reputation systems to filter by reviewer. In practice, a weighting scheme should discount feedback from young wallets, wallets that share a feeder with the agent’s owner and wallets that review only one operator’s agents.

None of these steps requires central control. They require better data design, and they would make every integrator’s job easier. Importantly, they preserve the neutrality that makes an open registry valuable.

Connecting Registry Patterns to Payments and Commerce

The patterns in an on-chain registry preview problems that other agent ecosystems will face. Agentic commerce is moving into card payments and wallet-based checkout, and the same dynamics apply there: cheap identities, fleets of agents and opaque funding.

Several efforts address parts of the problem. Trulioo describes a Digital Agent Passport that carries an agent’s origin, legitimacy, authorization and consent, as its Know Your Agent explanation sets out. Google’s Agent Payments Protocol uses signed mandates to record what users authorized. OpenAI and Stripe’s Agentic Commerce Protocol lets agents pay with a shared payment token, as Payments Journal reported. Each effort covers identity, authorization or transport.

None of them measures how an operator behaves with money. A passport proves origin, a mandate proves permission and a token proves a payment route. The tracker shows what happens when only those layers exist: fleets, concentration and opaque funding appear anyway. A behavioral layer completes the picture. Moreover, a commentary on the liability of agentic commerce, in its deep dive, argues that traditional human signals vanish when software buys on a user’s behalf. That piece is opinion rather than settled rule, yet its point holds. When human signals vanish, risk teams need signals that describe the agent and its operator.

The overview of the Web3 agentic economy explains why machine-readable trust becomes core infrastructure, and the guide to Web3 trust verification systems maps the five categories of trust problems that protocols face.

What to Watch in the Coming Weeks

Several questions will shape the next reports.

• Will the unknown-feeder share keep rising? A continued rise would weaken the funding signal further.
• Will delegation growth continue? More EIP-7702 accounts would change how teams read owner wallets.
• Will registrations recover toward Week 34 levels? If they do, the trust mix will show whether quality follows.
• Will median trust bounce back from 101? A recovery to the Provisional tier would suggest that honest registrations returned.
• Will new chains change the pattern? Mantle support is in progress, and each new chain brings its own operator mix.
• Will agents per owner stay high? A ratio above 2.0 has marked concentration in past weeks.

Why the Tracker Data Can Be Trusted as Evidence

The tracker scores every indexed agent from on-chain behavior only, with no reviews or self-reported inputs, so a fleet cannot vote its way up. In addition, the underlying models are ChainAware’s own: 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. Even so, attackers’ addresses and feeders pass through the same fraud detection, so abnormal behavior lowers their scores. For that reason, the weekly numbers describe predicted risk and not a popularity contest.

Key Facts at a Glance

• ChainAware’s weekly Agent Trust Tracker follows ERC-8004 agents across Ethereum, BNB Smart Chain, Base and Avalanche C-Chain.
• By Week 41 of 2026, the index held 568,590 agents.
• Week 34 set the registration record at 31,979 new agents.
• The highest median trust, 918, came in Week 36, and Week 41 set the lowest since Week 5, 101.
• Weeks 31 and 38 showed concentration bursts, with agents per owner at 2.54 and 2.30.
• Farm detection flagged 21.1% of agents at launch and 16.12% in Week 40.
• The unknown-feeder share nearly doubled to 12.84% in Week 41.
• EIP-7702 delegation rose 33.8% between Week 35 and Week 40.

Frequently Asked Questions

What does the Agent Trust Tracker measure?

It reports weekly registrations, unique owners, agents per owner, median trust of new agents, tier mix and flag shares for indexed ERC-8004 agents.

What is agents per owner, and why does it matter?

It is the number of new agents divided by the number of unique owner wallets. A rising ratio shows that few operators drive growth. Weeks 31 and 38 reached 2.54 and 2.30.

Why did median trust fall to 101 in Week 41?

Registrations rebounded 55.3% to 10,706, but the new agents skewed to low scores, and the unknown-feeder share nearly doubled to 12.84%. The tracker does not claim a single cause.

Are flagged agents fraudulent?

Not necessarily. Flags signal risk patterns such as shared funding or an untraceable source. They justify limits and review, not automatic rejection.

Why does registration volume say little about quality?

Registration is open and cheap, and a few large operators can dominate a week. Week 34 set the volume record while Week 41 set a quality low.

What is a Sybil farm in this context?

A Sybil farm is a group of agents or wallets that one operator controls while presenting them as independent. Farm detection compares funding, timing and ownership across agents.

How can I use the tracker in my own risk policy?

Read it weekly, set triggers such as a ratio above 2.0 or a median at or below 200, and tie those triggers to minimum tiers for sensitive access. Review outcomes monthly.

Does the tracker cover every ERC-8004 agent?

No. It covers agents that ChainAware has indexed across four chains, with Mantle in progress. A feeder was traced for about 38% of indexed agents.

Is the tracker free?

Yes. The tracker posts are public, and the Agent Trust Score is free for public indexed agents, with 1,000 queries per month and no signup. See the Agent Trust Score page for current details.

How do I check an individual agent?

Use the free Agent Trust Score tool, or call the same data through the Prediction MCP and the fraud detection API.

A Short Glossary of Tracker Terms

• ERC-8004: an Ethereum standard for agent discovery and trust, built around identity, reputation and validation registries.
• Agents per owner: new registrations divided by unique owner wallets in a week.
• Median trust: the middle Agent Trust Score among a week’s new registrations.
• Tier: one of five score bands, from Untrusted (0-199) to Sovereign (800-1000).
• Farm-detected: a flag for agents that appear to belong to one operator’s fleet.
• Feeder wallet: the address that first funded an owner wallet.
• Unknown feeder: a feeder whose source could not be traced to a known entity.
• EIP-7702: an Ethereum upgrade that lets an ordinary account delegate execution to contract code.
• Concentration burst: a week when registrations hold up while unique owners fall.

Conclusion: Read the Series, Not Just the Week

A single weekly report shows a snapshot. The series shows a pattern. Volume and quality move independently, concentration bursts repeat, farms stay large, funding gets harder to trace and delegation keeps growing. Together, these patterns describe a registry where cheap identities scale faster than trust.

None of this means that agents are bad. Many registered agents are legitimate, and many operators build honest products. The point is that an open registry cannot tell the two groups apart by itself. Independent evidence has to do that work, and the evidence has to refresh as conditions change.

Start with a small step. Read the latest weekly report, note the median and the agents-per-owner ratio, and compare them with your own counterparties. Then write a rule that ties a trigger to a minimum tier. For the full background, read the launch article, explore autonomous compliance screening, and see how ChainAware Investigation supports a deeper review of any suspicious owner wallet. Token-level risk sits next to agent risk in many integrations, and the Token Audit covers it. In addition, our overview of the 32 Claude sub-agents shows how ChainAware’s own agent fleet applies these checks.

Implications for AI Agent Builders

Builders of AI agents sit on both sides of the tracker. They want counterparties to trust their agents, and they depend on other agents and protocols that they must trust in turn. The weekly data offers practical lessons for both roles.

If You Build Agents

Builders can earn better tiers through ordinary good practice. Fund the owner wallet from a verified exchange account, because the feeder carries real weight. Avoid sharing one funding source across many unrelated owner wallets, since shared feeders look like fleets. Keep owner wallets active and consistent over time, and separate treasury, operating and test wallets.

Builders should also publish what they can prove. A registration file that links to audits, code references and a documented funding structure gives counterparties something to check. Claims without evidence blend into the noise that the tracker describes. Evidence stands out, particularly in a registry where the median new agent scores 101.

Finally, builders should monitor their own standing. A look-up of your own agents once a week costs nothing and shows how counterparties see you. When a score drops, investigate the cause before a partner does.

If You Integrate Agents

Integrators should treat the registry as a discovery layer and the score as a gate. Look up each counterparty before granting access, apply tier-based limits and re-check on a schedule. Keep a log of every decision, so that disputes and audits have a clear record.

Integrators can also let their own agents check counterparties automatically. Through the Prediction MCP, an agent can call the trust score before it pays or delegates. The logic stays simple because the output has a fixed structure. A human cannot sit in a loop that runs thousands of times a day, so machine-to-machine checks matter more every month.

If You Invest in Agents

Investors should ask for the same evidence that counterparties need. Where do the agents sit in the tier distribution? Who funds the owner wallets? How many sibling agents share an operator? A project that answers these questions openly deserves attention, and a project that dodges them has told you something about its priorities.

What a Healthy Agent Profile Looks Like

The tracker describes the registry as a whole, but individual agents can look healthy too. Counterparties can use a short profile as a mental model.

• Traceable owner. The owner wallet has a visible history of ordinary activity, and its fraud probability is low.
• Clear funding source. A verified exchange or a well-understood wallet funded the owner, and no flag marks the feeder as unknown or fraud-linked.
• No fleet signature. The owner runs a small number of agents, and no group of near-identical agents shares its funding.
• Clean creator record. The creator wallet has no rug pull or honeypot history.
• Independent feedback. Reviewers have their own histories, and they review many different agents.
• Consistency over time. Behavior and funding stay stable across re-checks.

Agents that match the profile tend to land in the Trusted or Sovereign tiers. In addition, agents that miss several items land lower, and agents that miss the most important items land in Untrusted. The profile also gives operators a checklist, since each item corresponds to something they can influence.

A Note on Timing and Freshness

Timing affects every reading in this article. The tracker publishes weekly, and the scores behind it update as new evidence arrives. A counterparty that checks an agent today sees today’s evidence, which may differ from the figure in last week’s report.

Freshness matters most for three groups of agents. New agents change quickly, because their histories are short and each new transaction moves the picture. Agents that change owners can shift tiers overnight, since a new owner brings a new funding chain. And agents in fast-growing chains can see their labels improve as exchange and entity databases catch up, which may lift scores that looked low earlier.

For these reasons, policy should treat any score as a dated reading. Store the time of each lookup, set a refresh window that matches the value at risk and trigger a fresh check before large or unusual actions. A score that is a month old is a claim about the past. In addition, a score from this minute is evidence about the present, and the difference can decide whether a protocol approves a request.

The weekly series gives the long view, and a live lookup gives the current one. Teams should use both. The series shows which way the registry moves, and the lookup shows where a specific agent stands today.

The post Agent Fraud Patterns From the ERC-8004 Tracker: What the Weekly Data Reveals first appeared on ChainAware.ai.

Every AI agent has an owner, and every owner wallet has a first source of money. That source, the feeder wallet, is hard to hide, easy to read and rarely checked. This guide explains funding-chain risk, shows how the feeder shapes an Agent Trust Score, and describes how teams can put the signal to work in access policies, compliance reviews and automated agent flows.

Most agent security checks start with the agent itself. They read the registration file, look at the feedback and review the stated purpose. Those facts matter, but the operator writes most of them. A funding record works differently. It sits on a public ledger, and nobody can edit it after the fact. Therefore, it often tells a more honest story than any description the agent offers.

Compliance teams know this logic well. Banks have asked where a customer’s money came from for decades. Blockchains make the same question easier to answer, because every transfer is public and permanent. Yet most agent integrations skip the question entirely. They grant access based on a name, a card and a rating, and they never look at the money behind the operator.

This article closes that gap. It defines the feeder wallet, explains why funding predicts risk, and walks through the signal spectrum from verified exchange to confirmed fraud. In addition, it also uses public data from ChainAware’s launch analysis and weekly tracker, and it stays honest about limits. A signal only helps when its users know where it fails.

The Oldest Question in Compliance

Source-of-funds checks sit at the center of anti-money-laundering practice. The logic is simple. Funds carry history. A clean source supports trust, and a tainted source casts a shadow over everything that follows. The Financial Action Task Force applies this thinking to virtual assets as well, and its guidance on virtual assets sets the international standard that regulated firms follow.

Traditional finance has to ask the question through paperwork. A customer provides statements, and an analyst reviews them. The process is slow, and it depends on documents that people can forge. On a public blockchain, the same question has a better answer. The ledger shows the first funding transaction of every wallet, and it shows who sent it. No document is needed, and no one can quietly alter the record.

AI agents add urgency to the question. Creating an agent costs almost nothing, and an operator can register hundreds in an afternoon. Registration files are free text. Feedback can come from many wallets. In that environment, funding becomes one of the few signals that still costs something to fake.

Why Agents Make Funding More Important

Three features of the agent economy raise the value of funding evidence.

First, agents act without a human watching. A person who opens a bank account faces a branch, a form and a face-to-face check. An agent faces none of these, so counterparties need machine-readable evidence instead.

Second, agents come in fleets. One operator can run thousands of them, and each one looks like an independent party. Funding links often reveal the group, because the operator needs money in every wallet.

Third, the value at risk is growing. McKinsey estimates that agent-mediated commerce could reach $3 trillion to $5 trillion globally by 2030. As more value flows through agents, the cost of trusting the wrong one rises with it.

What a Feeder Wallet Is

The feeder wallet is the address that funded an agent’s owner wallet. Think of it as the parent of the owner. When an owner wallet received its first gas or its first deposit from an address, that address became the feeder. The feeder’s own history then becomes evidence about the owner.

ChainAware’s Agent Trust Score reads the feeder as one of three core pillars, next to the owner wallet’s fraud probability and the creator’s criminal record. The creator’s record covers rug pulls and honeypot deployments. A fleet-level view then adds farm detection across agents. Together, these elements produce a 0 to 1,000 score, a tier and a set of named flags.

How the Feeder Gets Traced

Tracing a feeder means following the first funding transaction of the owner wallet back to its source. Sometimes the source is a labeled address, such as a verified centralized exchange. Moreover, sometimes it is an ordinary wallet with its own history. Sometimes the trail runs through several fresh wallets and ends nowhere useful.

ChainAware traced a feeder for roughly 38% of indexed agents. That coverage figure matters for interpretation. For the agents where tracing works, the signal is strong. Furthermore, for the rest, the absence of a traced feeder is itself information, though a weaker one. The platform does not claim to trace everything, and good policy should not assume it does.

Where the Feeder Sits in the Score

The feeder acts differently from the other pillars. A feeder at a verified exchange lifts the score, since the exchange applied its own checks. An unknown feeder pulls it down, because the source of funds cannot be established. A feeder with confirmed fraud or rug pull history suppresses the score hard, whatever the other pillars say. In other words, the feeder can both help and veto.

Why Funding Predicts Risk

Funding evidence is informative for four reasons. Each one explains a different kind of fraud.

It is costly to fake. An operator can write any agent card in minutes. Instead, it cannot rewrite who sent its first funds. Therefore, funding evidence resists the cheap manipulation that undermines other signals.

It links operators. Farms need many wallets, and many wallets need funding. Operators usually draw that funding from a small set of sources, because splitting every top-up across unrelated origins costs effort. Shared feeders consequently expose fleets, even when each owner wallet looks independent.

It carries inherited reputation. A wallet funded by a regulated exchange passed that exchange’s checks. In contrast, a wallet funded by a known rug pull operator tells a different story. Each new wallet inherits a shadow of its parent’s history.

It reveals intent to hide. Funding routed through obfuscation layers makes tracing harder. Opacity does not prove wrongdoing, since privacy-minded users also hide origins. Still, it is a risk signal worth pricing, because honest operators rarely need five hops to move money from an exchange to a wallet.

The Feeder Signal Spectrum

Feeders fall along a spectrum, from a strong positive to a hard stop. Each point on the spectrum maps to a flag and a suggested response.

Two details matter. First, the positive end is narrow. Only 1.0% of agents in the launch analysis carried a verified-exchange feeder. Second, the negative end moves the score sharply. A feeder with confirmed fraud history suppresses the score regardless of how good the other signals look.

Reading the Positive End

A verified-exchange feeder deserves a modest bonus, not blind trust. The exchange checked its customer, which lowers the chance that the owner is a throwaway identity. However, a bad actor can open an exchange account, and a clean source says nothing about what the owner does next. For that reason, the Agent Trust Score treats a verified feeder as a strong positive that still needs support from the other pillars.

Reading the Middle

Most agents with a traced feeder fall into the neutral middle. The feeder is an ordinary wallet, and its history neither helps nor hurts. In these cases, the other pillars decide the tier. Teams should treat this group as the default population and tune policy mainly for the two ends.

Reading the Negative End

An unknown feeder is a soft negative. It signals that the source of funds cannot be established, so counterparties should cap value and monitor activity. A feeder with fraud history is a hard negative. It links the owner to a party that has already been caught, and no amount of polished metadata offsets that link.

What the Data Shows

The public numbers show how the spectrum looks across a real registry.

The Launch Analysis

ChainAware’s launch analysis covered 274,792 indexed ERC-8004 agents. Within that population, 9.5% carried FEEDER_UNKNOWN, 1.0% carried FEEDER_CEX_VERIFIED and 0.3% carried FEEDER_RUG_HISTORY. In addition, 741 agents had been funded by confirmed rug pull operators. The farm flag, which depends partly on shared funding, appeared on 21.1% of agents. Beyond that, the launch article lists the full flag breakdown.

The table shows a lopsided picture. Verified sources are rare. Unknown sources are nearly ten times as common. And a significant group of agents traces back to operators with confirmed fraud.

The Weekly Tracker

The weekly Agent Trust Tracker follows how these shares move. At the same time, the Week 41 report, for example, showed the unknown-feeder share nearly doubling to 12.84% of indexed agents, as the population reached 568,590. That jump matters. The feeder is the hardest signal to fake, and an untraceable feeder weakens it.

Farm shares add context. Weekly reports showed 18.73% in Week 32, 18.39% in Week 33, 17.05% in Week 34 and 16.12% in Week 40. The share eased as the population grew, but the absolute number of flagged agents stayed large. On an index of more than half a million agents, even 16% represents a big group of coordinated wallets.

Concentration offers another clue. In Week 31, unique owners collapsed 58.7% to 8,413 while registrations fell only 7.0%, so agents per owner more than doubled to 2.54. The Week 31 report and the Week 32 report explain how concentration and shared funding connect. When few owners control many agents, shared feeders usually follow.

What the Numbers Mean

Three conclusions follow. First, trustworthy funding is scarce, so a verified source stands out. Second, untraceable funding is growing, which makes the remaining signals more important. And third, funding and fleet structure are tied together, since farms need money in many wallets.

Three Funding-Chain Patterns to Watch

The patterns below are illustrative. They describe shapes that investigators look for, and they do not name specific agents.

The Star

One feeder funds dozens of owner wallets within minutes. Each owner registers one or two agents. On the surface, the agents look independent. The star pattern shows that they are not, because one source stands behind all of them.

Defenders can respond in two ways. They can aggregate limits by feeder, so that the whole star shares one budget. Notably, they can also apply the weakest tier in the star to every member until the operator proves independence.

The Relay

Funds pass through a short chain of fresh wallets before they reach the owner. Each hop adds distance from the original source. Relays do not prove fraud, since some users route funds for privacy. They do, however, mask the source, and that is exactly the purpose of using them.

Defenders should treat a relay as a reason for limits. The trail often ends in the unknown category, which already carries a penalty. When the stakes rise, a deeper review can follow the relay hop by hop.

The Recycled Creator

A creator wallet with a rug pull history funds a new owner wallet. The new owner has no record of its own, yet it inherits the creator’s. A check of the owner wallet alone would miss this link. The feeder check catches it, because the creator’s address sits one step upstream.

This pattern explains why the Agent Trust Score reads the creator’s record as its own pillar. Bad actors rarely stop after one attempt. They create fresh wallets, and the funding chain connects the old identity to the new one.

A Worked Example: Following the Money

This example is invented to show the method. It does not describe a real agent.

A DeFi protocol receives a request from an agent for treasury read access. The agent’s card is polished, with a clear description and a professional name. Its owner wallet is five weeks old, and the owner has done little besides fund and register.

The check starts with the owner. Instead, the fraud probability is moderate, but the history is short, so it tells little. Next, the check follows the money to the feeder. The feeder is a wallet with no label. It funded the owner and eight other wallets within one hour, and two of those wallets registered near-identical agents.

At this point, the picture changes. The agent is probably one of a set. In addition, the unknown feeder prevents any credit for a reputable source. The farm flag confirms the pattern, and the tier falls to Elevated Risk. However, the protocol grants no treasury access and stores the flags as the reason.

Nothing in the agent card hinted at any of this. The funding chain revealed it in minutes. Furthermore, the example shows why funding evidence belongs near the start of any agent review.

Anatomy of a Funding Trace

A funding trace follows the money one step at a time. Analysts use the same method on every wallet, and the steps are short enough to run in minutes.

Step 1: Find the Owner Wallet

The trace starts with the owner address from the agent’s registration. In ERC-8004, the owner controls the identity token, and the agent wallet field starts as the owner’s address. This wallet is the anchor. Everything that follows hangs off its history.

Step 2: Find the First Funding Transaction

Next, the analyst looks for the first inbound transfer of value, usually a small amount of native gas. The sender of that transfer is the feeder. Sometimes the owner wallet received several early transfers from different senders. In that case, the analyst notes all of them and weighs the largest and the earliest most heavily.

Step 3: Classify the Feeder

The analyst then asks what kind of address the feeder is. A labeled exchange hot wallet belongs in one category. An ordinary wallet with a long, quiet history belongs in another. A fresh wallet with no history, a bridge contract or a mixer belongs in the risky categories. Labels, history and behavior all inform the classification.

Step 4: Look Upstream

When the feeder is a fresh or unlabeled wallet, the analyst steps one hop upstream and repeats the question. Each hop adds distance from the original source, and each hop either resolves into a known entity or stays opaque. Most analysts set a hop limit, because a trace that never ends does not help a decision.

Step 5: Look Sideways

The final step looks sideways at everything else the feeder funded. If the same feeder funded many other owner wallets, the analyst checks whether those wallets registered similar agents around the same time. A positive result suggests a fleet.

Where Automation Helps

Manual tracing works for a handful of wallets. It does not scale to a registry with more than half a million agents. The Agent Trust Score automates the first four steps and adds fleet detection for the fifth. Teams then spend their time on the flagged cases, not on routine tracing.

Funding Evidence Across the Agent Lifecycle

Funding matters at different moments in an agent’s life. Teams that understand the lifecycle can place checks where they do the most good.

At Registration

A new agent appears with a clean slate. Behavior history is short, so funding often carries most of the weight. Counterparties can use the feeder flag to decide whether a new agent receives any access at all. A verified-exchange feeder supports a modest starting limit. An unknown feeder supports a cautious start.

During Operation

As an agent operates, new funding events appear. The owner tops up gas, receives payments and moves funds. Most of these events are ordinary. Still, a sudden new source, such as a fresh wallet that sends a large sum, deserves a look. Scheduled re-checks catch these changes, and they keep the first impression from outliving the facts.

At Change of Ownership

Registry tokens can transfer. When an agent changes hands, the new owner may bring a different funding chain and a different record. The ERC-8004 specification clears the agent wallet field on transfer and requires fresh verification, which acknowledges that a transfer changes the trust picture. A counterparty should treat an ownership change as a new onboarding event and re-score the agent from scratch.

At Scale-Up

Operators who grow their fleets often add owner wallets quickly. Scale-up periods show up in the data as concentration bursts, with many agents appearing under few owners or with shared funding. Counterparties should tighten aggregate limits during such periods, not loosen them.

Five Illustrative Scenarios

The scenarios below are invented to show how funding evidence changes decisions. They do not describe real agents.

Scenario 1: The Exchange-Funded Newcomer

A new agent has little history, but its owner wallet received its first funds from a verified exchange. The owner is independent and runs a single agent. Likewise, the protocol grants a small starting limit and raises it as the agent builds a record. In this case, funding evidence helped a legitimate newcomer get started.

Scenario 2: The Anonymous Relay

An agent’s owner wallet received funds through four fresh wallets in two days. The trail ends in a wallet with no history. Nothing proves wrongdoing, but the source cannot be established. The protocol allows low-value actions only, applies velocity caps and re-checks in a week.

Scenario 3: The Rug Pull Link

An agent with a convincing card asks for lending access. Its owner wallet traces back to a creator address that has a confirmed rug pull record. The score is hard-suppressed, and the protocol declines. By contrast, the card never mentioned the link, and no other signal showed it.

Scenario 4: The Fleet Behind the Friendly Faces

Forty agents apply to a grant program through thirty-one owner wallets. All wallets share one unlabeled feeder, and all registered within the same afternoon. The program treats the group as one applicant. However, the operator receives a single allocation and learns that splitting wallets does not multiply rewards.

Scenario 5: The Quiet Ownership Change

An agent with a long, clean history changes owners. The new owner’s wallet is two weeks old and has an unknown feeder. An automatic re-check lowers the tier and the agent’s limits fall. The counterparty avoided inheriting trust that the old owner earned.

What the Scenarios Teach

Funding evidence plays a different role in each case. It helps newcomers, it limits opaque operators, it blocks linked bad actors, it exposes fleets and it catches changes after approval. A good policy uses all five roles.

How Funding Evidence Fits Into Know Your Agent

Funding evidence belongs to the behavior input of a wider Know Your Agent process. That process draws on five inputs: identity, authorization, integrity, behavior and status. Identity and authorization decide whether a request is valid. Behavior, including funding, decides how risky the operator is. Our guide to KYA versus agent identity explains the full structure, and the companion piece on ERC-8004 trust signals shows how the registry and the score divide the work.

The feeder check fits after the validity gates and before the final policy. A request that fails identity or authorization stops there. Notably, a request that passes moves to scoring, and the feeder flag shapes the result. This order saves effort, because cheap validity checks run first.

A Rule Set for Feeder Flags

A simple rule set turns feeder flags into actions.

1. FEEDER_RUG_HISTORY: deny the request and escalate to a human reviewer.
2. FEEDER_UNKNOWN: allow only low-value actions, with velocity caps and monitoring.
3. No feeder flag: apply the standard tier-based policy.
4. FEEDER_CEX_VERIFIED: apply the tier-based policy, and consider a modest limit increase if the other pillars are clean.
5. Shared feeder across many owners: treat all linked agents as one risk unit.

These rules are a starting point. Each team should adjust the thresholds to its own risk appetite and its value at risk.

Combining Feeder Flags With Tiers

Flags and tiers work best together. The table below shows one way to combine them.

Rules like these have three advantages. Auditors can follow them. Engineers can automate them. And operators can see exactly what they need to improve.

Funding Checks in Compliance Practice

Funding-chain checks are not new to regulated finance. They match familiar practices, so compliance teams can explain them to auditors in existing terms.

Source of funds. Banks ask where a customer’s money came from. A feeder check is the on-chain version of this question, and it needs no paperwork.

Network analysis. Investigators look for clusters of accounts that share counterparties. Shared feeders apply the same idea to wallets.

Enhanced due diligence. Higher-risk customers receive extra review. Elevated Risk agents and unknown-feeder agents deserve the same treatment.

Ongoing monitoring. Banks re-check customers over time. Agents need the same cycle, since funding patterns and behavior change.

For deeper review, ChainAware Investigation turns a single wallet address into a structured seven-section report in about a minute. It covers identity, activity, counterparties, risk, circular flows, AML exposure and a conclusion. An analyst can run it on the owner wallet, then on the feeder, which takes one more minute. The article on wallet forensics and AML reports shows how analysts read the output. For protocols with regulatory duties, the DeFi compliance overview and the guide to DeFi compliance tools explain which obligations apply.

Sanctions and Illicit-Finance Exposure

Funding evidence also touches sanctions risk. A feeder that links to sanctioned or flagged activity creates exposure for everything downstream. The authoritative list for United States designations is the OFAC sanctions list service. ChainAware’s reports screen against it and evaluate indirect exposure through counterparties. The reports remain informational. In practice, the regulated institution still makes the decision and carries the filing duties.

Building the Check Into Your Workflow

A feeder rule is easy to code once the score is available. In plain terms, the logic looks like this.

1. Look up the agent’s score, tier and flags.
2. If the flags include a fraud-history feeder, deny and escalate.
3. When the flags include an unknown feeder, cap the action size and require monitoring.
4. Should the flags include a farm marker, treat all agents from the same feeder as one risk unit.
5. Otherwise, apply the tier policy.
6. Log the result with the time of the lookup.

The same steps work in a smart contract guard, a backend service or an agent’s own decision loop. For high-volume screening, the fraud detection API delivers the underlying behavioral engine at scale.

Letting Agents Check Each Other

Agents can run the check themselves. Through the Prediction MCP, an agent can query a counterparty’s score before it pays or delegates work. The decision logic stays simple, because the output has a fixed structure. ChainAware’s own fleet works this way, as the overview of the 32 Claude sub-agents shows. This machine-to-machine step matters, because a human cannot sit in a loop that runs thousands of times a day.

Implementation Notes

Developers should keep several practices in mind.

• Cache with care. A score from last month may no longer apply, so set a time to live that matches the value at risk.
• Log every decision. Store the tier, the flags and the rule that fired.
• Fail safe. If a lookup fails, fall back to a low-limit policy.
• Handle partial data. A feeder was traced for about 38% of agents, so missing data is common and should not crash the flow.
• Offer an appeal path. Operators who improve their funding record should earn a better tier.

How Operators Can Improve Their Standing

A trust layer should reward good behavior. Operators who want better tiers can act on the funding signal directly.

• Fund owner wallets from a verified exchange account.
• Avoid using one funding source for many unrelated owner wallets.
• Keep owner wallets active and consistent over time.
• Separate treasury, operating and test wallets, and document their roles.
• Avoid receiving funds from addresses with fraud-linked history.
• Publish the funding structure of agent treasuries when the project asks investors for trust.

None of these steps is a trick. Each one is a sign of an operator with a traceable, stable record, which is exactly what a counterparty wants to see. Because the signal rewards honest structure, it also gives good operators a competitive edge.

Limits of the Feeder Signal

Honest use of any signal needs a clear view of its limits.

• A clean feeder is not a clean agent. Bad actors can use exchange accounts, so combine the pillars.
• An unknown feeder is not proof of fraud. Privacy-minded users and bridge routes also hide origins.
• Coverage is partial. A feeder was traced for about 38% of indexed agents.
• Funding is a snapshot of history. Later top-ups may come from other sources.
• Exchanges differ. A verified feeder shows that the exchange ran checks, not how rigorous they were.
• Flags describe patterns. They justify limits and review, not automatic judgment.

These limits explain why the score combines several pillars and why teams should pair it with identity checks and their own policy.

Weighing Funding Against the Other Signals

Funding evidence works best as one voice in a chorus. The Agent Trust Score combines three pillars and a fleet view, and the weights shift with the situation.

When Funding Should Carry More Weight

Funding deserves the most weight when an agent is new, when the owner wallet has a short history and when the value at risk is high. In those cases, behavior history gives little to read, and the feeder fills the gap. A hard-suppressing flag, such as a feeder with confirmed fraud history, should override everything else.

When Funding Should Carry Less Weight

Funding matters less when the owner has a long, clean history on its own. A two-year record of ordinary activity says more about the owner than a feeder that appeared once. Funding also carries less weight when the feeder could not be traced, since an unknown feeder says only that the source is unclear. Other pillars then decide the tier.

How to Break a Tie

Sometimes signals disagree. A verified-exchange feeder may sit next to a farm flag, or a clean owner may show a creator with a rug pull record. In those cases, policy should favor the more conservative reading for high-value access and the more permissive reading for low-value access. The tie-breaker follows the value at risk.

Funding Evidence in Other Trust Problems

The feeder idea reaches beyond agent access. Several Web3 trust problems share the same structure, and funding evidence helps with each of them.

Airdrop and Incentive Farming

Incentive programs attract farms. Operators create many wallets to collect many rewards, and they fund those wallets from a few sources. Shared feeders expose the pattern. Programs that apply feeder-based clustering can treat linked wallets as one claimant. The guide to Web3 Sybil protection systems compares the main approaches.

Governance Attacks

Governance attacks often rely on accounts that appear independent but share a funding source. A proposal that gathers votes from wallets with a common feeder deserves extra scrutiny. Funding evidence helps a DAO separate organic support from coordinated manipulation.

Lending and Credit

Lenders already weigh the source of a borrower’s funds. On-chain lenders can apply the same logic to agent borrowers, and they can set collateral requirements by funding category. Unknown-feeder borrowers might post higher collateral, while verified-exchange borrowers might qualify for better terms.

Token Launches

Rug pulls often come from creators who reuse funding paths. A feeder check on a token deployer can flag a link to earlier abuse. ChainAware’s Token Audit covers token-level risk, and the wider comparison of rug pull detection tools shows how teams combine signals.

How Funding Evidence Differs From Reputation Scores

Reputation systems and funding evidence solve different problems. A reputation system collects opinions about past behavior. Funding evidence reads the money trail. Both help, and each has blind spots.

Reputation systems can lag. A new agent has no reputation, so the system says nothing. Funding evidence works from the first day, because the first funding transaction already exists. In the other direction, funding evidence cannot tell whether an agent performs well. A reputation system can, if its reviewers are honest and independent.

Reputation systems also invite gaming. The ERC-8004 reputation registry blocks the owner from reviewing its own agent, yet an operator can still post feedback from other wallets. Funding evidence catches that move, because the reviewers and the owner share a source. A combination of the two gives a stronger signal than either one alone. Our guide to ERC-8004 trust signals explains how reviewer weighting uses funding data.

Questions Risk Teams Ask

Risk and compliance teams ask the same questions when they first meet funding evidence. The answers below address them directly.

Do We Need to Block Unknown Feeders?

No. Blocking everything unknown rejects honest operators who value privacy or who use bridges. A better approach caps value and increases monitoring. The unknown category should cost an agent some access, not all of it.

How Much Should a Verified Feeder Help?

A verified feeder should help modestly. It shows that an exchange ran its own checks, which lowers the chance of a throwaway identity. By contrast, it does not prove that the owner behaves well afterward, so the other pillars still apply.

What About Agents With No Traced Feeder?

Roughly six in ten indexed agents fall into this group, since a feeder was traced for about 38%. For these agents, the owner’s fraud probability and the creator’s record carry more weight. Teams should not treat missing data as a failure, but they should treat it as a reason for caution at high value.

Can an Operator Fix a Bad Funding Record?

Operators can improve over time. They can fund new wallets from verified sources, keep wallets active and avoid linking to risky addresses. A hard flag, such as a feeder with confirmed fraud history, is much harder to shake off, because the link is permanent. For that reason, operators with a bad history often start over with a new identity, and fleet and creator checks aim to catch that move.

How Often Does Funding Change?

Most owner wallets keep the same first feeder forever, since the first transaction never changes. New funding events keep arriving, though, and they may come from different sources. That is why teams should re-score on a schedule and not treat the first feeder as the final word.

A 90-Day Adoption Plan

Teams that want to adopt funding checks can follow a simple plan.

Days 1 to 30: Observe

Inventory every place where an agent can touch money or permissions. Look up the counterparties you already see and record their tiers and feeder flags. Do not block anyone yet. The baseline shows how much risk you carry today and which flags occur most often.

Days 31 to 60: Write Policy

Define one rule per access level, using tier and feeder flag together. Decide how to treat unknown feeders, and decide when to escalate. Agree who owns exceptions. Write the policy in one page, so that engineers, compliance staff and operators can all read it.

Days 61 to 90: Enforce and Measure

Turn the rules on for new agents, and add a scheduled re-score for existing ones. Track the metrics listed earlier, including approval rate and incident rate by feeder category. Review exceptions weekly and adjust thresholds with data.

By day 90, the team has a documented control, a measurable baseline and a clear owner. That outcome is more useful than a perfect model, because a working control beats an ideal one that never ships.

Practical Steps for Different Teams

Different teams meet agents in different places. Each one can start with a concrete step.

DeFi Protocols and DAOs

Protocols can add the feeder flag to their allow-list logic. Agents that request vault or treasury permissions should clear a higher bar, so FEEDER_UNKNOWN agents deserve extra review before they receive such access. DAOs can apply the same rule to agents that vote or propose on behalf of a delegate. The overview of Web3 trust verification systems maps five categories of trust problems, and funding evidence supports several of them.

Agent Marketplaces and Registries

Marketplaces can show the feeder flag next to each listing. Buyers should see whether an agent’s money has a traceable source. A flag display also changes operator behavior, since operators who want better placement will clean up their funding.

Payment and Fintech Teams

Where settlement runs on-chain or through stablecoins, the feeder check works as a source-of-funds control for agent wallets. It belongs in the same family as the checks that teams apply to human customers. Payment teams also gain a signal that survives the loss of human behavioral data, because funding history does not depend on device or session information.

Investors and Strategic Partners

Investors who back agent projects should ask for the funding structure of treasury and operating wallets. A team that can show a clean, traceable chain has told you something good. However, a team that cannot, or will not, has told you something else. A May 2026 study by researchers affiliated with Pantera Capital, Stanford, IC3 and Ava Labs found that even agents with fully public wallets could not always be verified as autonomous. Our article on how investors should evaluate AI trading agents covers the findings.

Security and Incident Teams

Security teams can use funding chains to map attacks. When an exploit involves an agent, the feeder shows who funded the attacker and which other wallets share that source. Repeated lookups track how funds move over time. In this setting, speed matters more than polish, which suits a one-minute report.

Metrics That Show Whether Funding Checks Work

A funding policy deserves measurement. Teams can track a short list of indicators and tune thresholds with data.

• Share of agents by feeder flag. Know how many counterparties are CEX-verified, unknown or fraud-linked.
• Approval rate by feeder category. Verified feeders should show higher approval rates.
• Loss and dispute rate by feeder category. Unknown-feeder agents should account for more incidents. If they do not, the limits need work.
• Fleet concentration. Track how many owners share each feeder.
• Re-check coverage. Measure the share of active agents scored within the chosen window.
• Overrides. Every manual override needs a reason, and a pattern of overrides points to a policy gap.

Leadership benefits from these numbers too. They turn a vague promise of agent security into a visible control with measurable results.

Common Mistakes When Using Funding Evidence

Teams repeat a handful of mistakes. Avoiding them saves time and losses.

• Ignoring the feeder. Many teams read the agent card and skip the money behind the owner.
• Treating unknown as guilty. Block everything unknown and you reject honest, privacy-minded operators. Limits and monitoring work better.
• Treating verified as safe. A verified feeder helps, but it cannot clear a bad owner.
• Checking agents one at a time. Shared feeders show up only when you compare agents across a fleet.
• Setting one threshold for all actions. A small payment and a treasury permission deserve different rules.
• Forgetting to re-check. Funding and behavior change, so schedule the next look.

Where Funding Evidence Is Heading

Several trends will raise the value of funding evidence over the next two years.

More Agents, More Fleets

Agent numbers keep growing. The indexed population passed 568,590 agents by Week 41, and registrations swing widely from week to week. As fleets grow, counterparties will need fleet-level views, and shared funding is one of the best fleet signals available.

Harder Tracing

The unknown-feeder share nearly doubled in Week 41. Operators who want to hide will keep adding hops. Scoring systems will need to follow funding across chains, bridges and mixers, and they will need to price opacity honestly.

Standards Around Identity and Payments

Identity and payment standards keep maturing. Trulioo describes a Digital Agent Passport that carries an agent’s origin and authorization, and its Know Your Agent explanation shows how verification firms think about the problem. Google’s Agent Payments Protocol uses signed mandates to record what users authorized. The ERC-8004 specification gives agents public identity, feedback and validation hooks. None of these standards judges the operator’s money. Funding evidence fills that gap, and it complements each of them.

Machine-to-Machine Trust

Agents will check each other’s funding before they transact. The overview of the Web3 agentic economy explains why machine-readable trust becomes core infrastructure. In that world, a fast, structured funding signal becomes a default input to every agent-to-agent decision. The broader market view in the agent trust infrastructure race compares how providers approach the problem.

Why the Funding Signal Carries Weight

Funding analysis rests on models with a long record. ChainAware did not start with agents. Its models analyze more than 25 million wallet addresses, more than 2.4 billion predictive data points and more than 1.8 million contracts checked for honeypots. The company reports 95% accuracy for its per-address fraud model, and anyone can verify it against public data through ScamDB. In a test on PancakeSwap on BNB Smart Chain, covering weeks 10 to 20, the rug pull model predicted 90.1% of rug pulls before they happened, as documented on the rug pull verification page. Separately, more than 940,000 rug pulls have been documented after the fact, and ChainAware covers them in its weekly rug pull news. The feeder flags in the Agent Trust Score build on that work. They do not rank agents. In addition, they predict risk from where the money came from.

An attacker cannot easily hide here. The attacker’s own address and feeder address pass through ChainAware’s machine-learning fraud detection, so abnormal funding behavior is punished and not rewarded. Faking a clean funding history also costs real money and time, which makes it a poor target for cheap farms.

Key Facts at a Glance

• The feeder wallet is the address that first funded an agent’s owner wallet.
• Funding evidence is hard to fake, because no one can rewrite who sent the first funds.
• A verified-exchange feeder is the strongest positive signal, an unknown feeder is a risk and a fraud-history feeder hard-suppresses the score.
• ChainAware traced a feeder for about 38% of indexed ERC-8004 agents.
• At launch, 9.5% of agents had an unknown feeder, 1.0% had a verified-exchange feeder and 0.3% had a feeder with rug pull history.
• A further 741 agents had been funded by confirmed rug pull operators.
• The unknown-feeder share nearly doubled to 12.84% in Week 41 of 2026.
• Shared feeders expose Sybil fleets, which carried the farm flag for 21.1% of agents at launch.

Frequently Asked Questions

What is a feeder wallet?

A feeder wallet is the address that first funded an agent’s owner wallet. Its history is evidence about the owner, because funds carry history.

Why does the feeder matter more than the agent card?

The agent card is self-written and free to change. Still, the funding record sits on a public ledger and cannot be rewritten.

What does FEEDER_UNKNOWN mean?

It means the source of funds could not be traced to a known entity. The flag raises risk and calls for limits and monitoring, not automatic rejection.

Is a verified-exchange feeder always safe?

No. It is the strongest positive funding signal, but a clean source does not clean the owner’s own behavior. Combine it with the other pillars.

What happens when a feeder has fraud history?

The Agent Trust Score hard-suppresses the score, whatever the other signals show. Counterparties should deny the request or escalate it to a human reviewer.

How can funding reveal a Sybil farm?

Farms need money in many wallets, and operators usually draw it from a few sources. When one feeder funds many owner wallets that register similar agents, the pattern points to a shared operator.

Does funding evidence work for every agent?

No. ChainAware traced a feeder for about 38% of indexed agents. For the rest, other pillars carry more weight.

How often should funding evidence be re-checked?

Check on a schedule that matches the value at risk, and check again before large or unusual actions. Funding patterns and behavior change over time.

Is the Agent Trust Score free?

The score is free for public indexed agents, with 1,000 queries per month and no signup. Higher-volume teams can use the API or the Prediction MCP. See the Agent Trust Score page for current details.

Conclusion: Follow the Money

Agents change fast, and their descriptions change faster. Funding history stays put. That stability makes the feeder wallet one of the most useful signals in agent trust, because it costs operators real effort to fake and it ties wallets together into fleets.

The public data shows why the signal matters. Verified funding is rare, untraceable funding is growing, and a large share of agents traces back to coordinated operators. A team that reads only the agent card sees a fraction of that picture.

Start with a small step. Look up the counterparties you already deal with, note their feeder flags and write a rule for each flag. Then add the re-check, and keep the evidence trail. For the wider view, read the launch article, explore the Token Audit for token-level risk, and see how the rug pull detection tools compare. In addition, the guide to Web3 Sybil protection systems covers the wider fleet problem.

Funding Evidence and Privacy

Funding checks raise a fair question about privacy. Public blockchains already expose every transaction, so reading a feeder reveals nothing that the ledger did not already show. Still, teams should use the evidence with care.

What the Check Does and Does Not Reveal

A feeder check reads public, pseudonymous data. It does not identify a person. Moreover, it tells a counterparty that one address funded another, and it classifies the source by label and behavior. Nobody learns a name, a country or a bank account from the check.

The signal also respects legitimate privacy choices. Many honest users move funds through bridges, new wallets or privacy-conscious routes. For that reason, an unknown feeder leads to limits and monitoring, not to a verdict. The policy treats opacity as a reason for caution, and it leaves room for operators to earn trust through behavior.

Fairness and Appeal

A fair system explains its decisions and lets operators respond. Teams that use funding evidence should log the flags behind each decision, share the reasons with operators on request and offer a path to a better tier. These practices protect operators from opaque rejections, and they protect the protocol from disputes. They also keep the trust layer honest, because a system that must explain itself has to rest on evidence.

Funding Across Chains

Agents and operators do not stay on one chain. An operator may fund an owner wallet on Ethereum, register agents on Base and move value through BNB Smart Chain. ChainAware’s scoring covers Ethereum, BNB Smart Chain, Base and Avalanche C-Chain today, with Mantle in progress.

Cross-chain activity complicates funding traces. A bridge can break the visible link between a source and a destination. Some bridges publish enough data to reconnect the two sides, while others do not. As a result, traces that cross bridges often end in the unknown category. The unknown-feeder share of 12.84% in Week 41 partly reflects this difficulty, though other causes also play a role.

Counterparties can respond in three ways. They can prefer agents whose funding chain stays on a single traceable path. Furthermore, they can apply extra limits when the chain crosses several bridges. And they can ask operators to document cross-chain structure when the stakes are high. As more chains adopt ERC-8004, cross-chain funding evidence will matter more.

Funding Evidence vs Transaction Monitoring

Teams that already run transaction monitoring sometimes ask whether funding checks duplicate it. They do not. The two controls look at different moments and different questions.

Transaction monitoring watches what an account does after onboarding. It flags unusual amounts, speeds and counterparties. Likewise, it works well on accounts with enough history to define normal behavior. New accounts give it little to work with.

Funding checks judge the operator before the first action. They ask where the money came from and who else it funded. Beyond that, they work from day one, because the first funding transaction already exists. However, they say little about what the agent does later.

A strong program runs both. Funding evidence sets the starting limit and the level of scrutiny. Monitoring then adjusts the limit as behavior accumulates. When monitoring finds something odd, the funding record helps analysts decide whether the agent is an honest outlier or part of a coordinated group.

A Short Glossary of Funding-Chain Terms

• Feeder wallet: the address that first funded an owner wallet.
• Owner wallet: the address that controls an agent’s identity token.
• Funding chain: the sequence of addresses that carried funds from an original source to an owner wallet.
• Hop: one transfer step in a funding chain.
• CEX-verified feeder: a feeder that belongs to a verified centralized exchange.
• Unknown feeder: a feeder whose source could not be traced to a known entity.
• Rug pull history: a record that an address took part in abandoning a project after taking investor funds.
• Sybil farm: a group of wallets or agents that one operator controls while presenting them as independent.
• Fleet: a set of agents that share an operator, a funding source or both.
• Hard suppression: a rule that caps a score regardless of other signals.
• Source of funds: the origin of the money in an account, a standard question in anti-money-laundering practice.

What Good Funding Analysis Looks Like

Not every funding check deserves the same confidence. Teams that evaluate tools, or build their own, can use a short standard to judge quality.

Transparent Evidence

A good analysis shows its reasoning. It names the feeder, states how it classified the source and lists the flags that followed. Auditors and operators can then check the claim. A system that outputs a bare number invites distrust, since nobody can see why the number came out as it did.

Honest Coverage

A good analysis states how often it can trace a feeder. ChainAware reports that a feeder was traced for about 38% of indexed agents, and that figure belongs next to every claim about funding. Honest coverage numbers let teams decide how much weight to put on the signal.

Sensible Defaults

A good analysis treats missing data as missing, not as guilt. It separates the unknown category from the fraud-linked category, and it lets policy handle each differently. A blunt rule that rejects everything unknown will reject honest operators and push them to competitors.

Fleet Awareness

A good analysis looks across agents as well as at them. Moreover, a single agent with a clean feeder may still belong to a fleet of forty. Fleet-aware tools compare feeders, registration times and ownership clusters, and they report the group, not just the member.

Regular Refresh

A good analysis updates. Furthermore, a funding record that was true at registration may look different after months of new transfers. Scheduled refresh keeps scores honest, and event-driven re-checks catch ownership changes and unusual top-ups.

Fit With Existing Controls

A good analysis plugs into the controls that teams already run. It returns structured output for automated flows, it produces readable evidence for human reviewers and it logs every decision. Teams that follow these five principles will get more from any funding signal, whether they use ChainAware’s score or another source.

Putting the Standard to Work

Teams can turn these principles into a short review checklist. Ask the provider which sources it uses to label feeders and how often those labels update. In addition, ask how it handles bridges and mixers, and what share of agents it can trace. Ask whether it detects fleets, and whether it reports each decision in words that an auditor can read.

A provider that answers these questions openly deserves a pilot. However, a provider that avoids them has not earned trust. The same standard applies to ChainAware’s own score, which is why the limits section of this article lists the gaps in plain terms. Funding evidence is powerful because it rests on public data, and it stays powerful only when its users read the evidence critically and keep their own judgment in the loop.

The post Funding-Chain Risk for AI Agents: Why the Feeder Wallet Is the First Thing to Check first appeared on ChainAware.ai.

ERC-8004 gave AI agents a shared on-chain identity, and that is a real step forward. It is not a trust verdict. This guide explains what the standard records, which signals it leaves out, and how independent evidence about wallets, funding chains and fleets fills the gap. It draws on the public specification and on ChainAware’s weekly tracker of registered agents.

When a standard goes live, people often read more into it than it says. ERC-8004 is a good example. Its name includes the word “trustless,” and its registries carry words such as reputation and validation. As a result, many readers assume that a registered agent has passed some kind of check. In fact, registration is open, cheap and unvetted. An agent that appears in the registry exists. Beyond that, the registry says very little about whether the agent deserves access to money.

That distinction matters because agents now touch real value. They manage positions, settle payments and call other agents. Therefore, every protocol, marketplace and payment team needs a way to decide which registered agents to trust, and how far. The decision needs evidence, and the evidence lives mostly outside the registry.

This article walks through the standard in plain language, then lists the trust signals that surround it. It uses public data throughout: the specification itself, ChainAware’s launch analysis of 274,792 indexed agents and the weekly Agent Trust Tracker. Finally, the article keeps a clear view of limits, because every signal has blind spots.

What ERC-8004 Is

ERC-8004 is an Ethereum standard titled Trustless Agents. Its stated purpose is to discover agents and establish trust through reputation and validation. The specification on the Ethereum EIP site credits Marco De Rossi, Davide Crapis, Jordan Ellis and Erik Reppel as authors, and it builds on four existing standards: EIP-155, EIP-712, ERC-721 and ERC-1271. At the time of writing, the EIP site lists the standard as a Draft. ChainAware tracks live agents on Ethereum mainnet, where the registries went live in January 2026, and on additional EVM chains.

The standard defines three lightweight registries.

• An identity registry gives each agent a portable, globally unique on-chain identity.
• A reputation registry lets clients post feedback about an agent.
• The validation registry lets an agent’s owner request independent checks of the agent’s work.

Minimalism drives the design. The registries store small, standard records and leave heavy logic to other layers. In addition, the standard describes trust models as pluggable and tiered. Depending on the value at risk, a system can lean on reputation, on stake-secured re-execution, on zero-knowledge proofs or on trusted execution environments.

Why the Standard Exists

Before ERC-8004, agents from different platforms had no shared way to introduce themselves. One framework might name an agent one way, and a second framework would use another name. Discovery was hard, and trust signals could not travel with the agent. The standard attacks that problem by giving agents a common identity format and a common place to publish feedback.

This is useful for the whole ecosystem. A developer can register an agent once and let any compatible client find it. Likewise, a buyer can look up an agent in a shared registry. Meanwhile, researchers gain a public dataset to study. Without ERC-8004, a project like ChainAware’s tracker would have nothing to index.

Anatomy of an ERC-8004 Registration

The identity registry builds on ERC-721, the standard for non-fungible tokens. Each agent becomes an NFT. The agent’s identifier is the token identifier, and the token’s URI points to a registration file. Globally, an agent is identified by a combination of a namespace, a chain identifier, the registry address and the agent identifier.

The table below shows the main fields and how much trust each one can carry.

A pattern emerges from the table. Fields that the operator writes freely carry little trust. In contrast, fields that connect to on-chain history carry more. A good scoring approach therefore concentrates on the owner address and the agent wallet, and on what surrounds them.

The Registration File

The registration file is a JSON document, and it can live on IPFS, on an HTTPS endpoint or inside a data URI. It lists the agent’s name, description and image. Beyond that, it lists the services the agent offers, such as web endpoints or other agent protocols, and it can name the trust models the agent supports.

The file works like a business card. It tells others how to reach the agent and what the agent claims to do. However, it carries no proof of the claims. An owner can describe a sophisticated trading engine in the file and deploy a trivial script. The standard itself acknowledges this limit and notes that it cannot cryptographically guarantee that advertised capabilities are functional and non-malicious.

The Agent Wallet

Separately, the standard reserves an agent wallet field. It starts as the owner’s address. Changing it requires a signature from the new wallet, using EIP-712 for ordinary accounts and ERC-1271 for smart contract wallets. The field clears when the token transfers and must be verified again.

This rule is a sensible protection against hijacked metadata. For risk analysis, it also creates a useful anchor: the agent wallet is a verified address that a counterparty can inspect. Its history, funding and activity become evidence.

The Optional Trust Field

The registration file can include a list of supported trust models. This field is optional. When it is absent or empty, the specification says the standard serves discovery only and makes no claim about trust. This detail matters, because many registered agents leave the field empty. For them, the registry gives an address and a description, and nothing more.

The Reputation Registry in Detail

The reputation registry is the part of ERC-8004 that most people mean when they say “agent reputation.” It lets a client submit feedback about an agent, and it stores a compact record on-chain.

How Feedback Works

A client calls a function to give feedback. Each entry stores a signed value with a number of decimals, two optional tags and a flag that shows whether the client later revoked the entry. Other data, such as an endpoint reference, a feedback file link and a hash of that file, appears in emitted events and stays off-chain storage. A client can revoke its own feedback, and anyone can append a response, for example to flag spam or to show a refund.

The registry can also return an on-chain summary. To limit spam, the summary function requires the caller to name the client addresses whose feedback should count. The specification expects more complex aggregation to happen off-chain.

One rule protects against the most obvious abuse. The specification forbids the agent’s owner or an approved operator from submitting feedback for that agent. A developer cannot simply rate their own agent from the owner address.

Why the Rule Is Not Enough

The rule closes the front door and leaves the side door open. An operator who controls several wallets can post feedback from wallets that are not the owner or an approved operator. The contract cannot know that those wallets share a controller. Yet the specification admits the risk directly: Sybil attacks are possible and can inflate the reputation of fake agents. It expects reputation systems to filter by reviewer.

Consider a simple case. One operator controls twenty wallets and twenty agents. Each wallet posts a positive review for several agents it does not own. The registry now shows agents with long lists of positive feedback, and nothing in the on-chain data marks the reviews as coordinated.

A defense must look at the reviewers, not the review count. Three questions help.

1. How old is the reviewing wallet, and does it have unrelated activity?
2. Who funded the reviewing wallet, and does the same source fund the agent’s owner?
3. Does the reviewer post for many agents from one operator and nobody else?

Reviewers with real history, independent funding and a record of unrelated activity carry weight. In contrast, reviewers created last week and funded by the owner’s own feeder carry almost none. This is the same fleet logic that drives farm detection, applied to feedback.

What Good Reputation Weighting Looks Like

A sound weighting step has four parts. It discounts feedback from wallets that share a feeder with the agent’s owner. Likewise, newly created wallets receive a discount. Third, it favors reviewers that have also paid or transacted with the agent, since economic activity is harder to fake than a rating. Finally, it reports confidence alongside the score, so that a thin record looks thin.

Protocols that rely on registry feedback alone should add at least a simple version of this step. Otherwise, they measure the operator’s effort, not the agent’s quality.

The Validation Registry and Pluggable Trust

The validation registry takes a different route. It lets an agent’s owner or operator request an independent check, and it lets a designated validator answer. The request carries a reference and a hash. Then the validator responds with a number from 0 to 100, and it can respond more than once, for example to show progress from a soft to a hard confirmation.

Incentives and slashing stay out of scope in the specification. Specific validation protocols supply those. The standard names several trust models that such protocols can use:

• Reputation-based trust, where clients vouch for the agent.
• Stake-secured re-execution, where validators re-run the work and risk a deposit if they approve bad results.
• Zero-knowledge machine learning proofs, where the agent proves that a computation ran correctly.
• Trusted execution environment oracles, where hardware attests to the code that ran.

These models give the standard a route toward real cryptographic assurance. In practice, they are still maturing. Most agents today rely on reputation-style signals or on third-party scoring. Therefore, the practical question for most teams is how to read signals around the registry, not how to wait for perfect validation.

What the Registry Can and Cannot Tell You

With the three registries in view, the boundaries become clear.

What the Registry Tells You Reliably

• Existence. Does this agent have a valid registration?
• Ownership. Which wallet owns the identity token?
• Agent wallet. What address links to the agent?
• Description. Where does the registration file say the agent does, and where does it run?
• Feedback history. Which reports have other addresses posted, and when?
• Validation history. Validator responses, with the result of each.

These facts are valuable. They let a counterparty find an agent, address it and refer to it consistently.

What the Registry Cannot Tell You

• Whether registration was vetted. No one reviews a registration before it goes live.
• Whether the claims are true. The registration file is self-described.
• Whether feedback is independent. Reviewers can share a controller.
• Whether the owner has a bad record. The registry shows who owns the token. It does not show that wallet’s history.
• Where the money came from. Funding sits outside the record.
• Whether the agent is one of many. Each registration stands alone, so fleets stay invisible.

The Gap, Summarized

The registry gives structure. A scoring layer supplies judgment. Judgment cannot live inside an open registry, because the registry would need to decide whom to believe, and in doing so it would become a gatekeeper. Keeping the registry neutral and letting independent scorers compete is the healthier design. Our guide to KYA versus agent identity explains how this split fits into a wider Know Your Agent process.

The Trust Signals That Surround the Registry

Independent scoring supplies the missing signals. ChainAware’s Agent Trust Score reads three core groups of evidence, then adds a fleet view. Each group fills one of the gaps listed above.

Signal 1: The Owner Wallet’s Fraud Probability

The owner wallet is the most direct link to a real party. ChainAware’s behavioral models estimate a fraud probability for the wallet from its on-chain history. A wallet that behaves like previous fraud accounts raises risk even when nobody has reported it. This matters because new attack wallets appear constantly, and a blacklist can only name those that someone already caught. The article on forensic versus AI-based crypto analytics explains the difference.

For a deeper look at a suspicious owner, teams can run the wallet through ChainAware Investigation. It returns a seven-section report in about a minute, covering identity, activity, counterparties, risk, circular flows and AML exposure.

Signal 2: The Feeder Address

The feeder is the address that funded the owner wallet. It is one of the most informative signals available, and the one that operators find hardest to fake. The reasoning is simple. An operator can write any registration file. It cannot rewrite who sent its first funds.

The feeder falls along a spectrum.

ChainAware traced a feeder for roughly 38% of indexed agents, so the signal is missing for many. When it is present, it carries weight. At launch, only 1.0% of agents had a verified-exchange feeder, while 9.5% had an unknown feeder and 0.3% had a feeder with rug pull history. A further 741 agents had been funded by confirmed rug pull operators.

Signal 3: The Creator’s Record

The creator’s wallet history carries forward. Past rug pulls and honeypot deployments are strong negatives. Bad actors rarely stop after one attempt, and a creator that funds a fresh owner wallet passes along a shadow of its history. The launch analysis flagged creator rug pull history for 0.02% of agents and creator honeypot history for only a handful of agents. These flags are rare, yet they are decisive when present.

Signal 4: Fleet-Level Farm Detection

Fleet detection compares agents with one another. It looks at shared funding, registration timing and clustered ownership to find groups that one operator probably controls. At launch, 21.1% of indexed agents carried the farm flag. Later tracker weeks put the share between roughly 16% and 19%. These figures show that coordinated operators account for a large part of the registry.

Signal 5: Delegation and Account Type

EIP-7702 lets an ordinary account delegate execution to contract code. The EIP7702_DELEGATED flag marks owner accounts that do. Delegation has legitimate uses, such as batching and gas sponsorship, so the flag is not a verdict. Nevertheless, it changes how an account behaves and deserves a second look, especially when it appears next to an unknown feeder. The Week 40 tracker showed delegation up 33.8% since Week 35, as the Week 40 report describes.

From Signals to a Score: How the Agent Trust Score Works

In turn, the score turns these signals into one number between 0 and 1,000, a tier and a set of flags. Three pillars drive it: the owner wallet’s fraud probability, the feeder address and the creator’s criminal record. Fleet-level detection adds the last layer. A fraud-history feeder hard-suppresses the score, whatever the other pillars show. By contrast, a verified-exchange feeder lifts it, although only when the rest of the evidence agrees.

The five tiers map to access decisions.

Coverage includes Ethereum, BNB Smart Chain, Base and Avalanche C-Chain, and Mantle support is in progress. The free tier allows 1,000 queries per month with no signup. Larger teams can use the fraud detection API, and agents can call the same intelligence through the Prediction MCP. The launch article explains the model and the first registry analysis in full.

Why a Score and Flags Together

A score alone hides the reasons. Flags alone give no ranking. Together, they let a team set a policy by tier and explain each decision by flag. For example, a protocol can require Sovereign tier for vault access and also reject any agent with a farm flag. When a protocol declines an agent, it can name the flags that drove the decision. That record protects the protocol and gives the operator a path to improve.

What the Data Shows About the Registry

A trust layer is only useful if it finds real differences between agents. The public numbers show that it does.

The Launch Analysis

At launch, ChainAware’s analysis covered 274,792 indexed agents. The tier split showed a polarized population.

Together, 51.8% of agents sat in the two lowest tiers. At the same time, one in five agents (21.1%) carried the farm flag. The distribution has two peaks, a large group at the top and a larger group at the bottom, with fewer agents in the middle. Meanwhile, the Week 29 tracker saw the same shape across 317,589 agents, where 27.5% were Untrusted and 21.3% were Sovereign, as the Week 29 report shows.

A Timeline From the Weekly Tracker

A weekly view adds a time dimension. Figures in the list come from the published posts.

What the Timeline Teaches

Three lessons stand out.

First, volume and quality move independently. Week 34 set the registration record, while Week 41 set the trust low. A dashboard that celebrates registration growth says nothing about whether the new agents deserve access.

Second, concentration shows up as a ratio. When registrations hold up while unique owners fall, a few operators drive the growth. Week 31 and Week 38 both followed that pattern, and both showed a median trust of 200. The Week 31 report and the Week 32 report explain how concentration and farm flags connect.

Third, funding is getting harder to trace. In Week 41, the share of agents with an unknown feeder nearly doubled to 12.84%. A weaker funding signal makes the other pillars matter more, and it raises the value of fleet detection.

The Week 36 report also shows that records cut both ways. A record-high median in one week fell back within seven days, which shows how much a single large operator can move the figure.

How to Read Trust Signals: A Practical Checklist

Use the list below when you assess any ERC-8004 agent. The order moves from validity to risk.

1. Confirm the registration. Check that the agent is registered, that the owner wallet is clear and that the registration file resolves.
2. Compare the tier. Sovereign and Trusted agents justify more access than Elevated Risk or Untrusted agents.
3. Read the flags. A farm flag or a fraud-history feeder flag overrides a polished registration file.
4. Look at the feeder. A verified-exchange feeder is positive. An unknown feeder calls for limits.
5. Check the delegation flag. EIP-7702 delegation is not bad by itself, yet it deserves a closer look next to other warning signs.
6. Treat feedback counts with care. Look at who posted the feedback, not how much there is.
7. Search for validation records. A credible validator’s response carries more weight than a pile of ratings.
8. Re-check later. Scores change as behavior changes, so schedule the next look.

Step by Step: A One-Minute Lookup

A lookup takes about a minute and needs no signup.

1. Open the Agent Trust Score tool and enter the agent or its owner address.
2. Read the tier and score first, since they give the headline.
3. Scan the flags, because they explain the score.
4. Compare the tier with the access you plan to grant.
5. For automated flows, call the same data through the API or the MCP instead of the page.

When the score raises a concern, open a deeper review. The article on wallet forensics and AML reports shows how analysts use Investigation for that step.

A Worked Example: Reading Two Registrations

This example is illustrative. Both agents and numbers are invented to show the method, and they do not describe real registrations.

Two agents ask a lending protocol for vault access. Both appear in the ERC-8004 registry, and both have polished registration files with clear service descriptions. Each shows dozens of positive feedback entries.

The protocol starts with the owner wallets. Agent A’s owner wallet is two years old, funded by a verified exchange, and active in unrelated protocols. Meanwhile, Agent B’s owner wallet is three weeks old. An unlabeled address funded it, and that address funded eleven other owner wallets in the same hour.

Next, the protocol looks at the feedback. Agent A’s reviewers include old wallets with independent funding and real transaction history. In contrast, Agent B’s reviewers are mostly new wallets funded by the same unlabeled address that funded the owner.

The scores follow. Agent A lands in the Trusted or Sovereign range and receives the vault access it requested. In contrast, Agent B carries a farm flag and an unknown-feeder flag, so it lands in Elevated Risk. The protocol declines the request and stores the flags as the reason.

Nothing in the registry separated the two agents. The registration files looked equally professional, and both showed positive feedback. Instead, the difference sat in the wallets behind them.

Why Funding Evidence Resists Manipulation

Of all the signals around ERC-8004, funding evidence deserves a closer look, because it behaves differently from the others. A registration file is free text. Feedback can come from many wallets. Funding, by contrast, leaves a record that the operator cannot edit after the fact.

Three properties make funding evidence hard to game.

Cost. Obtaining funds from a verified exchange requires passing that exchange’s checks. Operators who want the strongest positive signal must therefore pay in time, identity and compliance effort. By contrast, operators who skip the effort end up with an unknown or untraceable feeder.

Linkage. Farms need many wallets, and many wallets need funding. Operators usually draw that funding from a small set of sources, because splitting every top-up across unrelated origins costs effort. Shared feeders therefore expose fleets, even when each owner wallet looks independent.

Permanence. The first funding transaction of a wallet stays on the chain forever. An operator can change its registration file tomorrow. It cannot change who sent the first funds yesterday.

The Limits of Funding Evidence

None of this makes funding evidence perfect. A determined operator can route money through several hops, or it can fund wallets through exchange accounts that pass basic checks. Heavy obfuscation tends to push the feeder into the unknown category, which carries its own penalty. Still, a score that relies on funding alone would miss operators who use clean sources. For that reason, the Agent Trust Score combines the feeder with the owner wallet’s fraud probability, the creator’s record and fleet-level detection.

How ERC-8004 Fits the Wider Agent Standards Landscape

ERC-8004 does not stand alone. Several other efforts address parts of the same problem, and each one covers a different layer. Understanding the landscape helps teams combine the pieces.

Identity and KYA Frameworks

Trulioo describes Know Your Agent as an identity layer built around a Digital Agent Passport, a tamper-proof token that carries an agent’s origin, legitimacy, authorization and user consent. Its explanation of KYA frames the idea in payments terms. Baselayer raised a $35 million Series A to extend its verification tools to agents, according to coverage of the round. These frameworks mainly answer who is behind an agent.

Payment Protocols

Payment protocols address authorization and transport. Google’s Agent Payments Protocol, known as AP2, uses verifiable credentials and signed mandates to record what a user asked for and approved. Its announcement describes it as an extension of existing agent communication standards. OpenAI and Stripe launched the Agentic Commerce Protocol, which lets an agent pay through a shared payment token, as Payments Journal reported. These protocols mainly answer what the agent may do and how it pays.

Where ERC-8004 Sits

ERC-8004 sits between the two. It gives agents a public identity and a shared place for feedback and validation, and it does so on open infrastructure. Unlike closed credential systems, it exposes every registration to any observer. That openness is the reason a project like ChainAware’s tracker can measure the whole registry.

Where Behavioral Evidence Fits

None of these layers measure how an operator behaves with money. A passport proves origin. Meanwhile, a mandate proves permission. Likewise, a registry entry proves existence. Behavioral evidence adds the missing question: how risky is this operator? A commentary on the liability picture in agentic commerce notes that traditional behavioral signals such as device and typing patterns disappear when software buys on a user’s behalf. That deep dive is opinion, not settled rule, yet the underlying point holds. When human signals vanish, risk teams need new signals that describe the agent and its operator.

A Closer Look at Fleet Detection

Fleet detection deserves its own section, because it catches what no single-agent check can see. A single agent can look healthy while hundreds of siblings sit behind it. Detecting the group requires comparing agents with one another.

Signals That Suggest a Fleet

Several signals point to a shared operator.

• Shared feeders. Many owner wallets funded by the same source.
• Registration timing. Dozens of agents registered within the same short window.
• Template metadata. Near-identical registration files with only names changed.
• Clustered ownership. Many agents controlled by few owner wallets.
• Reviewer overlap. The same small group of wallets posting feedback across many agents.

No single signal proves a farm. Legitimate teams also register agents in batches and reuse templates. The combination, however, is hard to explain innocently, and that is where detection earns its value.

What to Do With a Fleet Flag

A farm flag should change how a counterparty treats the whole group. Three responses work well.

1. Treat linked agents as one risk unit. Aggregate limits across the group.
2. Apply the weakest tier in the group to all members, until the operator proves independence.
3. Review the operator, not just the individual agent.

These responses prevent a common trick. Operators split a large request across many agents so that each request looks small. Aggregation at the operator level closes that loophole.

Designing an Access Policy by Tier and Flag

Policy turns scores into rules. A good policy combines tiers with flag overrides. The example below is a starting point, and each team should adjust it to its own risk appetite.

Rules like these have three advantages. They are easy to explain to auditors, they are easy to automate and they give operators a clear target. A short rollout plan helps teams adopt them.

1. Week 1: inventory. List every place where an agent can touch money or permissions, and rank each place by value at risk.
2. Week 2: observe. Look up the counterparties you already see and record their tiers without blocking anyone.
3. Week 3: write policy. Define one rule per access level.
4. Week 4: enforce and re-check. Turn the rules on for new agents, add a scheduled re-score and review exceptions weekly.

The plan needs no heavy integration. It needs a clear owner and the discipline to write the policy down.

Four Fraud Patterns That the Registry Alone Cannot Show

Reading the weekly data in order reveals patterns that single reports hide. Each pattern exploits the open design of the registry, and each one calls for a different defense.

Pattern 1: Concentration Bursts

A concentration burst appears when registrations rise or hold steady while the number of unique owners falls. Therefore, a few operators account for the growth. Week 31 is the clearest case. Registrations dropped only 7.0% to 21,378, yet unique owners collapsed 58.7% to 8,413. Agents per owner more than doubled to 2.54, and median trust fell 33.1% to 200.

Week 38 repeated the shape. Registrations rebounded 74.5% to 17,001, owners grew only 10.2% to 7,405, and agents per owner reached 2.30. Median trust again dropped to 200.

Week 30 offers the contrast. Registrations more than doubled to 22,989, and owners grew almost as fast, up 96.9%. That is broad-based growth, and it carried no concentration signature. Trust was still low, with a median of 299, but the pattern differed.

Defense: Watch the agents-per-owner ratio. Aggregate limits by owner and by feeder, so that one operator cannot multiply its access across many agents.

Pattern 2: Farms That Stay Large

Farm detection flagged 21.1% of agents at launch. Later weeks showed 18.73% in Week 32, 18.39% in Week 33, 17.05% in Week 34 and 16.12% in Week 40. The share eased as the population grew, but the absolute number of flagged agents did not shrink. On an index of 568,590 agents, even 16% is a large group.

Farms matter for three reasons. They inflate registry counts. Next, they manufacture reputation by reviewing one another. And they position operators to claim incentives or access that was meant for many independent parties.

Defense: Never read an agent count as a count of independent participants. Ask how many operators stand behind it, and treat linked agents as one risk unit.

Pattern 3: Funding That Gets Harder to Trace

The unknown-feeder share stood at 9.5% at launch. By Week 41, it had nearly doubled to 12.84%. The feeder is the hardest signal to fake, and an untraceable feeder weakens it. Operators who want to hide their funding can add hops, yet each hop leaves a trace, and heavy obfuscation tends to push the feeder into the unknown category, which carries its own penalty.

Defense: Raise review thresholds when the unknown-feeder share rises. Cap value for unknown-feeder agents instead of blocking them outright, since some privacy-minded operators are legitimate.

Pattern 4: Delegation Growth

EIP-7702 delegation rose 33.8% between Week 35 and Week 40. Delegation lets an ordinary account hand execution to contract code. It brings real benefits, such as batching transactions and sponsoring gas. Yet it changes how an account behaves, since the account can now do more than a simple key pair.

Defense: Treat delegation as a prompt to look closer, not as a verdict. Review delegated accounts before granting permissions that matter.

How the Patterns Reinforce Each Other

The four patterns feed one another. Concentration bursts bring more farm-flagged agents. Farms prefer opaque funding. Opaque funding lowers trust scores. Lower scores pull down the weekly median. A single operator-driven registration wave can produce all four signs in one week. This is why a score should combine several pillars instead of relying on one.

What Fraud Looks Like in an Open Registry

It helps to name what these patterns make possible. The tracker cannot prove intent in any single case. It shows distributions, and the distributions show where risk concentrates.

• Reputation farming. Operator-controlled wallets review one another’s agents to look established.
• Incentive capture. Many agents from one operator claim programs built for independent users.
• Disposable agents. An operator creates agents, uses them for a harvesting action and abandons them. The creator’s record then moves to a new wallet.
• Laundered credibility. A creator with a bad record funds a clean-looking owner wallet.
• Counterparty exposure. Honest platforms integrate a farm agent and take on its risk.
• Misleading claims. An agent describes sophisticated capabilities in its registration file and delivers nothing of the kind.

The study discussed in our article on how investors should evaluate AI trading agents supports the last point. A May 2026 paper from researchers affiliated with Pantera Capital, Stanford, IC3 and Ava Labs examined more than 1,900 AI-tagged crypto projects and found that even agents with fully public wallets could not always be verified as autonomous. Claims in a card or a whitepaper need evidence behind them.

Who Benefits From Reading These Signals

Different teams meet registered agents in different places. Each one can act on the signals in a specific way.

DeFi Protocols and DAOs

Protocols can set tier thresholds for vault, lending and treasury access. They can also reject any agent with a farm flag or a fraud-history feeder, whatever its tier. The guide to Web3 trust verification systems maps the five categories of trust problems, and agent access touches several of them.

Agent Marketplaces and Registries

Marketplaces can rank listings by trust and show flags next to each one. Ranking by star rating or registration age rewards the easiest metrics to manufacture. A visible tier and flag set rewards operators that keep a clean, traceable record.

Payment and Fintech Teams

Where settlement runs on-chain or through stablecoins, wallet-level trust becomes a direct input to risk rules. The tier can set limits, and the flags can trigger review. Payment teams also face a wider problem, since agents remove the human signals that fraud models rely on. Behavioral evidence about the operator restores part of that signal.

Investors and Strategic Partners

Investors should ask any agent project to show its funding chain and fleet structure. A project that cannot, or will not, has told you something. The data also gives investors a market view. A registry with more than half a million entries and a record-low median trust is a market that needs a trust layer.

AI Agent Developers

Developers who build agents can use the score for two purposes. They can check counterparties before they pay or call another agent. Alternatively, they can monitor their own agents’ standing and fix problems early. Agents can call the score through the Prediction MCP, which turns trust checking into a machine-to-machine step. ChainAware’s own fleet works this way, as the overview of the 32 Claude sub-agents shows.

Compliance and Security Teams

Compliance teams already ask where money came from and who stands behind an account. The feeder check applies that familiar question to agents. For regulated teams, autonomous compliance screening shows how agents and screening fit together.

How Operators Can Improve Their Standing

A trust layer should reward good behavior. Operators who want better tiers can take clear steps.

• Fund owner wallets from a verified exchange account.
• Avoid sharing one funding source across many unrelated owner wallets.
• Keep owner wallets active and consistent over time.
• Separate treasury, operating and test wallets, and document their roles.
• Avoid funding from addresses with fraud-linked history.
• Seek feedback from independent, established clients.
• Request validation from credible validators when the use case justifies it.

None of these steps is a trick. They are signs of an operator with a traceable, stable record, which is exactly what a counterparty wants to see.

Mistakes to Avoid When Using Registry Data

Teams repeat a handful of mistakes. Avoiding them saves time and losses.

• Counting reviews as trust. The volume of feedback is easy to manufacture, so read the reviewers.
• Believing the registration file. It is a claim, not a proof.
• Ignoring the owner. The agent can be new while its owner has a long record, or the reverse.
• Checking once. Fleets, owners and funding evolve.
• Treating the registry as a whitelist. A registered agent is only a known agent.
• Blocking every unusual signal. An unknown feeder or a delegated account calls for limits and review, not automatic rejection.
• Using one threshold for everything. A low-value task and a treasury permission deserve different tiers.

Implementation Notes for Developers

Developers who add registry signals to a product face a few design choices. The notes below describe the patterns that work best.

Keep the layers separate in code. Store registry facts, such as identity and feedback, apart from scores and flags. Registry facts change on-chain events. Scores change as behavior changes, so they need different refresh schedules.

Cache with care. A score from last month may no longer apply. Choose a time to live that matches the value at risk, and force a fresh lookup before large actions.

Log every decision. Record the tier, the flags, the policy rule that fired and the time of the lookup. Compliance teams and operators will ask why an agent was declined, and the log answers in seconds.

Fail safe. If a lookup fails, fall back to a low-limit policy instead of full access.

Handle partial data. A feeder was traced for about 38% of agents, so many lookups will show no funding evidence. Treat missing data as a reason for caution at high value, and as normal at low value.

Expose a path to appeal. Operators who improve their history should be able to earn a better tier. A trust layer that cannot change its mind becomes a blacklist.

Calling the Score From an Agent

Agents can query the score themselves. Through the Prediction MCP, an agent can look up a counterparty before it pays or delegates work. The decision logic stays simple, because the output has a fixed structure. For example, an agent can proceed automatically with Sovereign counterparties, ask for confirmation with Provisional ones and decline Untrusted ones. The article on the Prediction MCP for AI agents explains the wider design, and the guide to blockchain data providers for AI agents maps the data sources that agents can use.

Metrics That Show Whether the Signals Work

A trust process deserves measurement. Teams can track a short list of indicators and tune thresholds with data.

• Approval rate by tier. Higher tiers should show higher approval rates.
• Loss and dispute rate by tier. Lower tiers should account for more incidents. If they do not, the thresholds need work.
• Farm-flag share. A rising share signals growing operator concentration.
• Unknown-feeder share. Growth here weakens the funding signal.
• Re-check coverage. The percentage of active agents scored within the chosen time window.
• Overrides. Every manual override needs a reason, and a pattern of overrides points to a policy gap.

Leadership benefits from these numbers too. They turn a vague promise of agent security into a visible control with measurable results.

A Short Glossary of ERC-8004 Trust Terms

The glossary below defines the terms used in this article.

• ERC-8004: an Ethereum standard for agent discovery and trust, built around identity, reputation and validation registries.
• Identity registry: the registry that mints an ERC-721 token for each agent and points to its registration file.
• Registration file: a JSON document with the agent’s name, description, endpoints and supported trust models.
• Agent wallet: the address linked to the agent, which starts as the owner’s address.
• Reputation registry: the registry where clients post feedback about an agent.
• Validation registry: the registry where validators answer an owner’s request to check an agent’s work.
• Sybil attack: the use of many fake identities by one party to gain influence or rewards.
• Feeder wallet: the address that first funded the owner wallet.
• Farm-detected: a flag for agents that appear to belong to one operator’s fleet.
• EIP-7702: an Ethereum upgrade that lets an ordinary account delegate execution to contract code.
• Agent Trust Score: ChainAware’s 0 to 1,000 rating for ERC-8004 agents, with five tiers and named flags.

Limits of the Signals

Honest use of any signal needs a clear view of its limits. The list below applies to ChainAware’s score and to any similar system.

• Coverage is partial. ChainAware traced a feeder for about 38% of indexed agents, so the funding signal is missing for many.
• A clean feeder is not a clean agent. Bad actors can use exchange accounts, so combine the pillars.
• An unknown feeder is not proof of fraud. Privacy-minded users and bridge routes also hide origins.
• Flags describe risk patterns. They are not proof of wrongdoing, and they justify limits and review, not automatic judgment.
• Scores reflect the evidence available at the time. Behavior changes, so scores change.
• The tracker covers indexed agents. It does not cover every agent everywhere, and weekly medians can swing when one large operator dominates a week.
• On-chain scoring covers on-chain agents. Agents that never touch a public chain need their own behavioral sources.

These limits explain why the score combines several pillars and why teams should pair it with identity checks, authorization records and their own policy.

How ERC-8004 and a Trust Score Divide the Work

The registry and the score do different jobs, and neither replaces the other.

First, the registry provides structure. It gives agents a common name, an owner and a place to publish a registration file, and it gives clients a place to post feedback. Standards like this make an ecosystem interoperable.

The scoring layer provides judgment. It turns open data into a rating that a protocol can act on. Different scorers can offer different methods, and buyers can compare them. Our overview of the agent trust infrastructure race maps how providers approach the problem. The important rule for buyers is to use a scorer that shows its evidence, so that the rating can be checked.

Overall, the split keeps the registry neutral. It also lets the market improve scoring methods without changing the standard. For readers who want the DeFi builder’s perspective, the article on why trust comes before integration walks through the first steps.

Where Agent Registries Are Heading

Several trends will shape the next stage.

Validation Will Mature

Stake-secured re-execution, zero-knowledge proofs and trusted execution environments promise cryptographic assurance. As validation protocols mature, high-value flows will lean on them. Reputation and scoring will still matter, since they cover the large set of agents that never request validation.

Registries Will Spread Across Chains

ChainAware already indexes agents on Ethereum, BNB Smart Chain, Base and Avalanche C-Chain, with Mantle in progress. As more chains adopt the standard, a counterparty will need cross-chain evidence about each operator. Funding chains and fleets do not respect chain boundaries, so scoring will need to follow them.

Machine-to-Machine Checks Will Grow

Agents will check each other before they transact. A human cannot sit in a loop that runs thousands of times a day. Therefore, trust checks need to be fast, structured and callable by software. The overview of the Web3 agentic economy explains why machine-readable trust becomes core infrastructure.

Evidence Will Beat Claims

As agent numbers grow, counterparties will stop trusting self-reported descriptions. They will favor evidence such as funding history, fleet structure and behavior over time. Public blockchains give this evidence a head start, because the data is open and the history is permanent.

Why Review-Based Rankings Fail

ERC-8004’s reputation registry lets clients publish feedback about agents. The specification forbids an owner or approved operator from reviewing their own agent, which blocks the simplest abuse. It cannot stop the next one. Review-based rankings share a basic weakness. Anyone can create 50 wallets, register 50 agents and let them upvote a 51st. That is a plain Sybil attack, and a score built on votes cannot see it. The example is an illustration, yet the tracker shows that such fleets are real: 21.1% of agents carried the farm flag at launch.

Consider how little the attack needs. A fleet of wallets submits friendly feedback, each wallet looks independent, and the registry records every entry as valid. In addition, a ranking that sums or averages that feedback rewards the fleet. Therefore, any ranking built on reviews inherits the weakness of cheap identities.

What Replaces the Votes

ChainAware takes a different route. The Agent Trust Score uses on-chain behavior only, with no reviews, no ratings and no self-reported data. Faking a clean funding history costs real money and time, while 50 upvotes cost almost nothing. Moreover, an attacker’s own address and feeder address pass through ChainAware’s machine-learning fraud detection, so abnormal behavior lowers the score instead of raising it.

Some on-chain data can still be faked, for example through wash activity or long-lived clean wallets. The difference lies in cost and in detection: every extra step leaves patterns that fraud models are trained to find. For that reason, behavior is a stronger base for trust than opinion.

Why ChainAware Is Credible Here

The fraud models behind the score have a long record. ChainAware reports 95% accuracy for its per-address fraud model, which anyone can verify against public data through ScamDB, and its rug pull model predicted 90.1% of rug pulls before they happened in a PancakeSwap test documented on the rug pull verification page. Those models feed the score, which is why it works as a prediction and not as a ranking.

Key Facts at a Glance

• ERC-8004 is an Ethereum standard for agent discovery and trust, with identity, reputation and validation registries.
• Registration is open and unvetted, so an agent’s existence says nothing about its trustworthiness.
• Owner self-review is blocked by the specification, yet the same document states that Sybil attacks remain possible.
• The standard says it cannot cryptographically guarantee that advertised capabilities are functional and non-malicious.
• ChainAware’s Agent Trust Score rates agents from 0 to 1,000 across five tiers, from Untrusted to Sovereign.
• The score combines the owner wallet’s fraud probability, the feeder address, the creator’s record and fleet-level farm detection.
• At launch, 51.8% of 274,792 indexed agents sat in the two lowest tiers, and 21.1% carried the farm flag.
• By Week 41 of 2026, the index held 568,590 agents, and the median trust of new registrations had fallen to 101.

Frequently Asked Questions

What is ERC-8004?

ERC-8004 is an Ethereum standard called Trustless Agents. It gives AI agents an on-chain identity through an ERC-721 token, and it adds a reputation registry for feedback and a validation registry for independent checks.

Does an ERC-8004 registration mean an agent is safe?

No. Registration is open and unvetted. It shows that an agent exists. The standard itself says it cannot cryptographically guarantee that an agent’s advertised capabilities are functional and non-malicious.

Can an agent’s owner review their own agent?

No, not directly. The specification forbids the owner and approved operators from submitting feedback for their own agent. However, an operator that controls other wallets can still post feedback from them. The specification acknowledges that Sybil attacks are possible, and it expects reputation systems to filter by reviewer.

What is a feeder wallet?

A feeder wallet is the address that first funded an agent’s owner wallet. Its history is evidence about the owner. A verified-exchange feeder is the strongest positive signal, an unknown feeder is a risk signal, and a feeder with fraud history hard-suppresses the score.

What is a farm-detected agent?

Farm-detected agents belong to a group whose funding, ownership or registration patterns suggest one operator controls them. At launch, 21.1% of indexed agents carried the flag.

What does the Agent Trust Score measure?

It measures the owner wallet’s fraud probability, the feeder address and the creator’s rug pull and honeypot history, then adds fleet-level farm detection. The result is a 0 to 1,000 score, a tier and named flags.

Which chains does the Agent Trust Score cover?

Coverage today includes Ethereum, BNB Smart Chain, Base and Avalanche C-Chain. Mantle support is in progress.

Is the Agent Trust Score free?

The score is free for public indexed agents, with 1,000 queries per month and no signup. Higher-volume teams can use the API or the Prediction MCP. See the Agent Trust Score page for current details.

How often should an agent be re-checked?

Check on a schedule that matches the value at risk, and check again before large or unusual actions. Behavior changes, so an old score is only a claim until someone verifies it again.

How does this relate to Know Your Agent?

Registry signals feed the behavior input of a wider KYA process, which also covers identity, authorization, integrity and status. Our guide to KYA versus agent identity explains the full picture.

Conclusion: Structure From the Registry, Judgment From Evidence

ERC-8004 solved a real problem. Agents now have a shared way to name themselves, publish what they offer and collect feedback. That is progress, and it gives the ecosystem something to measure.

The standard does not claim more than it delivers. It says plainly that it cannot guarantee that advertised capabilities work as described, and it admits that Sybil attacks are possible. Trust therefore has to come from evidence outside the registry: the owner’s history, the funding chain, the creator’s record and the fleet behind the agent.

The public data shows why this matters. A registry that grew past half a million agents in months also produced a record-low median trust score. Open systems scale volume easily, and they scale quality only when someone measures it.

Start small. Pick one agent integration that you already run, look up the counterparty’s score, and write down which tier you would allow for which action. That exercise produces a first policy. Then add the re-check and keep the evidence trail.

Readers who want to go further can review the Agent Trust Score, explore the Prediction MCP, or see how the Token Audit covers token-level risk that often sits next to agent risk. In addition, the weekly tracker shows how these signals move every week.

The post ERC-8004 Trust Signals: What the Registry Can and Cannot Tell You About an AI Agent first appeared on ChainAware.ai.

Agent identity and Know Your Agent sound like the same idea, yet they solve different problems. Identity tells a counterparty who stands behind an AI agent. KYA, short for Know Your Agent, decides whether that agent may act, and how far. This guide separates the two terms, shows where identity stops working, and explains which evidence completes the picture.

AI agents now pay invoices, buy API access, rebalance DeFi positions and manage treasuries. Each of those actions starts without a human clicking “confirm.” Therefore, every counterparty faces the same question: should this agent be allowed to move money? Vendors, standards bodies and payment networks have rushed to answer it. As a result, the vocabulary has grown crowded, and buyers often treat different products as if they were interchangeable.

That habit causes real design mistakes. A team that buys an identity product believes it has bought trust. In practice, it has bought one input to a trust decision. The gap between the two shows up later, usually after a loss. For that reason, this article draws a clear line between agent identity and Know Your Agent, and it uses public data from the ERC-8004 registry to show why the line matters.

The article is written for fraud and risk teams, fintech and DeFi builders, investors who back agent infrastructure, and AI agent developers. It uses plain language, public sources and ChainAware’s published research. Moreover, the article stays honest about limits, because a trust framework only helps when its users know what it cannot see.

Two Terms, One Common Confusion

The agent economy produced a long list of overlapping terms in a short time. Vendors talk about agent identity, agent credentials, agent passports, agent registries, agent authentication and Know Your Agent. Analysts add agent authorization and agent reputation. Buyers hear all of these in the same sales call, and many assume they describe one product category.

They do not. Each term answers a different question, and the questions stack in a clear order. Identity asks who or what the agent is. Authentication asks whether the party in front of you really holds that identity. Authorization asks what the agent may do. Reputation asks how the agent has behaved. KYA sits on top and asks the decision question: should I let this agent do this thing, now, with this amount of money?

A short comparison makes the order visible.

The table shows why the terms cannot replace each other. In fact, the first four feed the fifth. A KYA decision without identity has nothing to evaluate. An identity record without the other layers has nothing to decide.

Why the Distinction Matters Now

The distinction matters more every quarter, for three reasons.

First, agent activity is moving from demos to money. McKinsey estimates that agent-mediated commerce could reach between $3 trillion and $5 trillion globally by 2030. In decentralized finance, ChainAware’s published agentic-economy coverage cites that 68% of new DeFi protocols launched in the first quarter of 2026 include an autonomous agent. As these systems take on larger value, the cost of a wrong trust decision rises with them.

Second, creating an agent costs almost nothing. A developer can register hundreds of agents in an afternoon. Therefore, the number of identities no longer signals quality, and every counterparty needs a way to separate the agents that deserve access from those that do not.

Third, investors now treat agent verification as infrastructure. Baselayer, for example, raised a $35 million Series A to extend its identity verification tools to agents, according to coverage of the round. Capital flowing into identity shows that the market takes the problem seriously. It also raises the stakes for anyone who confuses identity with the full answer.

What Agent Identity Means

Agent identity is the set of facts that tie an agent to a verifiable origin. A useful identity record usually contains four elements.

• An identifier that stays stable across sessions and platforms.
• Ownership data, whether that owner is a person, a company or a wallet.
• Credentials that prove the link, such as signatures, certificates or tokens.
• Metadata that describes the agent, including its purpose, endpoints and version.

Several approaches exist, and each fits a different environment.

Identity Frameworks From the Verification Industry

Trulioo describes a Digital Agent Passport, a tamper-proof token that carries an agent’s origin, legitimacy, authorization and user consent. The company positions KYA as an identity layer that lets a merchant confirm who built an agent and what the agent may do, as its explanation of Know Your Agent sets out. Baselayer takes a related route. It extends business verification into an agentic identity suite, so that a company can vouch for the agents it operates.

These frameworks come from the compliance world, and they reuse its logic. Businesses already verify customers through KYC and companies through KYB. Extending the same pattern to software agents feels natural, and it reuses existing regulatory habits.

Identity in Payment Protocols

Payment protocols embed identity too. Google’s Agent Payments Protocol, known as AP2, uses verifiable credentials to bind an agent’s actions to a user’s authorization. The protocol extends existing agent communication standards, and its announcement describes signed records of what a user asked for and approved. OpenAI and Stripe’s Agentic Commerce Protocol takes a different angle. It uses a shared payment token so that an agent can pay without exposing card details, as Payments Journal reported.

Identity on Public Blockchains

On public chains, ERC-8004 plays the identity role. The standard gives each registered agent an ERC-721 token as its identity. Its metadata points to a registration file, and the registration file lists the agent’s name, description, endpoints and supported trust models. The specification on the Ethereum EIP site describes the design in detail, and later sections of this article return to it.

All of these approaches matter. Without identity, nothing else works. You cannot score, limit or revoke an agent that you cannot name. Identity is the foundation, and the rest of this article argues only that a foundation is not a building.

What Know Your Agent Means

Know Your Agent is a process, not a record. It starts from identity and ends with a decision. The process borrows its name from KYC and KYB, but it handles questions that those older frameworks never faced. A person has one body and one set of intentions. An agent can clone itself, change its code overnight, act for several principals and run in thousands of copies.

A complete KYA process draws on five inputs.

1. Identity. Who stands behind the agent, and can they prove it?
2. Authorization. What did the owner or user allow, and within which limits?
3. Integrity. Does the agent run the code it claims to run, without tampering?
4. Behavior. How have the agent, its owner and its funding acted over time?
5. Status. Is the agent still in good standing today?

Identity is one of five inputs. In other words, identity is necessary for KYA, yet it falls far short of sufficient. The output of KYA is a decision with a limit attached: allow, limit, monitor or block.

The Banking Parallel

A comparison with lending makes the logic easy to see. At onboarding, a bank verifies a borrower’s identity. However, no bank approves a loan on identity alone. It also checks income, credit history, existing debts and collateral. The identity check answers whether the borrower exists. Meanwhile, the credit file answers whether the borrower pays.

Agents need the same two layers. The first layer confirms that the agent exists and who owns it. Then a second layer records how the agent and its owner behave. A lender that skipped the credit file would lose money quickly. Counterparties that skip behavioral evidence for agents take the same risk.

What KYA Adds Beyond KYC

KYC verifies a human customer, and KYB verifies a business. KYA must also answer questions that only apply to software.

• Delegation. Which human or company authorized the agent, and for what purpose?
• Scope. What may the agent spend, where, and how often?
• Multiplicity. How many agents share the same operator?
• Drift. Has the agent’s behavior changed since it was approved?
• Revocation. Can the permission end instantly if something goes wrong?

Each question needs data that a one-time identity check cannot supply. Therefore, KYA treats trust as a continuing relationship, not a single event at onboarding.

Agent Identity vs KYA, Side by Side

The table below compares the two ideas across the dimensions that matter in practice.

One row deserves special attention: the last. In an open registry, creating a new identity is cheap. Creating a long, clean behavioral history is expensive, because it takes time and real activity. That asymmetry is why behavioral evidence resists manipulation better than registration data.

Where Identity Stops Working

Three situations show the limit of identity most clearly. Each one involves an agent that passes every identity check and still deserves caution.

A Real Owner With a Bad Record

Suppose a developer registers a legitimate-looking agent. The registration is genuine, the code hash matches and the owner signs every request correctly. Yet the owner’s wallet received its first funds last month from an address tied to a rug pull. Identity passes, and behavior fails.

A counterparty that relies only on identity will extend trust that it should withhold. The agent card describes a useful service. Meanwhile, the wallet history describes the people behind it. Only the second source says anything about risk.

Many Agents, One Operator

Identity treats each agent as a separate entity. A farm of hundreds of near-identical agents from one operator therefore looks like hundreds of independent participants. Each registration is valid, and each owner wallet signs correctly. The pattern across them is the signal, and no single identity record shows it.

ChainAware’s launch analysis of 274,792 indexed ERC-8004 agents flagged 21.1% as farm-detected. In other words, roughly one agent in five belonged to a coordinated group. A purely identity-based process would have approved most of them.

Farms matter because they exploit trust in numbers. They inflate registry counts, they post feedback for one another and they claim incentives that were meant for many independent parties. Our guide to Web3 Sybil protection systems covers the wider problem and the main detection approaches.

Identity That Ages

An identity record describes the moment of registration. Agents change after that moment. Owners rotate keys, upgrade code, move funds and sell the agent. A record that was accurate in January can mislead by March.

Without continuous checks, a counterparty keeps trusting yesterday’s picture. This is the same weakness that led banks to adopt ongoing monitoring after onboarding. KYA applies that lesson to agents, and it treats every old approval as a claim that needs a fresh look.

A Short Illustration: Two Agents, Same Credentials

The following case is invented to make the point concrete. Neither the agents nor the numbers describe real registrations.

Two agents apply for access to a marketplace. Both hold valid credentials, and both owners signed their registrations. On the identity layer, the two agents are indistinguishable.

Agent A belongs to an owner wallet with a two-year history. A verified exchange funded that wallet, and the owner runs a single agent. Agent B belongs to an owner wallet created two weeks ago. An untraceable address funded it, and the same address funded nine other owner wallets that registered similar agents on the same day.

On identity alone, both agents look alike. A behavioral check separates them at once. Agent A scores in a high tier and receives standard access. In contrast, Agent B carries a farm flag and an unknown-feeder flag, so it receives tight limits or a rejection. The marketplace did not need better identity. It needed another kind of evidence.

Anatomy of an Agent Approval Decision

A concrete decision flow shows how the five KYA inputs fit together. The flow below describes a protocol that decides whether to let an agent manage a lending position. Each step uses plain rules and can run in seconds.

First, the protocol resolves identity. It reads the agent’s registration, confirms the owner wallet and checks that the credential matches. If the agent cannot prove a link to an owner, the process stops. Next, the protocol reads the authorization. The owner granted permission to manage one position with a fixed cap, so any request beyond that cap fails automatically.

After those validity gates, the protocol checks integrity. It compares the declared code reference with the current one and looks for changes since approval. A mismatch triggers a review. Then the behavioral gate runs. The protocol looks up the tier and flags, and it compares them with its own policy table. Finally, it checks status. A revoked or flagged agent stops here, even when the earlier gates passed.

Each gate produces a reason code, and the protocol stores the codes with the decision. Later, when an operator asks why a request failed, the answer sits in the log. That audit trail turns KYA from a security feature into an operational asset.

Why Order Matters

The order of the gates saves effort. Validity checks are cheap and decisive, so they run first. Behavioral scoring takes a little longer and gives a graded result, so it runs once the request is valid. Status checks run last, because they catch changes that happened after the earlier data was collected.

Three Failure Stories That Identity Alone Would Not Catch

The three short stories below are illustrative. They combine patterns that appear in the public tracker data, and they do not describe specific agents.

The Polished Newcomer

An operator launches an agent with a professional card, a clear description and a valid registration. The agent asks for access to a lending vault. Identity is perfect. The owner wallet, however, was funded two days earlier by an address that also funded a rug pull deployer. Then the behavioral check flags the funding chain, the score drops, and the vault stays closed. In this case, the funding record told the story that the card did not.

The Crowd of One

A single operator registers two hundred agents through forty owner wallets. Every agent has a clean, valid identity. Likewise, every owner wallet signs correctly. When the operator applies for a promotional access program, each agent looks like a separate applicant. Fleet detection shows that the owner wallets share a feeder and registered within the same hour. The program treats the whole group as one applicant, and the farm collects one allocation, not two hundred.

The Agent That Changed

An agent earns a high tier through months of steady behavior. Then its owner sells it, and the new owner repoints it to a different strategy and routes funds through fresh wallets. The old approval still stands. A scheduled re-check sees the changed funding pattern and the drop in score, and the protocol reduces the agent’s limits before any loss occurs. Without the re-check, the old approval would have carried the new owner’s risk.

These stories share a theme. Each one hides in the gap between what an identity record says and what an operator’s money does.

The Missing Layer: Behavioral Evidence

Behavioral evidence fills the gaps that identity leaves. It looks at what the owner wallet has done, where its money came from, how many sibling agents exist and whether the creator has a history of abuse. None of these facts depend on what the agent claims about itself. They come from public, verifiable activity, and they are costly to fake.

Four evidence groups carry most of the weight in practice.

The Owner Wallet

Every agent has an owner, and the owner’s wallet history shows whether that party has been involved in fraud, scams or abuse. A clean agent card on top of a wallet with a bad record is a warning sign. ChainAware’s behavioral models estimate a fraud probability for the wallet, and they can raise a flag even when nobody has reported the wallet yet. The difference between list-based and behavior-based detection is explained in our article on forensic versus AI-based crypto analytics.

The Funding Chain

Money has a source. The feeder wallet, which is the address that funded the owner, reveals a great deal. A feeder at a verified exchange is the strongest positive signal, because the exchange performed its own checks. An unknown or obfuscated feeder is a risk signal. A feeder with confirmed fraud history is a hard stop. The signal is hard to fake because the operator cannot rewrite the record of who sent the first funds.

Fleet Behavior

A single agent can look fine while a farm of identical agents hides behind it. Registration bursts, many agents per owner and shared funding patterns point to Sybil operations. Fleet-level detection compares agents with one another, which single-agent checks cannot do.

The Creator’s History

Past contract deployments, honeypot history and rug pull history carry forward from creator to creator. Bad actors rarely stop after one attempt. When a creator with a bad record funds a new owner wallet, the new wallet inherits a shadow of that history.

Together, these signals form a score that updates as behavior changes. A passport is issued once. By contrast, a behavioral score is recomputed.

How ChainAware’s Agent Trust Score Works

The Agent Trust Score turns the evidence groups above into a single 0 to 1,000 number, a tier and a set of named flags. It scores three pillars for each ERC-8004 agent: the owner wallet’s fraud probability, the feeder address and the creator’s criminal record, such as rug pull and honeypot history. Fleet-level farm detection then adds the last piece. Behind the score sits the same wallet-level behavioral intelligence that powers ChainAware’s other products, including the Prediction MCP.

The five tiers map to access decisions.

Coverage includes Ethereum, BNB Smart Chain, Base and Avalanche C-Chain, and Mantle support is in progress. In addition, the free tier allows 1,000 queries per month with no signup. Teams that need more volume can use the API, and agents can call the same data through the MCP. The launch article explains the model and the first registry analysis in full.

Signals Beyond the Score

Every score also comes with flags that explain it. These flags matter as much as the number, because they let a risk team see why an agent landed in a tier.

An explanation next to each score also helps with audits. When a protocol declines an agent, the team can name the flags that drove the decision. That record protects the protocol and gives the operator a path to improve.

The Two-Key Lock

A useful mental model for combining identity and behavior is a two-key lock. Identity opens the first gate. Behavior opens the second. An agent needs both keys to pass.

The first gate answers whether the agent is who it says it is and whether the owner allowed the action. Next, the second gate answers whether the agent and its operator are safe to deal with. A failure at the first gate is a hard stop, because the request is not valid. By comparison, a failure at the second gate is a risk judgment, and that is where limits, monitoring and human review apply.

This design has a practical benefit. It lets teams buy or build each layer separately. An identity provider can handle the first gate, and a behavioral scorer can handle the second. Neither needs to be perfect at both jobs. Our overview of the agent trust infrastructure race shows how different providers focus on different layers.

What ERC-8004 Shows About This Split

ERC-8004 makes a good case study because it separates the layers on purpose. The standard, called Trustless Agents, lists its goal as discovering agents and establishing trust through reputation and validation. According to the specification, three registries do the work: an identity registry, a reputation registry and a validation registry. At the time of writing, the EIP site lists the standard as a Draft, and ChainAware tracks live agents on Ethereum mainnet, where the registries went live in January 2026.

The Identity Registry

The identity registry builds on ERC-721. Each agent becomes an NFT, the agent identifier is the token identifier, and the token’s URI points to a registration file. The file is a JSON document that lists the agent’s name, description, image, service endpoints and supported trust models. Beyond that, the registry supports an agent wallet field. That field starts as the owner’s address, and changing it requires a signature from the new wallet.

This design gives every agent a portable, globally unique name. Before ERC-8004, agents from different platforms had no shared way to introduce themselves. The identity registry solves that problem well.

The Reputation Registry

Next, clients can post feedback about an agent through the reputation registry. Importantly, the specification forbids the agent’s owner or approved operator from submitting feedback for that agent. Each entry stores a value, optional tags and a revocation status, and other parties can append responses such as refund notices.

The registry does not decide whose feedback to believe. Instead, the specification states that Sybil attacks are possible and that fake agents can inflate their reputation. It expects reputation systems to filter by reviewer. In practice, that filter needs outside data about each reviewing wallet, such as its age, funding and relationship to the agent’s owner.

The Validation Registry

The validation registry lets an agent’s owner request independent checks. A designated validator answers with a response between 0 and 100. The specification leaves incentives and slashing to the specific validation protocols built on top, and it names trust models such as stake-secured re-execution, zero-knowledge machine learning proofs and trusted execution environments.

Of the three registries, validation points furthest toward cryptographic assurance. Today, most agents rely on reputation signals or on third-party scoring, because validation protocols are still maturing.

Authorization and Integrity: The Two Inputs Between Identity and Behavior

Identity and behavior get most of the attention, yet two other KYA inputs sit between them. Authorization and integrity decide whether a request is valid. They do not measure risk, but a request that fails either one should never reach the risk score.

Authorization: What Did the Owner Allow?

Authorization records the scope that a user or business granted to an agent. A good record names the actions, the limits, the time window and the counterparties. For example, a treasury agent might hold permission to swap stablecoins up to a daily cap, on two named venues, for thirty days.

Payment protocols are building this layer in public. Google’s AP2 describes signed mandates that capture what a user asked for and what the user approved at purchase time. A commentary on agentic payments describes a similar chain of records for intent, payment and receipt, and it argues that these records will matter most when a dispute arises. That liability deep dive is an opinion piece rather than settled rule, but its central point holds: evidence of permission protects every party.

A mandate has one important limit, however. It proves that someone granted a permission. Yet it does not prove that the agent behaves well inside that permission, and it does not prove that the person who granted it is safe to deal with. A permission slip is not a character reference.

Integrity: Is the Agent Running What It Claims?

Integrity asks whether the agent’s code and configuration match what the owner declared. An agent that changes its model, its tools or its instructions after approval can act in ways that nobody reviewed. Some analysts call this effect agent drift. The agent stays technically authorized, yet its actions stop reflecting the owner’s intent.

Integrity checks use code hashes, attestations and, in some designs, trusted execution environments. The ERC-8004 specification points in this direction when it lists stake-secured re-execution, zero-knowledge proofs and trusted execution environments as pluggable trust models. These tools are still maturing. Therefore, most counterparties today rely on a mix of declared metadata and behavioral monitoring to catch drift.

Why These Two Inputs Still Need Behavior

Authorization and integrity answer “is this request valid?” Behavior answers “is this party likely to cause harm?” A bad operator can pass the first two tests easily. It can sign valid mandates for every agent it runs, and it can publish clean code hashes. The risk lives elsewhere, in the operator’s history, funding and fleet structure.

For that reason, a sound KYA design treats the first three inputs as validity gates and the fourth as a risk judgment. Validity failures end the request. Risk findings shape the limit.

Agent Identity Across Ecosystems: A Fragmented Picture

Identity standards do not yet connect. A passport from one provider means little to a protocol that reads a different credential. An ERC-8004 token proves registration on a public chain, but it carries no meaning inside a card network’s agent program. Meanwhile, each payment protocol defines its own credentials and mandates.

This fragmentation creates a practical problem for counterparties. A merchant that accepts agents from several ecosystems must read several credential formats. Likewise, a DeFi protocol that interacts with agents from several chains must resolve several registries. As a result, many teams keep a thin internal layer that normalizes identity facts into one internal record.

Behavioral evidence helps here, because it does not depend on the credential format. A wallet’s history reads the same way whether the agent arrived through a registry, a protocol or a direct integration. Public chains offer the cleanest case, since the data is open and permanent. Closed ecosystems will need to build comparable behavioral data, and the design principle transfers: judge the operator and its money, not just the paperwork.

What Counterparties Can Do Today

Counterparties do not need to wait for universal standards. Three steps help immediately.

1. Normalize identity into one internal record with an owner, an identifier and a source.
2. Store the credential and mandate next to every decision for later disputes.
3. Attach a behavioral score to the owner and the funding source, whatever the credential format.

These steps make a team ready for new standards instead of locked into one of them.

Reading Agent Risk in Payments and Commerce

Agent identity matters well beyond DeFi. In card payments, the arrival of agents breaks a long-standing assumption. Fraud models for card-not-present traffic lean on signals about the person, such as device, session and typing rhythm. A server-side agent produces none of them. One payments analyst describes the result as “a total loss of the traditional fraud signal,” and it argues that merchants of record may carry liability by default.

That claim is opinion, and networks and regulators are still working out the rules. Even so, the planning assumption is clear. Risk teams need new signals that describe the agent, because the human signals are gone. Credentials and mandates supply two of those signals. Behavioral evidence about the agent’s operator supplies the third.

The on-chain agent economy offers an early preview. Its registry is open, its funding chains are visible, and its fleets are measurable. Therefore, it shows what behavioral trust looks like when the data exists. Card and wallet-based agent payments will face similar patterns, including farms, concentration bursts and opaque funding. Teams that learn the signals on public chains will adapt faster when agent traffic grows in closed systems.

What the Registry Cannot Tell You

The registry gives structure, and it leaves judgment to the market. Several gaps follow from its open design.

• Registration is not vetting. No one reviews a registration before it goes live. A farm operator can register thousands of agents in an afternoon.
• The registration file is self-described. It states what the owner wants others to believe. The specification itself notes that the standard cannot cryptographically guarantee that advertised capabilities work as claimed and stay non-malicious.
• Feedback depends on the reviewer. A rule against owner self-review does not stop an operator from using other wallets. One party that controls ten wallets can still post ten reviews.
• The owner’s history sits outside the record. Instead, the registry shows who owns the token. It does not show whether that wallet previously ran a rug pull.
• Funding is invisible. The record does not show where the owner’s money came from.
• Fleets are invisible. Each registration stands alone, so the registry cannot tell you that a hundred agents share an operator.

The optional trust field in the registration file also deserves a mention. When an agent leaves it empty, the specification says the standard serves discovery only and makes no trust claim. Many registered agents leave it empty. For them, the registry says nothing at all about trust.

In short, ERC-8004 answers an important question well. It names which agents exist and how to reach them. A KYA process then asks the next question.

What the Data Shows About the Agent Population

Still, a trust layer is only useful if it finds real differences between agents. The public data suggests that it does.

The Launch Analysis

At launch, ChainAware’s analysis covered 274,792 indexed ERC-8004 agents. The tier split showed a polarized population.

Together, 51.8% of agents sat in the two lowest tiers. In addition, 21.1% carried the farm flag, and 741 agents had been funded by confirmed rug pull operators. The farm flag was the most common risk flag, followed by an unknown feeder at 9.5%. A verified-exchange feeder appeared for only 1.0% of agents. Our launch article lists the full flag breakdown.

The Weekly Tracker

Since launch, ChainAware has published a weekly Agent Trust Tracker that follows registrations, owners and trust. The series shows that volume and quality move independently.

Two lessons stand out. First, registration counts say little about trust. Week 34 set a registration record while Week 41 set a trust low. Second, the median can swing widely, because a single large operator can dominate a week.

The Week 41 report also showed the share of agents with an unknown feeder nearly doubling to 12.84%. Earlier weeks showed the same fleet logic at work. In Week 31, unique owners collapsed by 58.7% while registrations fell only 7.0%, so agents per owner more than doubled to 2.54. The Week 31 tracker and the Week 32 tracker explain how concentration and farm flags connect.

What the Numbers Mean for KYA

A KYA process that checks only identity would pass most of these agents. By contrast, a behavioral layer separates them. The data therefore supports a simple conclusion: registry growth is cheap, quality is scarce, and the difference needs measurement.

How to Combine Both Layers in Practice

A practical KYA pipeline runs identity first and behavior second. The steps below work for a protocol, a marketplace or a payment team.

1. Resolve identity. Confirm the agent’s identifier, owner and credentials. Reject agents that cannot prove a link to an owner.
2. Check authorization. Read the scope that the owner or user granted. Reject actions outside that scope.
3. Score behavior. Look up the owner wallet, the funding chain and the fleet signals. Record the tier and flags.
4. Apply policy. Map the tier and the requested action to a limit. A Sovereign agent may receive larger limits than a Provisional agent.
5. Re-check. Repeat the behavior step on a schedule and before large actions.

Teams that already use an identity provider need only add steps three to five. Meanwhile, teams that start from a blank page can begin with the behavioral check, because on-chain evidence is open and works the same way for every agent.

A Tier-Based Policy Example

A policy turns scores into rules. The example below is a starting point, and each team should adjust it to its own risk appetite.

Rules like these have three advantages. They are easy to explain to auditors. Next, they are easy to automate. And they give operators a clear target if they want more access.

A Four-Week Rollout Plan

Teams often ask where to start. A short plan helps.

• Week 1: inventory. List every place where an agent can touch money or permissions. Rank each place by value at risk.
• Week 2: observe. Look up the counterparties you already see. Record their tiers and flags without blocking anyone. The baseline shows how much risk you carry today.
• Week 3: write policy. Define one rule per access level, using a table like the one above.
• Week 4: enforce and re-check. Turn the rules on for new agents, add a scheduled re-score and review exceptions weekly.

The plan needs no heavy integration. It needs a clear owner and the discipline to write the policy down.

Implementation Notes for Builders

Developers who add KYA to a product face a few design choices. The notes below come from the patterns that work best.

Keep the layers separate in code. Store identity facts and behavioral scores as different fields with different update schedules. Identity changes rarely, while scores change often.

Cache with care. A score from last month may no longer apply. Set a time to live that matches the value at risk, and force a fresh lookup before large actions.

Make decisions explainable. Log the tier, the flags and the rule that fired. Compliance teams and operators will ask why an agent was declined.

Fail safe. If a lookup fails, fall back to a low-limit policy instead of full access.

Expose a path to appeal. Operators who improve their history should be able to earn a better tier. A trust layer that cannot change its mind becomes a blacklist.

Let agents check each other. Agents can call the score through the Prediction MCP before they pay another agent. Machine-to-machine trust checks remove the human from a loop where a human cannot keep up. ChainAware’s own agent fleet works this way, as the overview of the 32 Claude sub-agents shows.

For high-volume screening of wallets beyond agents, the fraud detection API covers the same behavioral engine at scale.

Who Needs KYA, and What Each Team Should Do

Different teams meet agents in different places. Each one can start with a small, concrete step.

DeFi Protocols and DAOs

Protocols give agents access to vaults, lending pools and treasuries. Before any agent receives such permissions, check its tier and flags. Elevated Risk agents should get limits or no access. Agents with a farm flag or a fraud-linked feeder should not receive treasury permissions at all.

DAOs face a related problem in governance. An agent that votes or proposes on behalf of a delegate deserves the same scrutiny as a human delegate. Our guide to Web3 trust verification systems maps five categories of trust problems, and agent access sits across several of them.

Agent Marketplaces and Registries

Marketplaces rank and recommend agents. If they rank by star rating or registration age, they reward the easiest metrics to manufacture. Ranking by trust tier, and showing the farm and funding flags next to each listing, gives buyers more than a name and a rating.

Payment and Fintech Teams

Where settlement runs on-chain or through stablecoins, wallet-level trust becomes a direct input to risk rules. Payment teams also face a wider problem in card-based flows, where agents remove the human signals that fraud models rely on. A behavioral layer for the agent and its operator restores part of that lost signal. Payment teams should treat KYA as one more control in the stack, next to tokens and signed mandates.

Investors and Strategic Partners

Investors who back agent projects need to separate real autonomy from marketing. A May 2026 study from researchers affiliated with Pantera Capital, Stanford, IC3 and Ava Labs examined more than 1,900 AI-tagged crypto projects and found that even agents with fully public wallets could not always be verified as autonomous. Our article on how investors should evaluate AI trading agents summarizes the findings. A KYA lens adds a practical test: ask for the funding chain and the fleet structure behind any agent that claims to manage money.

Compliance and Security Teams

Compliance teams already ask where money came from and who stands behind an account. KYA gives them the same questions for software. When a score raises a concern, the team can open a deeper review. ChainAware Investigation turns one wallet address into a seven-section report in about a minute, and it covers counterparties, clusters and AML exposure. The article on wallet forensics and AML reports explains how analysts use it.

Questions to Ask Any KYA Vendor

Buyers can use a short list to test whether a product delivers identity or real KYA. The list works for any provider, ChainAware included.

1. Does the product re-evaluate agents over time, or only at onboarding?
2. Which evidence beyond the agent’s own claims does it use, such as wallet history and funding?
3. Can it detect many agents controlled by one operator?
4. Does it explain why an agent received its rating, in terms an auditor can read?
5. Can an automated system call it, or does it need a manual review step?
6. Does it say what it cannot see?
7. Can operators improve their standing, and how quickly?

A product that answers yes to the first five and gives honest answers to the last two is close to full KYA. In contrast, a product that mainly issues credentials is an identity product. That is valuable, but it covers one layer.

Red Flags in Vendor Pitches

Some phrases should prompt a closer look.

• “Verified agent” with no description of what was verified.
• A single score with no flags or explanation.
• No mention of re-checks or monitoring.
• Silence about fleets or shared operators.
• Claims of perfect detection.

Honest vendors describe limits. A scoring system that claims to see everything has not told you what it misses.

Common Mistakes in Building a KYA Process

Teams repeat a handful of mistakes. Avoiding them saves time and losses.

• Treating identity as trust. A verified developer can still run a Sybil farm.
• Checking once. An agent that passes at registration can change behavior later.
• Ignoring the funding chain. The feeder is often the clearest signal and the easiest one to skip.
• Using a single threshold for everything. A low-value task and a treasury permission deserve different tiers.
• Trusting self-reported reputation. Feedback that operators can post through many wallets measures effort, not quality.
• Blocking everything that looks odd. An unknown feeder or a delegated account calls for limits and review, not automatic rejection.
• Forgetting the evidence trail. Without stored inputs, disputes become guesswork.

The last point matters in regulated settings. Auditors and counterparties will ask why the team allowed or declined an agent. A log of the tier, the flags and the rule that fired answers that question in seconds.

The Cost of Confusing the Two

Confusion has a price, and different parties pay it in different ways.

A protocol that grants large permissions after an identity check alone accepts all the risk that identity cannot see. An investor who treats a verified badge as a quality signal risks funding a farm. A payment team that equates a valid credential with a safe agent will learn the difference only after a loss. Similarly, a marketplace that ranks by registration age rewards operators that start early and fund cheaply.

The remedy is simple. Keep the vocabulary precise. Say “identity” when you mean who, and say “KYA” when you mean who plus whether and how much. Then ask for evidence on each part, and write the policy down.

Where Agent Trust Is Heading

Three trends will shape the next two years.

Identity Will Commoditize

As more standards and providers appear, issuing a credential or a registry entry becomes a commodity. Differentiation will move to the evidence that identity cannot supply. Standards will define the pipes, and specialists will supply the judgment.

Trust Checks Will Become Machine-to-Machine

Agents will check each other before they transact. A human cannot sit in a loop that runs thousands of times a day, so the check must be fast, structured and repeatable. The overview of the Web3 agentic economy explains why machine-readable trust becomes core infrastructure, and the guide to blockchain data providers for AI agents maps the data sources that agents can use.

Evidence Will Beat Claims

As agent numbers grow, counterparties will stop trusting self-reported descriptions. They will favor verifiable evidence such as funding history, fleet structure and on-chain behavior. Public blockchains give this evidence a head start, since the data is open and the history is permanent. Closed payment ecosystems will need equivalents, and the design lessons transfer.

For readers who want the next step in this series, our companion guide on ERC-8004 trust signals goes deeper into the registry and the signals that surround it. In addition, the first look at why trust comes before integration gives the DeFi builder’s view.

A Design Example: Re-Ranking an Agent Marketplace by Trust

The following example is illustrative. Both the marketplace and its numbers are invented to show how the ideas apply.

Imagine a marketplace that lists thousands of agents and ranks them by registration age and star rating. Operators quickly learn the rules. They register early, post feedback through several wallets and climb the list. Buyers follow the ranking, and the best-ranked agents are not always the safest.

The marketplace team decides to add KYA. First, the team resolves identity, so every listing links to a verified owner. Second, the team adds a behavioral score for each owner and shows the tier next to the listing. Third, farm and funding flags appear as visible badges. Finally, feedback receives weight by reviewer quality, so that a review from an old, independently funded wallet counts more than a review from a wallet funded last week by the agent’s own operator.

Three results follow. Farm-flagged agents drop in the ranking, because the flag is visible and buyers avoid it. Honest newcomers with a clean, exchange-funded owner rise, since the score rewards a traceable source of funds. And the marketplace gains an evidence trail that explains every placement, which helps when an operator disputes a ranking.

Why Visible Flags Change Behavior

Visible flags create an incentive. Operators who want better placement have a clear path: fund wallets from traceable sources, stop sharing one feeder across unrelated owners and keep wallets active over time. These steps are not tricks. They are signs of an operator with a stable, traceable record, which is exactly what a counterparty wants to see.

Metrics That Show Whether KYA Works

A KYA process deserves measurement. Teams can track a short list of indicators and tune thresholds with data instead of guesswork.

• Approval rate by tier. Higher tiers should show higher approval rates.
• Loss and dispute rate by tier. Lower tiers should account for more incidents. If they do not, the thresholds need work.
• Share of agents with a farm flag. A rising share signals growing operator concentration.
• Share of agents with an unknown feeder. A rising share weakens the funding signal.
• Re-check coverage. The percentage of active agents scored within the chosen time window.
• Time to decision. Added latency can hurt conversion, so watch it.
• Overrides. Every manual override needs a reason, and a pattern of overrides points to a policy gap.

Leadership benefits from these numbers too. They turn a vague promise of “agent security” into a visible control with measurable results.

A Short Glossary of Agent Trust Terms

The glossary below defines the terms used in this article, in the order that most readers meet them.

• AI agent: software that pursues a goal by choosing and taking actions, often including payments, without a human approving each step.
• Agent identity: a verifiable record of who or what an agent is and who owns it.
• Know Your Agent (KYA): the process of deciding whether an agent may act and how far, using identity, authorization, integrity, behavior and status.
• ERC-8004: an Ethereum standard for agent discovery and trust, built around identity, reputation and validation registries.
• Owner wallet: the address that controls an agent’s identity token.
• Feeder wallet: the address that funded the owner wallet.
• Sybil farm: a group of agents or wallets that one operator controls while presenting them as independent.
• Agent Trust Score: ChainAware’s 0 to 1,000 rating for ERC-8004 agents, with five tiers and named flags.
• Mandate: a signed record of what a user authorized an agent to do.
• Agent drift: a gradual change in an agent’s behavior that leaves it technically authorized but no longer aligned with the owner’s intent.

Why Votes and Passports Both Miss the Operator

Review-based rankings share a basic weakness. Anyone can create 50 wallets, register 50 agents and let them upvote a 51st. That is a plain Sybil attack, and a score built on votes cannot see it. The example is an illustration, yet the tracker shows that such fleets are real: 21.1% of agents carried the farm flag at launch. Identity has a similar gap, because a passport says nothing about the wallet that funded the agent.

ChainAware takes a different route. The Agent Trust Score uses on-chain behavior only, with no reviews, no ratings and no self-reported data. Faking a clean funding history costs real money and time, while 50 upvotes cost almost nothing. Moreover, an attacker’s own address and feeder address pass through ChainAware’s machine-learning fraud detection, so abnormal behavior lowers the score instead of raising it.

Why Behavior Is ChainAware’s Home Ground

ChainAware built its models to predict fraud and rug pulls long before agent identity became a topic. It reports 95% accuracy for its per-address fraud model, which anyone can verify through ScamDB, and its rug pull model predicted 90.1% of cases before they happened in a PancakeSwap test documented on the rug pull verification page.

Key Facts at a Glance

The list below summarizes the main points for readers who want the short version.

• Agent identity proves who is behind an agent. Know Your Agent decides whether the agent may act and how far.
• A full KYA process uses five inputs: identity, authorization, integrity, behavior and status.
• Identity is cheap to create in open registries, so the number of identities says little about quality.
• Behavioral evidence covers the owner wallet, the funding chain, fleet structure and the creator’s history.
• ChainAware’s Agent Trust Score rates ERC-8004 agents from 0 to 1,000 across five tiers, from Untrusted to Sovereign.
• At launch, 51.8% of 274,792 indexed agents sat in the two lowest tiers, and 21.1% carried the farm flag.
• By Week 41 of 2026, the index held 568,590 agents, and the median trust of new registrations had fallen to 101.
• ERC-8004 gives agents identity, feedback and validation hooks, and it leaves trust judgments to third parties.

Frequently Asked Questions

What is the difference between agent identity and Know Your Agent?

Agent identity records who or what an agent is and who owns it. Know Your Agent is the wider process that decides whether the agent may act. KYA uses identity as one input, alongside authorization, integrity, behavior and status.

Is agent identity enough to trust an AI agent?

No. A verified identity shows that the agent exists and has an owner. It does not show how the owner behaves, where the money came from or how many sibling agents the same operator runs. Those facts need behavioral evidence.

How does a Digital Agent Passport relate to a trust score?

A passport carries identity and authorization facts, such as origin and consent. In contrast, a trust score measures behavior. The two complement each other, because one says who and the other says how.

Can a verified agent still be risky?

Yes. A verified developer can run a Sybil farm, and a genuine owner can receive funding from a fraud-linked address. Behavior must be checked separately and repeated over time.

Does ERC-8004 verify that an agent is trustworthy?

No. ERC-8004 gives agents a standard on-chain identity and provides hooks for feedback and validation. The standard itself states that it cannot cryptographically guarantee that advertised capabilities are functional and non-malicious. Trust must come from independent scoring and validation.

What does the Agent Trust Score measure?

It measures three pillars for each agent: the owner wallet’s fraud probability, the feeder address that funded the owner, and the creator’s rug pull and honeypot history. Fleet-level farm detection adds a view across agents. The result is a 0 to 1,000 score, a tier and named flags.

Which chains does the Agent Trust Score cover?

Ethereum, BNB Smart Chain, Base and Avalanche C-Chain are covered today. Mantle support is in progress.

Is the Agent Trust Score free?

The score is free for public indexed agents, with 1,000 queries per month and no signup. Teams with higher volume can use the API or the Prediction MCP. See the Agent Trust Score page for current details.

How often should an agent be re-checked?

Check on a schedule that matches the value at risk, and check again before large or unusual actions. Behavior changes, so an old approval is only a claim until someone verifies it again.

Does KYA apply to agents that never touch a blockchain?

The principles apply to every agent, because every counterparty needs identity, authorization and behavioral evidence. ChainAware’s score covers on-chain agents and their wallets. Off-chain ecosystems need their own behavioral data sources, and the same two-gate design fits them.

Conclusion: Use Both Keys

Agent identity and Know Your Agent work together, and neither replaces the other. Identity gives every agent a name and an owner. KYA turns that name into a decision. The decision needs evidence that agents cannot write for themselves: wallet history, funding chains, fleet structure and a creator’s record.

Public data shows why this matters. A registry that grew past half a million agents in months also produced a record-low median trust score. Open systems scale volume easily, and they scale quality only when someone measures it.

Start small. Pick one agent integration you already run, look up the counterparty’s score, and write down which tier you would allow for which action. That single exercise produces a first policy. Then add the re-check, and keep the evidence trail.

Teams that want help mapping this to their own flows can review the Agent Trust Score, explore the Prediction MCP, or see how autonomous compliance screening works for regulated teams. Token-level risk sits next to agent risk in many integrations, and the Token Audit covers it. Finally, the Wallet Auditor comparison helps teams choose wallet-level tooling.

The post KYA vs Agent Identity: Why Knowing Who an AI Agent Is Does Not Tell You Whether to Trust It first appeared on ChainAware.ai.

AI agents now register, transact and negotiate on their own, and the question “can we trust this agent?” has become a daily operating problem. Know Your Agent, or KYA, is the discipline that answers it. This pillar guide explains what KYA is, why identity alone falls short, what a behavioral trust layer measures, what public data reveals about the agent economy and how teams can put KYA into practice.

For two decades, financial firms have relied on Know Your Customer, or KYC. KYC asks who a person is and whether the firm may serve them. The same question now applies to software. Agents hold wallets, sign transactions, buy goods and call services. Each of these acts carries risk, and each needs a decision: should this agent be allowed to do this?

KYA is the answer to that decision problem. It gathers evidence about an agent and its operator, turns the evidence into a risk view and sets limits for what the agent may do. A good KYA process works fast, runs without human effort for most cases and leaves a clear record for the cases that go wrong.

This guide serves as the hub for our series on the topic. It explains the core ideas and then points to detailed articles on identity, registries, funding chains, fraud patterns, card-network risk and checkout verification. Along the way, it uses public data from the ERC-8004 agent ecosystem to show what trust looks like at scale. It also marks limits clearly, because honest limits make a framework more useful.

What Is Know Your Agent (KYA)?

Know Your Agent is the process of deciding whether an AI agent may act and how far it may go. It combines identity, authorization and behavioral evidence into one risk decision. The word “agent” covers any autonomous or semi-autonomous software that acts on behalf of a person, a company or another agent.

The Core Question

Every KYA process tries to answer three linked questions.

1. Who is this agent? Identity evidence links the agent to an operator and a registry entry.
2. What is it allowed to do? Authorization evidence shows the scope that a user or system granted.
3. How likely is it to cause a loss? Behavioral evidence estimates risk from the operator’s history, funding and fleet links.

The first two questions have well-known tools. Registries, credentials, tokens and signed mandates handle them. The third question has fewer tools, and it decides most losses. KYA is incomplete without it.

KYA Compared With KYC

KYA borrows from KYC, yet it differs in important ways. The table below summarizes the contrast.

Two differences matter most. First, agent identities cost almost nothing to create, so identity checks filter very little. Second, agents act at machine speed, so the check must be automatic and continuous.

Why KYA Matters Now

Agents moved from demos to deployed systems quickly. Three forces make KYA urgent.

Agent Volume Is Growing

The ERC-8004 ecosystem offers a public window into this growth. By Week 41 of 2026, ChainAware’s index held 568,590 agents, up from 274,792 in the launch analysis. McKinsey has estimated that agent-mediated commerce could reach between $3 trillion and $5 trillion globally by 2030, and even a fraction of that figure implies a large volume of machine-initiated payments. ChainAware’s own coverage of the agentic economy also reports that a majority of new DeFi protocols now include an autonomous agent, a claim we flag as ours and not as an independent statistic.

Registration Is Cheap

An open registry lets anyone register an agent for the price of a transaction. That openness is a feature for builders and a gift for abusers. In the launch analysis, 51.8% of indexed agents sat in the Elevated Risk or Untrusted tiers, and 21.1% carried the farm flag. Cheap identities scale faster than trust.

Money Is Moving

Agents now handle payments, trades and treasury actions. OpenAI and Stripe launched the Agentic Commerce Protocol, and Google introduced AP2. Card networks run their own agent programs. Where money moves, fraud follows, and the cost of a weak trust decision rises with every new integration.

The Cost of Doing Nothing

Teams that skip KYA face two bad choices. They can accept all agent traffic and absorb fraud, promotion abuse and disputes. Alternatively, they can block all agent traffic and lose a growing channel. KYA offers a third path: allow good agents, limit uncertain ones and refuse bad ones, with evidence for each decision.

Identity Is Necessary but Not Sufficient

Most early KYA efforts focus on identity. That focus makes sense, because a merchant or protocol must first recognize an agent. Yet identity answers only one of the three questions.

What Identity Frameworks Offer

Several efforts build agent identity. Trulioo describes a Digital Agent Passport that carries an agent’s origin, legitimacy, authorization and consent, and its Know Your Agent explanation frames the concept for commerce. A report on Baselayer’s $35M Series A shows the capital flowing into agent identity platforms. On public chains, ERC-8004 defines identity, reputation and validation registries, and its specification is public.

These efforts deliver real value. They let counterparties recognize an agent, attach revocation and build audit trails. In addition, they also create a shared language for the industry.

Where Identity Stops

Identity proves that an agent is registered. It does not prove that the agent’s operator is honest. A registered agent can belong to a fleet of thousands. It can be funded by a wallet that also funded a rug pull. Its creator can have a record of honeypots. None of this appears in a registration entry.

Our analysis of KYA versus agent identity develops the point in detail. Its core message is simple: identity tells you who, and behavior tells you whether to trust. A system that stops at the first answer treats a well-documented fraud the same as a well-documented honest operator.

What a Registry Can and Cannot Tell You

ERC-8004 is a strong foundation. Its reputation registry lets clients publish feedback about agents, and its validation registry lets validators attest to results. The specification also protects against one simple abuse: an agent’s owner or approved operators cannot submit feedback for their own agent. Gaming therefore happens elsewhere, through Sybil wallets that submit friendly feedback or through fleets that appear independent.

The article on ERC-8004 trust signals walks through what each registry proves and where feedback can mislead. A registry records claims. Moreover, a trust layer evaluates the claimants.

The Four Evidence Groups

A behavioral trust layer collects evidence in four groups. Each group answers a different part of the risk question.

Group One: The Owner Wallet

The owner wallet controls the agent. Its history shows how the operator behaves on chain. Past interactions with fraud, mixers, scam contracts or sanctioned addresses raise risk. A long, clean history lowers it. ChainAware’s fraud models assign a fraud probability to the owner wallet, and the number feeds the agent’s score.

Group Two: The Feeder Address

The feeder is the address that funded the owner wallet. Funding chains reveal intent that a wallet’s own history may hide. A fresh wallet funded by a verified exchange looks different from a fresh wallet funded by an address tied to a rug pull.

The analysis of funding-chain risk explains why this signal matters. In the launch data, 741 agents were funded by confirmed rug pull operators, and the feeder was traceable for about 38% of indexed agents. Where the feeder could not be traced, the FEEDER_UNKNOWN flag applies.

Group Three: The Creator Record

The creator wrote or deployed the agent. A creator with a history of rug pulls or honeypots poses a risk to everyone who interacts with the agent. This evidence is rare but severe. In the launch analysis, the CREATOR_RUG_HISTORY flag appeared on a tiny fraction of agents, 0.02%, and each case deserves attention.

Group Four: Fleet Detection

Fleets are groups of linked agents under one operator. They arise because registration is cheap. Fleet detection looks for shared owners, shared funders and shared patterns. In the launch data, 21.1% of agents carried the FARM_DETECTED flag. Fleets matter because they distort reputation, inflate activity and exploit incentives.

Why Four Groups Beat One

Any single group can mislead. A clean owner wallet may hide a dirty feeder. Furthermore, a clean feeder may fund a farm. A clean farm member may have a creator with a bad record. Combining the four groups raises the cost of evasion, because an attacker must clean up every layer.

The ChainAware Agent Trust Score

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

How the Score Is Delivered

The score is free for public indexed agents, with 1,000 queries per month and no signup. A web interface lets anyone look up an agent. Software can call the score through an API or through the Prediction MCP, so that agents and backends can check a counterparty before they act. The score covers Ethereum, BNB Smart Chain, Base and Avalanche C-Chain, and Mantle support is in progress.

Our launch article on the Agent Trust Score lists the full breakdown, and the piece on why trust comes first in agentic commerce explains the strategic case.

Named Flags

Flags give plain reasons for each score. The main ones are FARM_DETECTED, FEEDER_UNKNOWN, EIP7702_DELEGATED, FEEDER_CEX_VERIFIED, FEEDER_RUG_HISTORY and CREATOR_RUG_HISTORY. Teams can set rules by flag, for example stricter limits for unknown feeders or automatic review for rug pull history.

What the Public Data Shows

Public data lets anyone test claims about agent trust. ChainAware indexes the ERC-8004 ecosystem and publishes weekly tracker reports. Together, the launch analysis and the tracker series form one of the larger public views of agent behavior.

The Launch Analysis

The launch analysis covered 274,792 ERC-8004 agents. Its headline numbers are stark.

• 51.8% of agents sat in the Elevated Risk or Untrusted tiers.
• 21.1% carried the FARM_DETECTED flag.
• 9.5% carried the FEEDER_UNKNOWN flag.
• 7.6% carried the EIP7702_DELEGATED flag.
• 1.0% carried the FEEDER_CEX_VERIFIED flag, a positive signal.
• 0.3% carried the FEEDER_RUG_HISTORY flag.
• 0.02% carried the CREATOR_RUG_HISTORY flag.
• 741 agents were funded by confirmed rug pull operators.

The numbers show a registry where trust is the exception and not the rule. Only about a third of agents reached the top two tiers. Registration, in other words, did not guarantee quality.

The Weekly Tracker

The weekly ERC-8004 Agent Trust Tracker follows registrations, owners, median trust and flag shares week by week. Several data points stand out.

The Week 36 tracker and the Week 40 tracker show how quickly the picture can shift in a few weeks.

What the Swings Teach

Quality does not move steadily. A record median of 918 in Week 36 gave way to a median of 101 in Week 41, the lowest since Week 5. By contrast, a policy tuned to one week’s average can fail in the next. KYA must therefore refresh and respond to change, not issue a one-time verdict.

Farms Persist

The farm-detected share stayed in a narrow range across several weeks: 18.73% in Week 32, 18.39% in Week 33 and 17.05% in Week 34. By Week 40 it stood at 16.12%. Defenders do not remove fleets by naming them once, and operators adapt. For a deeper reading of these series, see our study of agent fraud patterns from the ERC-8004 tracker.

Technology Shifts

The count of EIP-7702 delegated accounts rose about 33.8% between Week 35 and Week 40. New account mechanics change what signals exist and how attackers hide. KYA models must follow these shifts, which is another reason continuous updates matter. In Week 41, FEEDER_UNKNOWN reached 12.84%, and Base added 37,037 agents, showing how activity moves across chains.

The KYA Series: What Each Article Covers

This pillar sits at the center of a series. Each article takes one topic in depth. The summaries below show how the pieces fit together.

KYA vs Agent Identity

This article separates identity from trust. It explains what passports, registries and credentials prove, shows where they stop and describes how behavioral evidence completes the picture. Read it first if your team treats identity as the whole of KYA.

ERC-8004 Trust Signals

This article examines the three ERC-8004 registries. It clarifies what feedback signals mean, how Sybil wallets can inflate them and why an external trust layer adds value.

Funding-Chain Risk

This article follows the money. It shows how the feeder address reveals intent, how the 741 rug-pull-funded agents surfaced and why FEEDER_UNKNOWN deserves caution.

Agent Fraud Patterns From the Tracker

This article reads the weekly series as a fraud dataset. It covers farms, registration waves, delegation shifts and the swings in median trust.

Agentic Commerce Fraud and the Four-Party Model

This article applies KYA to card payments. It explains how agents strain the issuer, acquirer, merchant and network roles, and which new fraud scenarios follow.

Verifying AI Agents at Checkout

This article turns the ideas into a checkout design with three layers: credentials and tokens, mandates and behavioral evidence.

The Wider Landscape of Agent Trust

KYA does not exist in a vacuum. Several communities work on parts of the problem, and the picture changes quickly.

Identity and Credential Vendors

Identity vendors focus on recognition and attestation. They issue passports, verify operators and maintain registries. Their strength is a clean answer to “who is this?” Their limit is that identity rarely predicts behavior.

Payment Protocols and Networks

OpenAI and Stripe’s Agentic Commerce Protocol gives agents a shared payment token. Payments Journal covered the launch. Google’s AP2 uses signed mandates, and its announcement describes intent, cart and payment mandates. Card networks run programs of their own, and a report on the Visa and OpenAI partnership shows how networks and AI firms move together. A liability analysis at FinTech Wrap Up argues that agents remove traditional fraud signals and that the merchant of record may carry much of the risk. That piece is opinion, and liability rules are still developing.

Behavioral and On-Chain Intelligence

Behavioral providers score wallets, funders and fleets. ChainAware works in this layer. The review of the agent trust infrastructure race compares how different providers approach agent trust, and the guide to Web3 trust verification systems maps the wider field.

How the Pieces Combine

Identity answers who. Payment protocols answer how to pay and what was allowed. Behavioral intelligence answers whether to trust. A mature KYA stack uses all three, and the weakest layer usually decides the losses.

A Practical KYA Framework

Teams can adopt KYA step by step. The five-step framework below suits protocols, marketplaces, payment firms and platforms.

Step One: Inventory Agent Touchpoints

List every place where an agent can act on your system: registration, API calls, payments, trades, listings, votes and claims. Each touchpoint needs a decision rule. Many teams discover touchpoints they had not planned for, so the inventory itself pays off.

Step Two: Define What Agents May Do

Write down allowed actions, limits and conditions. Separate low-risk actions, such as reading public data, from high-risk actions, such as moving funds. Low-risk actions may need only a registration check. High-risk actions deserve the full stack.

Step Three: Gather the Three Layers of Evidence

Collect identity evidence (registry entries, credentials), authorization evidence (mandates, tokens, scopes) and behavioral evidence (owner, feeder, creator, fleet). Normalize the outputs so that the policy engine can read them. The free tier of the Agent Trust Score makes the behavioral piece easy to test.

Step Four: Map Evidence to Decisions

Turn evidence into rules. Start with tiers and flags, then add product-specific rules. The table below shows an example for a platform that handles payments.

Flags adjust the defaults. Rug pull history on a feeder or a creator should lead to the strongest response. An unknown feeder should lead to lower limits and closer monitoring. A farm flag should trigger operator-level aggregation.

Step Five: Monitor, Store and Improve

Re-score agents on a schedule. Store the evidence and the decision for every action. Track approval, dispute and incident rates by tier. Adjust thresholds with data. A KYA process that stays static falls behind, as the tracker swings show.

KYA by Role

Different teams use KYA differently. The sections below describe the needs of each.

Protocols and DApps

Protocols that accept agent interactions face fleets, sybil attacks and incentive farming. Screening wallets before they interact beats simulating transactions alone. The guide to Web3 fraud detection for DApps explains the approach, and the overview of Web3 Sybil protection systems covers fleet defenses. Compliance-minded teams can consult the compliance guide for DeFi.

Agent Marketplaces and Directories

Marketplaces list agents for users to hire or call. A directory that lists every registered agent without a trust view exposes users to farms and fraud. Showing tiers and flags next to each listing helps users choose and rewards honest operators.

Payment Providers, Acquirers and Merchants

Payments teams carry the visible liability. They need credentials, mandates and a behavioral tier for every agent purchase, plus an evidence store for disputes. Our articles on agentic commerce fraud and checkout verification give detailed designs.

Exchanges and Regulated Platforms

Regulated firms add sanctions and anti-money-laundering duties. The Financial Action Task Force publishes guidance on virtual assets, and the U.S. Treasury maintains the OFAC sanctions list service. These duties apply whether a person or an agent initiates a transfer. Tools such as ChainAware Investigation produce a structured wallet report in about a minute, and the page on autonomous compliance screening shows how screening and agents work together.

Investors and Allocators

Investors who delegate capital to trading agents need to know who stands behind them. The guide on how investors should evaluate AI trading agents shows how behavioral evidence supports due diligence. Funding chains and creator records matter most when capital is at stake.

Growth and Acquisition Teams

Growth teams use agents to reach users, while attackers use agents to farm incentives. Behavioral scoring separates real users and honest agents from farms. The page on Web3 user acquisition shows how behavioral data supports targeting.

Agent Builders and Operators

Builders face verification from the other side. A well-run operator benefits from a clean record, because it earns higher limits and smoother access. Practical steps include funding from transparent sources, avoiding mass registration, keeping mandates narrow and checking your own score before others do.

How KYA Works in Four Short Scenarios

The scenarios below are invented to illustrate reasoning. They do not describe real incidents.

Scenario One: The Lending Protocol

A lending protocol lets agents borrow against collateral. Moreover, a new agent arrives with a valid registration. KYA finds that the owner wallet is clean but funded by an unknown source, and that the agent belongs to a farm of dozens of linked agents. The protocol assigns a low tier, caps the loan size and aggregates exposure across the farm. A naive system would have treated each agent as independent and allowed the full loan size many times over.

Scenario Two: The Agent Marketplace

A marketplace lists a research agent that claims strong performance. Feedback entries look positive. KYA reveals that most feedback comes from newly created wallets that share a funder with the agent’s owner. The marketplace flags the listing and shows the tier next to the reviews. Users see the context and choose accordingly.

Scenario Three: The Online Store

An online store accepts agent checkout. Furthermore, an agent buys ten gift cards under a valid mandate. The operator holds the Elevated Risk tier and carries the FEEDER_UNKNOWN flag. Likewise, the store applies a small limit for the tier, asks the user to confirm and avoids a likely chargeback.

Scenario Four: The Treasury Agent

A DAO considers handing a treasury task to an agent. Due diligence checks the creator record, the funding chain and the fleet links. The creator shows a prior rug pull. Beyond that, the DAO declines and picks another agent. The check took minutes and prevented a major loss.

What the Scenarios Share

In each scenario, identity and authorization were in order, and behavioral evidence made the difference. That pattern recurs across the series, and it explains why KYA needs the third layer.

Why Behavioral Signals Work

Behavioral signals work because they are costly to fake at scale. A passport can be forged once and used a thousand times. By contrast, a clean funding history cannot be forged cheaply, because it requires real transactions with real counterparties over time. Therefore, behavior carries information that identity cannot.

The Economics of Evasion

Attackers respond to costs. When registration costs a few cents, attackers register thousands of agents. Moreover, when a clean history costs weeks of activity and real funds, attackers must choose between speed and credibility. A good trust layer raises the cost of credibility without raising the cost for honest operators. In other words, honest operators already hold the evidence that a trust layer reads.

Why Funding Chains Matter

Money leaves a trail. An owner wallet that received its first funds from a verified exchange tells a different story from one funded by a mixer or a flagged address. Funders rarely change, because operators tend to reuse the same sources. As a result, a bad funder links many agents at once and exposes whole fleets with one finding.

Why Fleets Matter

Fleets distort every metric that teams rely on. Activity counts inflate, reputation scores skew and incentive programs leak value. Fleet detection also protects honest operators, because it stops farms from drowning out genuine agents. In the launch data, more than one in five agents showed farm signals, so ignoring fleets means ignoring a large part of the ecosystem.

Why Creator History Matters

Creators repeat behavior. A creator who deployed a honeypot or ran a rug pull once is more likely to do it again than a creator with a clean record. This signal is rare, and its rarity makes it powerful. When it appears, teams should treat it as a strong reason to refuse high-risk access.

Why Continuous Scoring Matters

Profiles change. Funding sources shift, ownership changes and fleets grow. The weekly tracker shows how fast the aggregate picture moves, with the median trust of new agents ranging from 918 in Week 36 to 101 in Week 41. A score computed once and cached for months would miss these shifts, so serious deployments refresh scores on a schedule.

Ten Agent Risk Patterns and How KYA Responds

Teams that understand the patterns can design better rules. The list below covers ten patterns that appear across agent ecosystems, along with a defensive idea for each.

1. The Registration Flood

An operator registers thousands of agents in a short window. The goal may be to farm incentives or to bury honest agents in noise. Fleet detection and operator-level limits respond best.

2. The Clean Front

A new agent shows a spotless owner wallet created for the purpose. Funding-chain analysis reveals the dirty source behind it. The feeder flag and the tier respond.

3. The Borrowed Reputation

An agent collects positive feedback from linked wallets. The registry shows a good score, but the feedback comes from Sybil wallets. An external trust layer evaluates the reviewers and discounts the feedback.

4. The Patient Build

An attacker runs a quiet agent for months, then abuses it. Scheduled re-scoring and drift monitoring shorten the window.

5. The Creator Recycle

A creator with a bad record deploys a new agent under a fresh wallet. Creator-level evidence links the new agent to the old record when the link exists on chain.

6. The Delegation Shell

An owner account delegates execution through EIP-7702 to hide the real actor. The EIP7702_DELEGATED flag prompts closer review, since legitimate uses also exist.

7. The Cross-Chain Hop

An operator moves activity across chains to escape history. Multi-chain coverage and wallet-level screening reduce the blind spot.

8. The Fleet Split

An operator splits a large action across many agents to stay under per-agent limits. Operator-level aggregation closes the loophole.

9. The Compromised Agent

A weak agent falls to a hostile prompt or a stolen key. Behavior suddenly changes, and anomaly rules and step-ups limit the damage.

10. The Mandate Stretch

An agent acts inside a valid but overly broad mandate. Narrow mandates, tier-based limits and confirmation prompts help.

Patterns Share a Cause

All ten patterns exploit one fact: identities are cheap and evidence about operators is hard to see without a trust layer. KYA’s job is to make that evidence visible and actionable.

Walkthrough: Auditing One Agent Step by Step

A concrete walkthrough shows how the pieces fit. The example is generic and uses no real agent.

Step One: Find the Agent

Start with the agent’s identifier or its owner wallet. The free Agent Trust Score interface accepts the lookup, and the API accepts the same inputs for automated flows. Confirm the chain, since the same operator may run agents on several networks.

Step Two: Read the Tier

The tier gives the first impression. A Sovereign or Trusted result suggests clean evidence across the four groups. In addition, a Provisional result suggests thin or mixed evidence, which is common for new agents. An Elevated Risk or Untrusted result suggests material risk signals. At this point, the decision is not final, because flags may change the picture.

Step Three: Read the Flags

Flags explain the tier. For example, FEEDER_UNKNOWN tells you that the funding source could not be traced. In addition, FARM_DETECTED tells you that the agent appears to belong to a group of linked agents. By contrast, FEEDER_CEX_VERIFIED tells you that a verified exchange funded the owner, which supports a more positive view. Rug pull flags deserve a strong response.

Step Four: Look at the Context

Context matters. A treasury action of large size needs more evidence than a small read-only request. Likewise, a flagged agent that asks for low-risk access can proceed with limits, while the same agent asking to move funds may need a decline. Match the response to the action.

Step Five: Decide and Record

Choose a response: approve, limit, step up or decline. Record the tier, the flags, the action and the reason with a timestamp. As a result, you can explain the decision later to the operator, an auditor or a dispute team.

Step Six: Schedule the Next Check

Set a re-check date. Low tiers deserve shorter intervals, and high tiers can wait longer. Moreover, set an event-based trigger for large changes, such as a new funder or a jump in fleet size.

Going Deeper When Needed

Some cases justify a deeper review. For example, a large counterparty, a compliance-sensitive transfer or an unexplained flag may call for a full wallet investigation. ChainAware Investigation turns a wallet address into a structured report, and the article on investigation reports and wallet forensics shows what the output looks like. Furthermore, the comparison of forensic and AI-based crypto analytics explains when each approach fits.

Four Approaches to Agent Trust Compared

Teams often combine approaches, but each has strengths and limits. The table below compares four common ones.

Combining the Approaches

No approach wins alone. Allowlists reward known partners with a smooth path. Blocklists stop known bad actors at once. Identity and credentials let you recognize agents and attach revocation. Registry reputation adds community signals. Behavioral scoring covers the large middle, where most new agents sit. In practice, a layered design uses all four and weighs them by action risk.

Why Behavioral Scoring Fills the Gap

New agents appear faster than humans can review them. Allowlists cannot include them yet, and blocklists have not caught them yet. Behavioral scoring evaluates them on arrival, using the history and funding that already exist on chain. For that reason, behavioral scoring is the layer that scales with open registration.

A Detailed Playbook for Tier-Based Policy

Tiers give teams a shared language. The sections below describe how to design a policy around them.

Sovereign (800-1000)

Sovereign agents show strong, clean evidence. Treat them as preferred counterparties. Offer standard or higher limits, skip routine step-ups and monitor lightly. Even so, keep the re-scoring schedule, because a change in funding or fleet links can lower a tier quickly.

Trusted (600-799)

Trusted agents show mostly clean evidence with minor concerns. Offer standard limits and review them periodically. If a flag appears, check which one, and decide whether to adjust limits.

Provisional (400-599)

Provisional agents show mixed or thin evidence. This tier includes many honest newcomers. Offer lower limits that rise with clean behavior, and ask for confirmation above a threshold. Fairness matters here: a path to a higher tier keeps good operators engaged.

Elevated Risk (200-399)

Elevated Risk agents show material risk signals. Offer small limits, require human confirmation for most meaningful actions and monitor closely. For high-resale goods or irreversible transfers, a decline is often the right default.

Untrusted (0-199)

Untrusted agents show severe risk signals. Decline high-risk actions. Allow low-risk read-only access if your system needs it, and log the attempts. Repeated attempts may justify a block.

Using Flags as Modifiers

Flags adjust tier-based defaults. The matrix below shows common adjustments.

Handling Disputes About Scores

Operators sometimes challenge a decision. A fair process includes an appeal route, a re-check of the evidence and a documented outcome. Appeals also act as a quality loop, since they reveal cases where the model or the policy needs work.

Integration Patterns

Teams integrate KYA in several ways. The pattern depends on volume, latency needs and stack.

Direct Lookup

A service calls the score for a single agent when needed. It suits low volume and simple flows. Direct lookups give the freshest result, but they add latency to each action.

Batch and Cache

A background job scores many agents on a schedule and stores results locally. Real-time decisions read from the store. This pattern suits high volume. It also supports analytics, since the store holds a history of tiers.

Agent-Native Access

Agents themselves can query trust before they transact. The Prediction MCP exposes ChainAware’s tools to AI agents, so that an agent can check a counterparty as part of its own reasoning. Furthermore, the article on Prediction MCP for AI agents explains how this works. In practice, an agent that checks a counterparty before paying behaves more safely than one that does not.

Wallet Screening Alongside Agent Scoring

Many teams already screen wallets for fraud, rug pull risk and compliance. The fraud detection API supports wallet-level checks, and the guides to rug pull detection tools and wallet auditing providers compare options. Agent scoring adds the agent layer on top of these checks.

Designing for Failure

Plan for lookup failures. A safe default is a lower limit plus a step-up, not full approval or full block. Log every fallback. Set a latency budget and monitor lookup error rates, because a control that silently fails is worse than none.

Metrics That Show KYA Works

A KYA program deserves measurement. Likewise, a small set of indicators keeps it honest.

If incident rates do not rise as tiers fall, thresholds need work. Beyond that, if step-up rates climb, the policy may be too strict. If fleet detections drop to zero for weeks, check that the detection still works.

Testing Policies Before Launch

Replay past agent activity against a new policy. Count how many actions the policy would have approved, limited or declined, then compare with real incidents. This test costs little and prevents painful surprises.

Building Your Internal KYA Capability

Organizations that treat KYA as a standing capability get better results than those that treat it as a one-off project.

Who Owns KYA?

Ownership depends on the organization. In a protocol, security or risk teams usually lead. Moreover, in a payments firm, fraud and payments engineering share the work. In a marketplace, trust and safety often leads. Whoever owns it needs authority across teams, because KYA touches product, engineering, legal and support.

Skills to Build

The core skills are policy design, data analysis, integration engineering and incident response. Policy design turns evidence into rules. Data analysis tunes thresholds and tracks metrics. Integration engineering keeps the stack reliable. Incident response handles disputes and attacks. Small teams can cover these skills with a few people, as long as someone owns each.

Tools to Assemble

A practical toolkit includes a trust score source, a verifier for credentials and mandates, a policy engine, an evidence store and a dashboard. Teams can start with spreadsheets and scripts. Later, they can move to dedicated services as volume grows. Throughout, modular interfaces keep options open.

Rituals That Keep It Alive

A short monthly meeting reviews the dashboard, the largest overrides and one lesson from a recent incident. Furthermore, a quarterly review revisits tiers, limits and flags. An annual exercise tests the stack against a simulated attack. These rituals cost little and keep the program sharp.

Evaluating KYA Providers

Providers differ widely. A short evaluation list helps buyers compare them.

1. Scope. What exactly does the product verify, and on which chains or rails?
2. Handling of newcomers. New identities: are they scored on behavior, or only after reports?
3. Fleet detection. Linked agents: does it connect them, or only score them one by one?
4. Freshness. How often does it refresh, and can you trigger a re-check?
5. Explainability. Explanations: are there tiers and named flags, or only a number?
6. Access. Does the vendor offer a free tier, an API and agent-native access such as an MCP server?
7. Limits. Limits: does it say plainly what it does not cover?
8. Privacy. Is there data minimization and a clear retention rule?
9. Evidence. Published data, such as weekly trackers, lets you check the claims.

ChainAware answers these questions in public. It publishes the launch analysis and the weekly tracker, offers a free tier and states its coverage limits. You can inspect the evidence before you buy anything.

KYA Across the Agent Lifecycle

Agents move through stages, and KYA applies at each one.

Registration

At registration, the registry records the agent. KYA can score the owner, feeder and creator on arrival, so that directories and marketplaces display trust signals from the first day.

Onboarding

When an agent connects to a service, the service decides its access. KYA sets initial limits by tier and flags. Fair paths let honest newcomers grow.

Operation

During operation, the agent acts and the service observes. KYA monitors behavior, aggregates activity by operator and re-scores on schedule. Drift and fleet growth appear in this stage.

Incident

When something goes wrong, KYA supplies evidence. Stored scores, flags and decisions show what the team knew when it acted. As a result, disputes resolve faster, and lessons feed back into policy.

Offboarding

When an agent leaves or an operator changes, KYA closes the loop. Credentials are revoked, limits are removed and records are retained for the required period. Clean offboarding prevents stale access from becoming a hidden risk.

Governance, Privacy and Fairness

KYA touches sensitive questions. Teams that plan for them early avoid costly reversals later.

Data Minimization

Collect the evidence that supports a decision and avoid collecting more. Wallet addresses and agent identifiers are pseudonymous, yet linked data can reveal patterns about people. Document what you collect, why you collect it and how long you keep it.

Explainable Decisions

Operators deserve a plain reason for each limit or decline. Tiers and named flags make explanations easy. In contrast, a black-box number without reasons weakens support, appeals and dispute defense. Explainability also helps internal teams debug policies.

Fair Paths for Newcomers

Every honest operator starts with a thin history. A policy that treats all young agents as dangerous punishes newcomers and slows the ecosystem. Offer lower initial limits that rise with clean behavior. Moreover, publish what operators can do to improve their tier, such as funding from transparent sources and avoiding mass registration.

Human Oversight

Automated decisions need human review. Sample decisions each month, review the largest overrides and keep an appeal route open. Human oversight catches model errors, and it builds trust with operators.

Change Control

Track changes to thresholds, models and rules. A change log explains shifts in approval and incident rates, and it helps audits. Without one, teams cannot tell whether a movement came from policy or from the environment.

Working With Legal and Compliance

Legal and compliance teams should review liability maps, retention rules and customer notices. In regulated sectors, they should also confirm how sanctions and AML duties apply to agent flows. The Financial Action Task Force guidance on virtual assets and the OFAC sanctions list service provide starting points. Liability for agent-initiated payments remains unsettled, and analysts differ on who should carry it, so teams should verify their own position with counsel.

Honest Limits of KYA

A trustworthy framework states what it cannot do. Several limits apply today.

Coverage. The Agent Trust Score covers on-chain ERC-8004 agents and their wallets, on Ethereum, BNB Smart Chain, Base and Avalanche C-Chain, with Mantle in progress. Agents that never touch a public chain need other behavioral sources, and closed ecosystems hold their own data.

Probability, not proof. A tier estimates risk. It cannot prove intent. Honest operators can land in lower tiers, and sophisticated attackers can sometimes reach higher ones. Teams should treat the score as one input into a policy and not as a verdict.

Funding visibility. The feeder was traceable for about 38% of indexed agents at the time of analysis. For the rest, the FEEDER_UNKNOWN flag applies. Missing evidence is itself a signal, but it is a weaker one than a confirmed bad funder.

Fast-moving targets. Attackers adapt, standards shift and new account mechanics change the signals. Models and policies need regular updates.

Intent in the user’s head. No layer proves what a user truly wanted. Mandates and confirmations come closest, and some disputes will remain.

Liability rules. Networks, regulators and courts are still working out who bears the loss in several agent flows.

Why Stating Limits Helps

Clear limits help teams design around them. A merchant that knows the score covers only on-chain agents will add card-ecosystem data for card-only agents. In addition, a compliance team that knows the score is a probability will keep a human in the loop for sensitive cases.

Common Mistakes in KYA Programs

Teams repeat a small set of mistakes. Knowing them in advance saves months.

1. Treating identity as trust. A registered agent is not necessarily a safe agent.
2. Scoring agents one at a time. Fleets hide in operator-level patterns.
3. Checking once. Profiles change, so scores need refresh cycles.
4. Ignoring the funding chain. Clean wallets can hide dirty sources.
5. Trusting registry feedback blindly. Sybil wallets can inflate it.
6. Blocking all agents. A blanket ban gives up a growing channel.
7. Approving all agents. Open acceptance invites cheap fleets.
8. Skipping evidence storage. Disputes then turn into guesswork.
9. Using vague confirmations. Users who see unclear prompts click through.
10. Ignoring fallbacks. A failed lookup needs a defined outcome.
11. Overreacting to single flags. A flag is a prompt to look closer, not a verdict.
12. Waiting for final standards. Standards arrive slowly, and agent traffic is here now.

Myths About Agent Trust

Myths slow adoption. Four deserve a direct answer.

Myth: “Agents Are Just Bots”

Bots follow fixed scripts, and agents reason and adapt. This difference matters for fraud, because agents can change tactics mid-attack. Bot defenses based on fixed signatures miss adaptive behavior.

Myth: “A Good Reputation Score Settles It”

Reputation systems record feedback. Feedback can be gamed by Sybil wallets and fleets. A trust layer evaluates the sources of feedback and the operator behind the agent, not just the numbers.

Myth: “Only Big Players Need KYA”

Small protocols and merchants face the same fleets and farms as large ones. Free tools and simple tier tables let small teams start.

Myth: “KYA Will Slow Everything Down”

Well-designed KYA runs in milliseconds for most cases and adds friction only for risky ones. Honest agents in higher tiers often move faster than before, since they earn higher limits and fewer step-ups.

Why Open Registries Need an External Trust Layer

Open registries bring real benefits. They let builders publish agents without permission, and they create a shared namespace. However, openness also means that the registry cannot judge quality on its own. A registry stores claims, and anyone can make claims.

The Registry Cannot Be Its Own Judge

A registry that tried to judge operators would need to take on gatekeeping, which defeats its purpose. Instead, the registry stays neutral, and other parties build judgment on top. Directories, marketplaces, protocols and merchants each add their own views. An external trust layer supplies common evidence so that each party does not need to rebuild the same analysis.

Shared Evidence, Local Decisions

A good trust layer separates evidence from decisions. The evidence, such as tiers, flags and funding links, is shared. In addition, the decisions, such as limits and responses, stay local. A lending protocol and an online store can read the same tier and apply different rules. In this way, the layer serves many uses without forcing one policy on everyone.

Neutral Data Builds Confidence

Neutral, published data builds confidence. When a provider publishes its analysis and its weekly trackers, outsiders can check the numbers and challenge the method. Public scrutiny improves the models, and it protects honest operators from unfair labels. For that reason, transparency is part of the product and not an extra.

Industry Snapshots

Different industries feel agent risk in different ways. The snapshots below summarize typical needs. They are illustrative and do not describe specific firms.

Decentralized Finance

DeFi protocols face farms, Sybil attacks and incentive abuse. They need fast wallet and agent screening, operator-level limits and clear policies for automated actors. Many also need compliance views for sanctioned addresses. Funds move without chargebacks, so prevention matters more than dispute.

E-Commerce and Retail

Online retailers face promotion abuse, resale fraud and disputes. They need credential checks, mandate checks and tier-based limits for agent checkout. Moreover, they also need evidence for chargebacks. Because margins are thin, even small leaks add up quickly.

Travel and Ticketing

Travel sellers face fast, high-value bookings with tight time windows. They need live confirmation for large bookings and strong credentials for agents that search at machine speed. Reliable logs help during disputes.

Software and Subscriptions

Software firms face trial abuse, license resale and renewal disputes. They need operator-level limits on trials, standing mandates for renewals and alerts for price changes.

Gaming and Digital Goods

Game studios and digital marketplaces face farming, account resale and bot economies. Agents can amplify all three. Fleet detection and tier-based eligibility for rewards protect honest players and keep in-game economies healthy.

Financial Services

Banks, exchanges and payment firms carry the heaviest compliance load. They need credentials, mandates, behavioral scores and sanctions screening, with audit trails for supervisors. The extra work protects licenses and customers.

Research and Data Services

Data providers and API platforms face scraping fleets and quota abuse. Agent-level credentials plus operator-level limits keep service quality high for honest users. Behavioral tiers help decide who receives priority access.

What the Snapshots Show

Every industry needs the same three layers, but each weights them differently. Funds that cannot be reversed lean on prevention. Industries with disputes lean on evidence. Regulated sectors lean on audit trails. KYA flexes to fit each case because it separates evidence from decisions.

Where KYA Is Heading

Several trends will shape the next two to three years.

Trend One: Trust Becomes Machine-Readable

Agents will check agents. When one agent considers paying another, it will query a trust layer first. Machine-readable trust, delivered through APIs and MCP tools, will become part of the standard agent toolkit. The overview of the Web3 agentic economy explains why this shift is underway.

Trend Two: Standards Converge

Credential formats, mandate formats and payment protocols will narrow over time. Thin adapter layers will bridge the gap while the field settles. Teams that keep modular interfaces will adapt more easily.

Trend Three: Liability Rules Firm Up

Networks, regulators and courts will clarify who bears the loss in agent-initiated transactions. Until then, teams should plan for the merchant of record to carry much of the risk, and they should store evidence that supports a defense.

Trend Four: Fleets Get Subtler

Operators will spread activity across more agents, more funders and more chains. Detection will move from single-agent signals toward operator-level and graph-level patterns. The persistence of farms in the tracker data suggests that this arms race will continue.

Trend Five: Behavioral Evidence Joins the Standard Stack

Credentials prove who, mandates prove what was allowed, and behavioral evidence estimates risk. Risk teams will treat the three as one stack, much as they treat tokens, authentication and risk scoring in card flows today.

Trend Six: Multi-Chain and Cross-Rail Coverage

Agents will use several chains and several payment rails. Trust layers will expand coverage and connect on-chain and card-based evidence. For now, each ecosystem needs its own behavioral data, and the design principle, judge the operator and its funding and fleet, carries across.

A 90-Day KYA Roadmap

Teams can move from nothing to a working program in three months.

Days 1 to 30: Discover and Baseline

Inventory agent touchpoints. Tag agent traffic in logs. Look up a sample of your agents and counterparties in the free Agent Trust Score, and record the tier mix. Read network, acquirer and regulatory guidance relevant to your sector.

Days 31 to 60: Design and Pilot

Write a one-page policy with limits by tier and responses by flag. Pilot the policy in monitor-only mode on live traffic. Compare what it would have done with what actually happened, and refine thresholds.

Days 61 to 90: Enforce and Operate

Turn the policy on for new agent activity. Start storing evidence for every decision. Launch the metrics dashboard and schedule monthly reviews. Name an owner for escalations and appeals.

After Day 90

Review quarterly. Add new chains and data sources as they become available. Share findings with partners, since shared learning raises the standard for everyone.

Questions Boards and Regulators Will Ask

Senior leaders and supervisors will ask about agent risk soon. A prepared team can answer five questions with evidence.

1. How much of our activity comes from agents? Channel tags and dashboards give the number.
2. What do agents cost us in losses and disputes? Incident data by tier gives the answer.
3. How do we know an agent may act? Credential and mandate checks give the answer.
4. How do we manage risky operators? Tier-based limits and re-scoring give the answer.
5. Who is responsible when something goes wrong? A liability map and an owner for escalations give the answer.

Written answers, kept current, turn a vague risk into a managed one. They also speed up audits, partner reviews and investor diligence.

Why Act Early

Early action has three advantages. First, baselines come cheap before volume grows, and they guide later choices. Second, early adopters shape internal norms and vendor relationships. Third, attackers target weakly defended ecosystems first, so teams with controls in place become less attractive targets.

The cost of starting is low. Moreover, the Agent Trust Score has a free tier. A simple tier table takes an afternoon to write. Evidence storage needs only a few fields. The cost of waiting is harder to see until a fleet drains a promotion budget or a bad funder reaches a treasury.

Lessons From Reading the Tracker Over Time

A single snapshot hides dynamics. Reading the weekly series side by side teaches lessons that no one report shows. Five lessons stand out for teams that design KYA programs.

Lesson One: Averages Mislead

Median trust of new agents moved from a record 918 in Week 36 to 200 in Week 40 and 101 in Week 41. Therefore, a team that tuned a policy to the Week 36 mix would have faced a very different population five weeks later. Policies should hold up across the range, not only at the average.

Lesson Two: Volume and Quality Do Not Move Together

Registrations hit 31,979 in Week 34, a record, and fell to 6,893 by Week 40 before rebounding to 10,706 in Week 41. However, quality did not follow volume in a simple way. A quiet week can bring good agents, and a busy week can bring waves of weak ones. As a result, volume alone is a poor predictor of risk.

Lesson Three: Operators Run Many Agents

Agents per owner stood at 2.54 in Week 31 and 2.30 in Week 38. In other words, the typical owner runs more than two agents. That average hides a long tail of operators with far more. Consequently, operator-level analysis catches patterns that agent-level analysis misses.

Lesson Four: Farm Shares Stay Elevated

The farm-detected share held near 17% to 19% across Weeks 32 to 34 and stood at 16.12% in Week 40. Although the share drifted lower, it stayed material. For this reason, fleet detection must stay on permanently and not run as a one-off cleanup.

Lesson Five: New Mechanics Shift the Ground

Delegated accounts grew about 33.8% between Week 35 and Week 40, and Base added 37,037 agents in Week 41. In addition, the FEEDER_UNKNOWN share reached 12.84% that week. These shifts show why models need regular updates and why coverage must expand across chains.

Why Public Trackers Matter

Public trackers let outsiders check claims. They also create a shared reference for the industry, so that teams can compare their own traffic with the wider registry. Furthermore, they build a record that lets analysts see which defenses work over time. The tracker series is available through the weekly posts, including the Week 29 report, the Week 31 report and the Week 32 report.

Questions Technical Leaders Ask

Technical leaders tend to raise the same questions. Short answers help them plan.

How much engineering effort does a first version need?

A first version is small. In addition, a lookup client, a tier table, an evidence store and a dashboard cover the basics. Moreover, the free tier lets teams test without a contract. Larger deployments add caching, batch scoring and alerting.

Where should the check run?

Teams choose between inline checks, cached pre-checks and edge gateways. Inline checks suit low volume. Cached pre-checks suit high volume. Edge gateways suit platforms with many services. In every case, keep the components modular so that you can swap parts later.

How do we avoid blocking good agents?

Use limits before blocks. Offer lower initial limits that rise with clean behavior. In addition, keep an appeal route and review a sample of decisions each month. Fair design keeps honest operators engaged.

How do we handle agents on chains we do not cover?

Fall back on wallet-level screening, conservative limits and step-ups. As coverage grows, move those agents into the standard flow. Meanwhile, log every fallback so you can see how often it occurs.

How do we prove to regulators that the program works?

Keep documented policies, stored evidence and metrics. Show approval, incident and appeal data by tier. Besides that, show change logs and review minutes. Regulators value consistent process as much as any single control.

How do we keep up with attackers?

Refresh scores on a schedule, watch for drift and review the tracker data. Additionally, run red-team exercises each year, and update rules when you learn something new. Attackers adapt, so defenders must adapt too.

Why Votes Are Not Trust: The Sybil Problem

Review-based rankings share a basic weakness. Anyone can create 50 wallets, register 50 agents and let them upvote a 51st. That is a plain Sybil attack, and a score built on votes cannot see it. The example is an illustration, yet the tracker shows that such fleets are real: 21.1% of agents carried the farm flag at launch. Votes measure what other accounts say. Behavior shows what an operator did.

ChainAware takes a different route. The Agent Trust Score uses on-chain behavior only, with no reviews, no ratings and no self-reported data. Faking a clean funding history costs real money and time, while 50 upvotes cost almost nothing. Moreover, an attacker’s own address and feeder address pass through ChainAware’s machine-learning fraud detection, so abnormal behavior lowers the score instead of raising it. Honest limits still apply: on-chain data is costly to fake, not impossible to fake, which is why the fraud models watch the attacker as well as the agent.

Why ChainAware Is Credible in This Layer

ChainAware did not start with agents. Its models analyze more than 25 million wallet addresses, more than 2.4 billion predictive data points and more than 1.8 million contracts checked for honeypots. The company reports 95% accuracy for its per-address fraud model, and anyone can verify it against public data through ScamDB. In a test on PancakeSwap on BNB Smart Chain, covering weeks 10 to 20, the rug pull model predicted 90.1% of rug pulls before they happened, as documented on the rug pull verification page. Separately, more than 940,000 rug pulls have been documented after the fact, and ChainAware covers them in its weekly rug pull news. The Agent Trust Score applies this record to agents. It predicts risk and does not rank popularity.

Key Facts at a Glance

• Know Your Agent (KYA) is the process of deciding whether an AI agent may act and how far.
• KYA combines identity evidence, authorization evidence and behavioral evidence.
• Identity shows who an agent is. Behavioral evidence shows whether to trust it.
• Registration is cheap in open registries, so fleets and bad funders pass identity checks.
• The Agent Trust Score rates ERC-8004 agents from 0 to 1,000 across five tiers: Sovereign, Trusted, Provisional, Elevated Risk and Untrusted.
• Inputs include the owner wallet, the feeder address, the creator record and fleet detection.
• At launch, 51.8% of 274,792 indexed agents sat in the Elevated Risk or Untrusted tiers, and 21.1% carried the farm flag.
• By Week 41 of 2026, 568,590 agents were indexed, and the median trust of that week’s new agents was 101.
• The score is free for public indexed agents, with 1,000 queries per month and no signup.
• Coverage today includes Ethereum, BNB Smart Chain, Base and Avalanche C-Chain, with Mantle in progress.

Frequently Asked Questions

What does KYA stand for?

KYA stands for Know Your Agent. It is the process of deciding whether an AI agent may act and how far.

How is KYA different from KYC?

KYC verifies people and companies. KYA evaluates software agents and their operators, using signals such as owner wallet history, funding source, creator record and fleet links. Agent identities cost far less to create than human identities, so KYA relies more on behavior.

Is agent identity enough for KYA?

No. Identity shows who an agent is, but it does not show whether the operator is honest. Behavioral evidence completes the picture.

What is the Agent Trust Score?

It is ChainAware’s 0 to 1,000 rating for ERC-8004 agents. Furthermore, it groups agents into five tiers and adds named flags that explain the reasons.

What are the five tiers?

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

What does the score measure?

It measures the owner wallet’s fraud probability, the feeder address that funded the owner, the creator’s rug pull and honeypot record, and fleet-level farm links.

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.

Which chains does it cover?

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

What is a feeder address?

It is the address that funded an agent’s owner wallet. The funding source reveals intent that the wallet’s own history may hide.

What is a farm or fleet?

A farm is a group of linked agents under one operator. Farms inflate activity, distort reputation and exploit incentives.

What does the FARM_DETECTED flag mean?

It means the agent appears to belong to a group of linked agents. In the launch analysis, 21.1% of agents carried it.

Can honest agents receive low scores?

Yes. New agents have thin histories and may start in lower tiers. A fair policy gives them a path to improve through clean behavior and transparent funding.

Does KYA work for card payments?

The principles carry over. Instead, the Agent Trust Score itself covers on-chain agents and wallets, so card-only ecosystems need their own behavioral data. Our articles on agentic commerce fraud and checkout verification cover the card side.

Who is liable when an AI agent causes a loss?

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

Where should a team start?

Inventory agent touchpoints, look up a sample of agents in the free tool, write a tier-based policy and store evidence for every decision.

A Short Glossary

• Agent: software that acts on behalf of a person, company or another agent.
• Operator: the person or company that runs an agent.
• KYA (Know Your Agent): the process of deciding whether an agent may act and how far.
• ERC-8004: an Ethereum standard for agent identity, reputation and validation registries.
• Agent Trust Score: ChainAware’s 0 to 1,000 rating for ERC-8004 agents.
• Tier: one of five bands of the score, from Untrusted to Sovereign.
• Feeder: the address that funded an agent’s owner wallet.
• Farm or fleet: a group of linked agents under one operator.
• Sybil attack: the use of many fake identities to gain influence or rewards.
• Mandate: a signed record of what a user authorized an agent to do.
• Payment token: a limited-use stand-in for a payment method.
• Step-up: an extra confirmation before approval.
• Drift: a gradual change in an agent’s behavior away from its intended purpose.
• Rug pull: a scam in which creators drain funds and abandon a project.
• Honeypot: a contract designed to trap funds.

Conclusion: Make Trust a Layer, Not a Hope

Agents will keep multiplying. Registration will stay cheap, and money will keep moving through machine decisions. In that world, trust cannot rest on paperwork alone. It needs evidence about who stands behind each agent, where the money came from and how many siblings the agent has.

KYA gives teams a structure for that evidence. Identity tells you who. Authorization tells you what was allowed. Behavioral evidence tells you whether to trust. Together, they let teams welcome good agents, limit uncertain ones and refuse bad ones, with a record for every decision.

Start small. Look up a few agents today, write a one-page tier policy this week and store evidence from the first day. Then expand coverage, tune thresholds and share what you learn.

To go deeper, read the rest of the series: KYA versus agent identity, ERC-8004 trust signals, funding-chain risk, agent fraud patterns, agentic commerce fraud and checkout verification. Teams that want to see how an agent fleet applies these ideas can read about ChainAware’s 32 Claude sub-agents, and teams that need deep wallet reviews can look at the ChainAware investigation reports.

The post Know Your Agent (KYA): The Behavioral Trust Layer for AI Agents first appeared on ChainAware.ai.