Know Your Agent (KYA): What It Proves, What It Misses, and the Controls AI Agents That Spend Still Need

Know Your Agent (KYA) is the verification of an AI agent's identity: which agent is acting, who built and operates it, and which person or business it claims to act for. KYA is the agent version of Know Your Customer, and like KYC it answers "who?" It does not answer "is this action allowed?", "how much may it spend?" or "can we prove what happened?" Those need four more controls: authorization, risk limits, compliance mapping and an audit record.

If agents have started arriving at your checkout, your APIs or your payment flows, this guide covers what KYA gives you today, where it stops, and what to put on top of it before an agent is allowed to move money. If you already know where your gaps are, talk to us.

Key takeaways

• KYA tells you which agent is acting and for whom. It is necessary, and it is an onboarding step, not a control on each action.
• Many agent failures involve no impostor at all, just verified agents doing something nobody approved. In one 2025 survey, 80% of organisations said their agents had already taken unintended actions.
• After KYA come four controls: authorization (what the agent may do), risk limits (how much, how often), compliance (which rules apply) and audit (proof of each decision, including refusals).
• US law has not decided who pays when an agent exceeds its mandate. Regulation E may leave the consumer liable if they gave the agent their credentials.
• The evidence that holds up is a signed record of every decision, kept by a party with no stake in the outcome.

What is Know Your Agent (KYA)?

Know Your Agent (KYA) is the process of establishing, before an AI agent is trusted, three facts: which agent this is, which company operates it, and which person or business it acts for. KYA borrows its shape from Know Your Customer and, like KYC, mostly runs once, when an agent registers or first presents itself. No law requires KYA yet.

The three facts KYA establishes are:

1. The agent. Which piece of software this is, and whether it is the same one you saw last time.
2. The operator. Which company built and runs it, and whether that company is accountable.
3. The principal. Which person or business the agent says it acts for, and whether that claim is true.

KYA is industry practice that payment networks, identity vendors and standards bodies are converging on. It is not a rule with a compliance date anywhere.

How does Know Your Agent work today?

Know Your Agent works today through four methods, often combined. A card network registers the agent and issues it tokenised credentials. The agent signs every web request. The customer grants the agent scoped access through OAuth sign-in. Or the agent's identity is published to a public on-chain registry. No single KYA standard exists.

Each method answers "who is this?" well. A merchant checking signed requests can tell a known shopping agent from a scraper. A card network that issued the agent's token knows which cardholder stands behind it. That removes a whole class of fraud: the impostor agent.

But an impostor is only one way an agent payment goes wrong. For a side-by-side of the protocols these methods come from, see Agentic Commerce Protocols Compared.

What does Know Your Agent not cover?

Know Your Agent does not decide whether a specific action is allowed, how much an agent may spend, who approves anything above a threshold, what happened when an action was blocked, or who pays when the agent is wrong. KYA names the agent. A verified agent can still overspend, pay a fraudulent account or follow an injected instruction.

Picture a fully verified agent. Its operator is known, its signature checks out, its token is valid, and it really is acting for your customer. That agent can still:

• buy the wrong item, or forty of the right one,
• pay a supplier whose bank details were changed by a phishing email the agent believed,
• spend this month's budget in an afternoon,
• act on an instruction injected into a web page it read.

In every case the identity record is accurate. It correctly names the agent that did the wrong thing.

These failures are common. In a SailPoint survey of 353 IT professionals published in May 2025, 80% said their organisation's AI agents had performed unintended actions. 23% said agents had revealed access credentials, and 16% said agents had inappropriately ordered something (CFO Dive, Jun 2025).

The OWASP Top 10 for Agentic Applications for 2026 ranks "Agent Goal Hijack" first and "Identity and Privilege Abuse" third. The danger OWASP describes is a legitimate identity doing illegitimate things.

Key takeaway: KYA removes the impostor. It does nothing about a trusted agent making an untrusted move.

What controls come after Know Your Agent?

Four controls come after Know Your Agent: authorization, which defines what the agent may do for whom; risk limits, which cap how much and how often; compliance, which maps each action to existing obligations; and audit, which proves each decision, including refusals. Banks use the same split: KYC for who, transaction monitoring for what.

Authorization: the mandate

AI agent authorization starts with a mandate: a clear statement of what the agent may do, for whom, within what limits, until when. "Handle our SaaS renewals" is an instruction. "Renew only vendors on this list, up to $2,000 each and $10,000 a month, and send anything else to the IT director" is a mandate.

Only the mandate can be checked. It should be written by the person accountable for the agent and confirmed as exact rules, not as a sentence a model has interpreted. It should also be versioned, so "what were the rules on 14 March?" always has an answer.

