Know Your Agent

KYC was built to answer a fundamental question: who is the customer? Agentic commerce introduces a second one: who is acting with the customer’s authority?

Executive summary

For decades, financial institutions have built customer due diligence around a relatively stable assumption. Once the institution identifies the customer and authenticates access to the account, the customer is generally the actor directing the transaction - or a known human delegate is acting within a familiar permission structure.

Agentic commerce begins to challenge that assumption. Individuals and businesses are starting to delegate search, procurement, negotiation, routing and payment decisions to AI agents. The customer remains the principal. KYC remains essential. But customer identity alone may no longer provide enough context to understand who is acting, what that actor has been authorized to do, and whether the resulting transaction is consistent with that authority.

Your customer passed KYC. Their AI agent did not. Now what?

I do not believe the answer is to treat software as a customer or to apply KYC to an AI agent as though it were a natural person. The better framing is to extend identity controls into a model of delegated authority.

That model should answer six questions: Who is the principal? Which agent is acting? What has it been authorized to do? What constraints apply? Is the observed behavior consistent with the mandate? And can the authority be challenged or revoked in real time?

KYC was built for a human-centered transaction model

Modern KYC starts with a simple objective: know who you are doing business with. Financial institutions identify customers, verify identity, understand beneficial ownership, establish the purpose of the relationship and assess expected activity. That information becomes the foundation for screening, monitoring and fraud controls.

These controls developed in a world where the customer, the account holder and the decision-maker were often closely connected. Even where a business delegated authority to employees, directors or treasury teams, institutions understood those actors through familiar concepts such as authorized signatories, account administrators, corporate cards, treasury permissions, powers of attorney or API credentials.

Agentic commerce changes the nature of that delegation. An AI agent may not simply execute an instruction. It may make choices. It may compare counterparties, optimize price, select timing, choose a route, decide among payment methods and act continuously at machine speed.

The customer remains the principal. But the immediate actor behind the transaction may increasingly be software. That distinction matters because identity and authority begin to separate.

The customer is still the customer

It is tempting to describe this as “KYC for AI.” I do not think that is the right framing. An AI agent does not become the customer simply because it initiates activity. The individual or legal entity on whose behalf the agent acts remains central to the relationship.

Traditional KYC therefore remains essential. The problem is that KYC may no longer answer every question the institution needs to ask.

Consider a business that successfully completes onboarding and then deploys an autonomous procurement agent. The business may instruct the agent to identify suppliers, negotiate terms, purchase software, pay recurring invoices or transact within predefined budgets.

The institution knows the business. But that does not necessarily tell the institution which software agent is acting, whether the customer actually authorized it, what actions it may perform, whether those permissions remain valid, or whether the attempted transaction sits inside the authorized mandate.

Know Your Agent is not a replacement for KYC. It is an extension of KYC into delegated financial authority.

The Agent Authority Stack

A useful operating model is to separate agentic payments into six control layers.

1. Principal identity

Who is the underlying customer? This remains the foundation of the relationship. The institution must understand the individual or business responsible for the account and the activity.

2. Agent registration

What agent is acting? The institution may need to distinguish between the customer acting directly, a human delegate, a customer-owned software agent, a third-party agent or an agent operating through another platform. The principal-agent relationship should be explicit and auditable.

3. Delegated authority

What has the customer authorized the agent to do? An agent might recommend, prepare, initiate or execute a transaction; select counterparties; add beneficiaries; or operate autonomously within constraints. Different levels of autonomy should create different control expectations.

4. Transaction constraints

What are the boundaries of the mandate? These may include transaction size, velocity, approved counterparties, merchant categories, jurisdictions, currencies, products, time windows and human approval thresholds.

5. Continuous verification

Is the agent still acting consistently with its authorization? Authority should not be treated as a one-time event. Monitoring should detect changes in behavior, new geographies, new counterparties, unexpected velocity and expired or altered mandates.

6. Revocation and escalation

Can authority be interrupted immediately? If behavior changes or the agent is compromised, the institution should be able to suspend the agent, reduce limits, require human reauthorization or revoke the delegation entirely.

Authentication is not authorization

One of the most important distinctions in agentic payments is the difference between authentication and authorization. Authentication asks whether this is genuinely the actor it claims to be. Authorization asks whether that actor is permitted to take this particular action.

