KYA vs Agent Identity: Why Knowing Who an AI Agent Is Does Not Tell You Whether to Trust It

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.

Term	Question it answers	Typical output
Agent identity	Who or what is this agent?	A record, identifier or token
Authentication	Does this party really hold that identity?	A pass or fail on a signature or credential
Authorization	What did the owner or user allow?	A signed scope, limit or mandate
Reputation	How has this agent behaved?	Feedback, a score or a history
Know Your Agent	May this agent act, and how far?	A decision: allow, limit, monitor or block

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.

Dimension	Agent identity	Know Your Agent
Core question	Who is this agent?	May this agent act, and how far?
Output	A record, credential or token	A decision and a limit
Time frame	Point in time, updated rarely	Continuous, re-evaluated
Evidence	Documents, signatures, registration data	Identity plus authorization, integrity and behavior
Failure mode	Fake or stolen credentials	Over-trusting a verified but risky agent
Typical owner	Identity provider or registry	Risk, compliance and security teams
Cost to fake	Low in open registries	Higher, because behavior leaves a history

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.

Tier	Score	Suggested use
Sovereign	800-1000	Full autonomous access, including large-value lending or treasury management
Trusted	600-799	Standard integrations, with monitoring available
Provisional	400-599	Monitoring required, low-risk workflows only
Elevated Risk	200-399	Restricted: size limits, velocity caps and real-time monitoring
Untrusted	0-199	Block at the access control layer

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.

Flag	What it means	Typical reading
FARM_DETECTED	The agent belongs to a group with shared funding or ownership patterns	Treat the whole group as one risk unit
FEEDER_CEX_VERIFIED	A verified exchange funded the owner	Strongest positive funding signal
FEEDER_UNKNOWN	The source of funds could not be traced	Apply limits and monitoring
FEEDER_RUG_HISTORY	The feeder has confirmed rug pull history	Hard suppression of the score
CREATOR_RUG_HISTORY	The creator wallet has a rug pull record	Strong negative
CREATOR_HONEYPOT_HISTORY	The creator wallet deployed honeypot contracts	Strong negative
EIP7702_DELEGATED	The owner account delegates execution to contract code	Look closer, not a verdict

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.

Tier	Share of agents at launch
Sovereign	20.9%
Trusted	12.7%
Provisional	14.6%
Elevated Risk	25.8%
Untrusted	26.0%

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.

Week	New registrations	Median trust of new agents	Note
34	31,979	563	Record weekly registrations
36	24,173	918	Record median, first in Sovereign tier
38	17,001	200	Agents per owner reached 2.30
40	6,893	200	Farm share 16.12%, 518,885 agents indexed
41	10,706	101	Lowest median since Week 5, 568,590 agents indexed

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.

Action requested	Minimum tier	Extra conditions
Read-only data access	Provisional	Rate limits
Small payments or swaps	Provisional	Per-transaction cap, velocity cap
Standard integrations	Trusted	Monitoring enabled
Vault or lending access	Sovereign	No farm flag, no unknown feeder
Treasury permissions	Sovereign	Human approval above a threshold

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.