Know Your Agent Explained: Identity, Permission, and Fraud Risk Are Different Questions

TL;DR

• Identity asks which agent initiated the transaction and which verified person or business owns it.
• Authorization asks who delegated authority and what permissions, spending limits, or purchase categories govern the agent.
• Conduct asks whether the specific transaction complied with that mandate. Current KYA tooling largely focuses on identity and authorization signals rather than independent evidence of transaction-level compliance.
• Know Your Agent already names an emerging product category. Prove (opens in a new tab), Persona (opens in a new tab), and Trulioo with PayOS (opens in a new tab) each use KYA in their public positioning.

What “Know Your Agent” means and why it exists

Know Your Agent, or KYA, describes controls for identifying an AI agent, linking it to a responsible principal, and evaluating its delegated authority. The term already appears across separate vendor offerings. Prove (opens in a new tab) focuses on verified owner binding and session integrity, while Persona (opens in a new tab) connects agents to verified humans at onboarding and during higher-risk actions. Trulioo and PayOS (opens in a new tab) extend the category through developer verification, code checks, user consent, and transaction validation.

KYA remains an emerging category rather than a settled standard. Vendors differ in what they verify and when they verify it. Some offerings concentrate on the human or business behind an agent. Others add consent records, software integrity, session security, or continuing risk checks.

KYC and KYA evaluate different actors. KYC establishes the identity of a person or business and may continue with screening and account monitoring. KYA adds a delegated software actor whose authority can change between transactions. A verified customer might authorize an agent to buy a flight below $800 today, then revoke that authority tomorrow.

Agent transactions also separate the customer from the moment of purchase. The customer may be absent when the agent chooses a merchant, accepts terms, or submits payment. A merchant therefore needs evidence about the agent and the instruction behind its current request.

Experian frames agent trust (opens in a new tab) through identity, authorization, and intent. Its intent question asks whether the requested transaction falls within what the person authorized. That framework supports a precise definition of KYA as an umbrella for determining who an agent represents, what authority it received, and whether its requested action fits that authority.

The three questions that get conflated under “verify the agent”

Risk teams create blind spots when they treat a positive answer to one verification question as an answer to all three.

• Identity. Which agent submitted the request, and which verified person or business owns or operates it? Identity evidence can include human verification, business verification, software credentials, and secure agent-to-session binding.
• Authorization. What did the principal permit the agent to do? A useful mandate defines limits such as spending amount, merchant category, approved counterparties, duration, and conditions requiring fresh approval.
• Conduct. Did the specific transaction remain within those limits? Conduct checking compares the actual purchase against the current mandate, including its amount, merchant, timing, and other applicable restrictions.

Verified ownership does not establish permission for every purchase. A valid mandate also does not establish that an agent followed it. Each question requires its own evidence, and later sections examine those evidence trails separately.

Identity: which agent is this, and who owns it

Identity verification establishes which agent is making a request and who stands behind it. A merchant can use that evidence to distinguish an agent linked to a verified customer or business from an unbound script or impersonator. Verified ownership supports attribution and reduces impersonation risk, but it cannot establish whether a particular purchase followed the owner’s instructions.

Prove uses its Identity Graph (opens in a new tab) to connect an agent with a verified person and device. Prove also authenticates delegated authority and checks session integrity through signed requests. A merchant can therefore assess whether the request came through the expected agent relationship rather than a spoofed or hijacked session.

Persona approaches the linkage through human identity checks (opens in a new tab). Its KYA workflow can combine a government ID with a selfie and liveness check, while Relay and passive device, network, and behavioral signals provide further evidence. Persona applies these checks during onboarding and can reverify the human behind an agent before a higher-risk action.

Both approaches provide meaningful identity evidence. Neither type of evidence, by itself, determines whether the owner allowed this merchant, product category, or purchase amount. Authorization and transaction-level conduct require separate checks.

Authorization: what the agent is actually permitted to do

Authorization defines the actions an identified agent may take for its owner. A useful mandate specifies limits such as permitted merchants, purchase categories, payment instruments, spending caps, and conditions that require human approval. Identity verification can connect an agent to a genuine owner, but that connection does not reveal whether the owner approved a particular purchase.

AP2 treats authorization as a distinct protocol problem (opens in a new tab). Its documentation asks how a merchant can verify specific authority, confirm that a request reflects the user’s intent, and assign accountability when a transaction goes wrong. AP2 records authority through signed checkout and payment mandates. Open mandates capture constraints before the agent finalizes a purchase. Closed mandates bind approval to a finalized checkout or transaction amount, creating a tamper-evident audit trail.

Payment settlement protocols can operate without defining those permissions. x402 handles how a payment request is priced, communicated, and settled (opens in a new tab), while the wallet decides whether the agent may spend and whether to sign the transaction. A valid x402 payment therefore proves that settlement requirements were met. It does not by itself prove that the purchase fit the owner’s mandate.

Trulioo and PayOS apply similar permission scoping through an Agent Consent Authority. A user can set weekly caps, restrict merchants, revoke consent, or require approval above a threshold. PayOS can pause an unusual request and ask the user to confirm it.

These approaches give merchants evidence that an agent received current, scoped authority. Standing mandates still create a separate question for each transaction. The merchant must determine whether the agent’s actual purchase stayed inside those recorded limits.

Conduct: did this specific action stay inside the mandate