Agentic payment standards are moving the same way. Google's AP2 records a user's instruction as a signed "intent mandate." Mastercard's Verifiable Intent links the consumer's identity, their instruction and the transaction outcome in one tamper-resistant record (PYMNTS, Mar 2026).

Both standards cover purchases made through the flows that adopt them. A business whose agents also pay suppliers, renew software or issue refunds needs the same mandate discipline for those actions.

Risk limits: enforced before the action, not reported after

A limit reported after the money has moved is a finding, not a control. Agent risk limits need to run at the moment of action, every time. They also need to sit outside the agent, because the agent is the thing that can be tricked.

Buyers usually ask for the same limits first: a per-transaction cap, a daily or monthly ceiling, an allowlist of counterparties, a hold on payments to new or changed bank details, and a named human for anything above a threshold.

Consumers want similar protections. In Checkout.com research reported in July 2026, the safeguards shoppers most wanted before letting an agent buy were spending caps (30%) and instant revocation (29%) (Forkast, Jul 2026).

Compliance: map controls to obligations you already have

Most companies do not need a new compliance framework for agents. They need their existing obligations to keep working when the actor is software. Segregation of duties, approval matrices, sanctions screening and record retention all assume a named human at the decision point.

When an agent both proposes and executes a payment, maker-checker collapses into one step, unless the approval sits somewhere the agent cannot reach. The compliance question for each agent is therefore practical: which existing controls does this agent touch, and where does each one now run?

Audit: the refusal is the evidence

Auditors test whether a control operated, not just whether it was documented. The record that proves a control operated is the refusal: the agent tried something, the check stopped it, and the evidence shows it.

Most systems record approvals and discard refusals. Most also keep logs on infrastructure run by the same company that runs the agent, which makes the log testimony from the party being tested.

An AI agent audit trail that holds up needs four properties. It covers allows and denials. It names the rule and mandate version behind each decision. It is signed. And someone who does not trust your systems can verify it.

Key takeaway: KYA is one control out of five. Authorization, limits, compliance mapping and audit are the four that decide whether a verified agent's action should happen.

Know Your Agent in practice: one verified agent, five decisions

The worked example below shows a fully verified agent, with known operator, valid credentials and a real principal, making five payment attempts in one day. KYA passes all five. The mandate check allows two, routes one to a human and blocks two, and the blocked ones are where the losses would have been.

The agent handles software renewals for a finance team. Its mandate: approved vendors only, up to $2,000 per renewal, $10,000 a month, anything above $2,000 goes to the IT director, and no payment to changed bank details until confirmed. It has spent $6,500 this month.

Identity was perfect in all five rows. The fourth row is a classic payment-redirection attempt. The agent believed the email, and only a rule outside the agent stopped it. The receipt for that refusal:

decision:  deny
rule:      bank_change
passed:    vendor, per_order, monthly_cap
version:   4
receipt:   0x91d3…a7c2

The receipt records more than "denied". It records which rule failed, which rules passed, and which version of the mandate was in force. The disputes team, the auditor and the vendor can all read the same record.

Who is liable when an AI agent pays wrongly?

Nobody has decided yet. In the US, Regulation E protects consumers from unauthorized transfers but excludes those made by someone the consumer gave access to, and it is unclear whether an AI agent counts. Until a rule exists, disputes over agent payments will turn on evidence of what was authorised.

Regulation E excludes transfers "initiated by a person to whom the consumer furnished the access device." Its official commentary says the consumer "can remain liable even when that person exceeds the authority given."

Aaron Cheiffetz flagged the gap in Payments Dive in October 2026. What the rule does not say, he wrote, "is how that rule applies when credentials are furnished to software operated by a company." Card network zero-liability policies "still depend on a transaction being classified as unauthorized." His conclusion: "There's no clear legal rule for who bears the loss when an AI tool exceeds its mandate" (Payments Dive, Oct 2026).

For anyone deploying or accepting agents, the consequence is simple. The party that can show exactly what was authorised, what the agent attempted and what was allowed or refused stands far stronger than a party holding an identity record and an activity log. We cover the liability side in more depth in Who Is Liable When an AI Agent Is Right?

Key takeaway: without a liability rule, the mandate and the receipt are your defence in a dispute.

What are regulators asking for on AI agent identity and authorization?

No jurisdiction mandates Know Your Agent or runtime agent authorization yet. But NIST, OWASP, the EU AI Act and the Monetary Authority of Singapore all point the same way: verify the agent's identity, check each action before it runs, and keep a log that proves the check happened.

