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

TL;DR

Know Your Agent (KYA) is a category of controls for identifying an AI agent, linking it to a verified person or business, defining its delegated authority, and checking whether a requested action falls within that authority.

• Identity asks which agent initiated the transaction and which verified person or business is responsible for it.
• Authorization asks who delegated authority to the agent. It also identifies the applicable permissions, spending limits, and purchase categories.
• Conduct asks whether the requested transaction falls within the mandate. The providers reviewed in this article focus primarily on identity, authorization, and risk signals. Inherence addresses pre-execution policy enforcement and independently verifiable evidence for covered actions.
• KYA is an emerging product category used in the public materials of Prove (opens in a new tab), Persona (opens in a new tab), and Trulioo with PayOS (opens in a new tab).

What “Know Your Agent” means and why it exists

KYA addresses a problem created by delegated software actors. A merchant may know the customer while lacking evidence about the agent that submitted a request or the authority behind that request. Public KYA offerings address different parts of this problem. Prove (opens in a new tab) describes owner binding and session integrity. Persona (opens in a new tab) connects agents to verified people during onboarding and higher-risk actions. Trulioo and PayOS (opens in a new tab) describe developer verification, software 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 person or business responsible for an agent. Others address consent records, software integrity, session security, or ongoing risk checks.

Provider taxonomy for KYA controls

The providers and protocols cited here can be grouped by the function described in their public materials. Functions may overlap. Placement in one row does not imply that a provider replaces the controls described in another row.

KYA versus KYC

KYC and KYA evaluate different actors. KYC establishes the identity of a person or business. Applicable programs may also include screening and ongoing monitoring. KYA addresses the delegated software actor, its link to that principal, and its current authority. For example, a verified customer could authorize an agent to buy a flight below $800 and later revoke that authority.

An agent transaction may occur without the customer participating at the moment of purchase. The agent may choose a merchant or submit a payment while acting under earlier instructions. A merchant therefore needs evidence about the agent and the authority supporting the current request.

Experian describes agent trust (opens in a new tab) in terms of identity, authorization, and intent. Its intent question concerns whether the requested transaction falls within the person’s authorization. This article uses conduct for the transaction-level question because the available evidence can establish policy compliance without establishing an agent’s internal intent.

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

A positive answer to one verification question does not answer the other two.

• Identity. Which agent submitted the request? Which verified person or business is responsible for it? Evidence may include person or business verification, software credentials, and secure agent-to-session binding.
• Authorization. What did the principal permit the agent to do? A mandate may specify a spending limit, approved counterparties, a duration, or a condition requiring fresh approval.
• Conduct. Does the requested transaction remain within those limits? Conduct verification compares the proposed action with the current mandate and its 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 acting, and who is responsible for 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 describes its Identity Graph (opens in a new tab) as a way to connect an agent with a verified person and device. Prove also describes signed requests for delegated authority and session-integrity checks. These signals can help a merchant assess whether a request came through the expected agent relationship.

Persona describes a KYA workflow (opens in a new tab) that connects an agent to a verified person. The workflow may combine a government ID with selfie and liveness checks. Persona also describes Relay, device signals, network signals, and behavioral signals as additional evidence. Checks may occur during onboarding or 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 addresses how a merchant can verify an agent’s specific authority. AP2 uses signed checkout and payment mandates to record that authority. Open mandates record constraints before an agent finalizes a purchase. Closed mandates bind approval to a finalized checkout or transaction amount. The signed records provide a tamper-evident audit trail.

A payment protocol does not necessarily define an agent’s authority. MetaMask’s explanation of x402 (opens in a new tab) describes how the protocol communicates payment requirements and supports settlement. The wallet separately decides whether to sign a transaction. Successful payment does not establish that the purchase fell within the principal’s mandate.

Trulioo and PayOS describe (opens in a new tab) permission scoping through an Agent Consent Authority. Their public materials say a user can set weekly caps, restrict merchants, revoke consent, or require approval above a threshold. They also describe a PayOS control that can pause an unusual request for user confirmation.

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 (opens in a new tab) four ongoing-monitoring scenarios. Business-risk monitoring checks developers and beneficial owners for sanctions or risk changes. Corporate-registry monitoring checks for changes in business records. Software monitoring compares an agent build with an approved code fingerprint. Consent monitoring responds when a user withdraws permission. Their materials say these changes can affect the status of a Digital Agent Passport.

These scenarios address identity, software, consent, or risk status. The cited materials do not describe an independently verifiable cryptographic receipt that binds a specific order to its applicable numeric and categorical limits. PayOS separately describes permission checks, trust thresholds, and requests for fresh approval.