A payment provider may correctly authenticate an agent and still have no confidence that the customer intended the transaction. Imagine a registered procurement agent attempting a $75,000 payment to a newly discovered overseas supplier. The system may know exactly which agent is making the request. That does not answer whether the agent is allowed to spend $75,000, add a new supplier, transact cross-border or bypass human approval.

In human-centered payments, permission structures already exist in corporate cards, treasury systems and bank entitlements. Agentic commerce requires the same idea to operate at far greater speed and granularity.

Transaction monitoring needs a richer unit of analysis

Traditional monitoring often focuses on customer + transaction. The institution establishes expected behavior and looks for activity that deviates from that baseline.

Agentic activity can make that approach less reliable. A company deploying an AI procurement agent might suddenly generate more low-value purchases, transact at different times, switch merchants more frequently, optimize FX execution or increase payment velocity. Those behaviors may be anomalous compared with the customer’s history while still being entirely consistent with the agent’s mandate.

Without that additional context, institutions risk two failures. They may over-alert legitimate agent-driven activity, creating friction and false positives. Or they may under-detect misuse because the system treats activity through an authenticated agent as presumptively authorized.

The compliance question therefore evolves from “Is this normal for the customer?” to “Is this consistent with the authority granted to the agent?”

Sanctions and fraud become product-design questions

Sanctions obligations do not disappear in an agentic environment. If anything, the operational challenge becomes more complex. Consider an AI agent instructed to identify the lowest-cost supplier globally. It may discover a new counterparty, compare jurisdictions, select a route and initiate the payment. The customer may never personally review the specific supplier or payment path.

The strongest control is not necessarily another alert after the payment. It may be a constraint before the payment: approved counterparties, prohibited geographies, mandatory screening, transaction limits and human approval above defined thresholds.

Fraud controls face a similar change. A legitimate agent can itself become an attack surface. An attacker might hijack agent credentials, alter a mandate, manipulate the data the agent uses, change destination accounts or exploit automated approval logic.

Identity fraud may therefore need to answer not only “Is this really the customer?” but also “Is this really the customer’s authorized agent, operating inside a valid mandate?”

Accountability cannot be delegated to the machine

AI agents may make decisions. They cannot become the institution’s accountability framework. Payments companies still need clearly defined responsibility for who approved the agent, who defined its permissions, who monitors its activity, who owns exceptions, who responds when behavior changes and who can suspend the agent.

A useful governance hierarchy is based on the degree of authority delegated to the system:

Each level should have different requirements for oversight, testing, transaction limits, explainability, incident response and escalation. This is where AI governance and financial-crime compliance begin to converge.

The bigger shift: from customer records to identity-and-authority graphs

KYC has traditionally produced something that looks like a customer record: identity, ownership, address, business activity, risk and expected behavior. Agentic commerce may require a more relational model.

Rather than a single customer record, institutions may need an identity-and-authority graph connecting customers to agents, permissions, products, counterparties, transactions, behavior and risk.

Authority is contextual. An agent may be allowed to act for one customer but not another; on one product but not another; within one geography but not globally; below one threshold but not another; or during one time period but not indefinitely. A static record does not represent that complexity particularly well. A dynamic authority graph can.

Five questions payments companies should be asking now

1. Can we identify agent-initiated activity? Can systems distinguish direct customer actions, human delegates, conventional API automation and AI-agent activity?
2. Do we have a model for delegated authority? Can the product represent spend limits, counterparties, geographies, approval thresholds and expiration?
3. Can we link the agent to a verified principal? Is the relationship explicit, durable, auditable and revocable?
4. Can monitoring understand the mandate? Can risk systems distinguish legitimate automation from activity outside the delegated authority?
5. Can authority be withdrawn immediately? If the agent is compromised or behaves unexpectedly, can the institution interrupt it before more value moves?

Conclusion: KYC is still necessary. It may no longer be enough.

KYC was built for a world in which identifying the customer provided a strong foundation for understanding who was acting behind the transaction. That assumption is weakening.

As AI agents begin to search, choose, negotiate, route and pay on behalf of individuals and businesses, the next identity challenge in payments may not be determining who the customer is. It may be determining who is exercising the customer’s authority.

That is why I believe payments companies should begin thinking about Know Your Agent - not as a replacement for KYC, and not as a new legal status for software, but as a practical extension of identity into delegated authority.

The firms that solve this well will not simply have better controls. They may help create the trust infrastructure required for agentic commerce to scale.