• NIST (US). In February 2026 NIST's Center for AI Standards and Innovation launched the AI Agent Standards Initiative, with agent security and identity as one of three pillars. Its NCCoE published an AI Agent Identity and Authorization concept paper for public comment (NIST, Feb 2026). The paper's title puts authorization next to identity.
• OWASP. The Top 10 for Agentic Applications for 2026 lists goal hijack, tool misuse, and identity and privilege abuse as the top three risks. All three are failures of what an agent does, not who it is. In September 2026 the OWASP GenAI Security Project took on the Agent Control Standard, "extending that guidance toward practical runtime enforcement" (OWASP, Sep 2026).
• EU AI Act. Article 12 requires high-risk AI systems to "technically allow for the automatic recording of events (logs) over the lifetime of the system" (Help Net Security, Apr 2026). Under the Digital Omnibus adopted in June 2026, those obligations apply to Annex III high-risk systems from 2 December 2027 (DeepInspect, Jun 2026). US companies serving EU customers should plan for this.
• Monetary Authority of Singapore. MAS published Safeguards for Agentic Finance at Runtime (SAFR) in July 2026. The white paper describes "governance checkpoints that check and log each action an agent proposes before that task is carried out." It keeps agents inside firm-defined mandates and risk limits (FinTech Global, Jul 2026).

There is also a business reason not to wait for the rules. Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, citing "escalating costs, unclear business value or inadequate risk controls" (Gartner, Jun 2025). Risk controls are the item on that list a project team fully controls.

Key takeaway: every framework listed above goes past identity to a per-action check and a durable log.

Know Your Agent checklist: ten questions to ask before an agent moves money

Before an AI agent moves money, ask ten questions. They cover how the agent is identified, where its permissions are written and who signed them, and whether checks run before every action and outside the agent. They also cover limits, bank detail changes, approvers, refusal records, third-party verification and dispute evidence.

Use these with any vendor, internal team or agent platform. A good answer is specific. "The model handles it" is not a good answer.

1. How is the agent identified, and how are its operator and principal verified?
2. Where are the agent's permissions written down, and who signed them?
3. Are the rules checked before every action, or reviewed afterwards?
4. Do the checks sit outside the agent, where a prompt or a tricked agent cannot change them?
5. What are the per-transaction, daily and monthly limits, and are they enforced across every payment method the agent uses?
6. What happens to payments to new or changed bank details?
7. Who is the named human for anything above the threshold, and how are they asked?
8. Are refusals recorded the same way as approvals?
9. Can a third party verify a decision without access to your systems?
10. If the agent buys something the customer disputes, what evidence will you hand the disputes team?

Key takeaway: if you cannot answer questions 4, 8 and 9, you have identity without control.

Where does Abstraxn fit with Know Your Agent?

Abstraxn works on top of Know Your Agent rather than replacing it. Abstraxn's KYI (Know Your Intent) checks each agent action against a signed, versioned mandate before it executes, returns allow, deny or ask a human, and issues a signed receipt for every decision, including refusals. Abstraxn holds no funds and no keys.

We wrote about the concept in Know Your Intent (KYI). Here is what it means in practice.

You write the rules in plain English. The person accountable for the agent writes them the way they would brief a new hire: "Approved vendors only. Up to $2,000 per order and $10,000 a month. Anything above that waits for Priya. Hold any payment to changed bank details." No forms, no rule builder.

KYI reads them back, and you lock them. KYI turns the note into exact rules and shows them for confirmation. The confirmed rules are signed and versioned. A model may help translate the sentence, but it never makes the decision. Every yes or no after that comes from the locked rules, the same way every time.

Every action checks first. Before the agent pays, the check returns a decision with a signed receipt naming the rule, the mandate version and the outcome. Refusals use the same path and format as approvals.

What is live, and what we set up with you. Approved-counterparty lists, per-transaction limits and signed allow and deny receipts are live today. Monthly ceilings, routing to a named approver and holds on changed bank details are configured with our team for each deployment, because every finance and risk team draws those lines differently.

It works with the identity you already have. KYI does not replace KYA. Whether your agents are identified through a card network token, a signed request or an on-chain registry, KYI adds the decision and the evidence on top.

It never touches the money. Abstraxn holds no funds, holds no keys and does not sit in the payment path. Your bank, processor and card networks move the money. That separation is the point. A receipt issued by a party with no stake in whether the payment went through is evidence. A log kept by the party being audited is testimony.

For teams that also need the agent to hold and spend funds, Abstraxn provides smart-account wallets with live allowlist, blocklist and per-transaction limit controls at the signing layer. The technical detail is in the KYI documentation.

Frequently asked questions

Related reading

• Know Your Intent (KYI): Agents Have an Identity Layer. They Have No Intent Layer.
• Agentic Commerce Protocols Compared: ACP, UCP, AP2, TAP, VIC, AP4M, MPP and PAP by Layer
• AI Agents for Accounts Payable: Who Does the Agent Answer To?
• The AI Agent Security Questionnaire
• Agent Identity Verification