The Trulioo and PayOS materials (opens in a new tab) also say an agent’s trust score “drops on chargebacks and policy breaches.” Those events provide retrospective behavioral signals. They do not establish before execution that an individual purchase satisfies the user’s policy.

Inherence (opens in a new tab) provides pre-execution policy enforcement and independent verification for covered agent actions. It evaluates defined policy conditions within an enforcement path before execution. An action that fails those conditions is blocked within that path. An action that passes can produce an independently verifiable cryptographic receipt. A zero-knowledge proof can verify satisfaction of the committed policy conditions without disclosing the protected inputs encoded in the proof.

Inherence complements identity, authorization, fraud, screening, and investigation providers. Its evidence applies to covered actions routed through the defined enforcement path and evaluated against committed or attested inputs. Inherence does not independently establish the truth of every external input. It also does not cover actions executed outside that path. Identity providers establish who is responsible for an agent. Authorization and consent systems record what the principal permitted. Fraud, screening, and investigation providers address separate risk functions.

Why verified ownership does not establish transaction compliance

Experian distinguishes (opens in a new tab) unauthorized agent transactions from impersonation and account takeover. A legitimate agent can request an action outside the principal’s authorization even when the principal did not intend 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.

Account or credential compromise creates a separate problem. An attacker could hijack an agent linked to a genuine customer. Stolen or altered credentials could also support requests outside the approved scope. The principal’s verified identity would not establish that those requests were authorized. Controls must therefore check the current credential, mandate, and proposed transaction.

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.

Merchant verification flow for an agent order

1. Verify the agent’s linkage to a principal.
   Use identity evidence to bind the agent or its signing key to a verified person or business. Confirm that the credential is valid and has not been revoked. This establishes the agent’s linkage, not whether the order follows the principal’s instructions.
2. Confirm a scoped and current mandate.
   Check the authority granted to the agent. Applicable fields may include the amount, counterparty, purchase category, expiration, revocation status, or requirement for fresh human approval.
3. Match the mandate to the proposed order.
   Compare the order’s amount, merchant, category, timing, and other applicable conditions with the current mandate. A signed request identifies its sender but does not by itself establish policy compliance.
4. Verify conduct evidence before fulfillment.
   Require evidence tied to the specific order and applicable policy version. For covered actions routed through the defined enforcement path, Inherence (opens in a new tab) evaluates committed policy conditions before execution. An action that passes can produce an independently verifiable cryptographic receipt. A zero-knowledge proof can verify those conditions without disclosing the protected inputs encoded in the proof. Other implementations may use different forms of evidence.
5. Apply the remaining risk controls.
   Use applicable fraud, sanctions screening, payment, and investigation controls separately. Conduct evidence complements these controls and does not replace them.

FAQ

Is KYA a regulatory requirement yet?

KYA is an emerging industry category rather than a single regulatory framework. Prove discusses KYA (opens in a new tab) in relation to several developing standards and protocols. A company must assess the laws and regulatory requirements that apply to its activities and jurisdictions. The KYA label does not by itself define a legal obligation.

How does KYA relate to AP2 and x402 mandates?

KYA is the broader category for controls concerning agent identity, principal linkage, delegated authority, and covered actions. AP2 (opens in a new tab) defines signed checkout and payment mandates that can record delegated authority. x402 communicates payment requirements and supports settlement. Separate controls establish agent identity and spending authority.

Does KYA replace KYC?

No. KYC verifies the human or business principal. KYA adds controls for the AI agent acting for that principal, including agent linkage, delegated authority, and transaction-level conduct where applicable. A KYA program therefore depends on, and does not replace, the underlying customer or business verification.

Can a KYA-verified agent still commit fraud?

Yes. KYA evidence may establish an agent’s identity, principal linkage, or delegated authority without establishing that every action is legitimate or within scope. Experian distinguishes (opens in a new tab) identity, authorization, and intent. Its framework recognizes that a legitimate agent can request a transaction outside the principal’s approved scope. Fraud detection, screening, transaction controls, and investigation remain separate functions.

Evaluation criteria for agent transactions

An agent-risk program should maintain separate evidence for identity, authorization, and conduct. Identity evidence links an agent to a verified person or business. Authorization evidence records the authority granted by that principal. Conduct evidence addresses whether a covered action satisfied the applicable limits.

Missing evidence in one category should not be inferred from evidence in another. Verified principal identity does not establish compliance with a mandate. A signed mandate does not establish that a later action remained within its limits. For covered actions, the relevant decision-maker should obtain identity, authorization, and conduct evidence at the applicable decision point. Records should support independent verification where the underlying control provides it.