Conduct verification asks whether the proposed purchase satisfies the agent’s current mandate. A valid identity and active permission can coexist with an off-mandate order. For example, an agent authorized to spend $500 on office supplies may attempt a $450 purchase from a merchant outside the approved category.

Trulioo and PayOS describe four continuous-monitoring scenarios in their KYA white paper. Business-risk monitoring watches developers and beneficial owners for sanctions or risk changes, then revokes their Digital Agent Passports when needed. Corporate-registry monitoring updates records after ownership changes, relocations, or mergers. Software monitoring compares each agent build with an approved code fingerprint. Consent monitoring invalidates the passport when a user withdraws permission.

Each scenario checks a necessary condition for trust, but none produces independent evidence that a specific order satisfied its numeric and categorical limits. PayOS can check whether permission remains active, apply trust thresholds, and request fresh approval for an unusual purchase. Those controls gate authorization. They do not give the merchant a cryptographic receipt showing that the order amount, merchant, and product category matched the mandate.

The white paper also says an agent’s trust score “drops on chargebacks and policy breaches.” Chargebacks and recorded breaches provide useful behavioral signals after a problem surfaces. They cannot prove at execution that an individual purchase complied with the user’s policy.

Inherence (opens in a new tab) covers this conduct layer by evaluating defined policy before execution. It blocks an action that violates limits and produces a cryptographic receipt for an action that passes. A merchant, payment provider, or other counterparty can verify the receipt independently. Zero-knowledge proofs can confirm compliance without revealing private thresholds or transaction details.

Inherence complements identity and authorization providers rather than replacing them. Identity vendors establish who stands behind the agent, and consent systems record what the principal permitted. Inherence binds those policy conditions to the specific action before value moves and supplies evidence that the check occurred.

Why a verified owner doesn’t make an agent’s purchase low-risk

Experian treats unauthorized agent transactions as a distinct risk category from impersonation and account takeover. A legitimate agent can act outside the scope (opens in a new tab) of what its owner intended or authorized, even when neither the owner nor the agent was created for fraud.

A fully KYC-verified customer might authorize an agent to buy an airline ticket for up to $800. If the agent buys a $1,200 ticket, the verified identity still establishes who owns the agent, but it does not make the purchase compliant with the mandate. Ambiguous instructions, software errors, or unexpected agent behavior can produce the same failure without dishonest intent from the customer.

Compromise creates another failure path. An attacker might hijack an agent that belongs to a genuine customer, or altered credentials might let the agent request purchases outside its approved categories. The owner’s identity remains valid throughout the incident. Risk controls must therefore check whether the current agent and transaction still match the owner’s permission.

Treating every unfamiliar agent as an anonymous stranger discards useful evidence. Verified owner linkage can reduce impersonation risk, support accountability, and connect the transaction to an established customer or business. Merchants should use that linkage as one input, then separately verify the agent’s current authority and the transaction’s compliance with its mandate.

What a merchant or payment provider should check before fulfilling an agent order

• Verify the agent’s linkage to a principal. An identity vendor should bind the agent or its signing key to a verified person or business. Your risk check should confirm that the credential remains valid and has not been revoked. A verified owner supplies useful identity evidence, but it does not establish that the order follows the owner’s instructions.
• Confirm a scoped and current mandate. An authorization protocol should show what the principal permitted the agent to do. The mandate should cover the proposed purchase amount and counterparty, where applicable. Your payment flow should also check expiration, revocation status, and any requirement for fresh human approval.
• Require evidence that the order satisfied the mandate. A conduct-verification layer should evaluate the actual transaction against the applicable limits before execution. A signed request proves which agent sent the request, but the signature alone does not prove policy compliance. Inherence (opens in a new tab) offers one approach through pre-execution enforcement and a cryptographic receipt that a merchant or payment provider can verify independently. Its zero-knowledge receipt can confirm compliance without exposing private policy inputs. Other implementations may use different evidence, but the verifier should be able to connect the evidence to the specific order and policy version.

FAQ

Is KYA a regulatory requirement yet?

No general regulation currently names KYA as a mandatory control. Prove’s public roadmap (opens in a new tab) describes an emerging industry category built across several developing standards, rather than a settled regulatory framework.

How does KYA relate to AP2 and x402 mandates?

KYA establishes who controls an agent and whether its credentials are genuine. AP2 (opens in a new tab) adds signed checkout and payment mandates that record user intent, while x402 integrations still need separate evidence about identity and permitted spending.

Does KYA replace KYC?

No. KYC verifies the human or business principal, and KYA binds an agent to that verified principal while recording delegated authority. A risk program still needs the underlying customer or business verification.

Can a KYA-verified agent still commit fraud?

Yes. Valid identity and delegation do not prove that every action complied with the mandate. Experian distinguishes (opens in a new tab) identity, authorization, and intent because a legitimate agent can request a transaction outside the owner’s approved scope.

The takeaway for risk teams evaluating agent traffic

A mature agent-risk program can answer three questions with three separate evidence trails. Identity evidence links the agent to a verified person or business. Authorization evidence records the authority that principal granted. Conduct evidence shows whether each covered action followed the applicable limits.

Risk teams building these controls over the next year should treat missing evidence as an unresolved diligence question, rather than inferring an answer from another layer. A verified owner cannot establish mandate compliance, and a signed mandate cannot establish that later actions stayed within it. Completion requires all three answers at transaction time, with records that relevant counterparties can verify independently.