Know Your Agent: Identity for AI Agents That Buy on a Customer's Behalf

Key takeaways

• Know Your Agent (KYA) is a third verification layer beside KYC and KYB: verify the agent, control its permissions, and monitor that the customer authorized it.
• An agent transaction probability score asks whether an agent truly acted on the customer's authority. That is a trust question, not a fraud score.
• Mastercard's Probability Score (September 30, 2026) is the first named instance. It is in US-only testing, with thresholds, APIs, and pricing undisclosed.
• CIAM owns the binding between agent and customer: a delegated OAuth grant with narrow scopes, a spend limit, and an expiry. Never the customer's password or cookie.
• Out-of-policy actions should step up to the human through CIBA, not fail silently or proceed on the agent's say-so.
• Feed identity signals such as account age, delegation age, and scope fit to the payment network's score. Do not build a competing score.

What Know Your Agent means

That framing comes from PYMNTS, writing with the identity verification firm Trulioo in March 2026. See the Know Your Agent glossary entry for the short definition.

KYC proves a person is who they claim to be. KYB does the same for a company. Neither answers the question a merchant now faces at checkout. Is this software acting for a verified customer, and did that customer authorize this specific action? Most of the answer lives in the consumer identity stack, which is why this guide is written for the CIAM team.

The commerce side of the shift, meaning how agents find, compare, and buy products, is covered on the main site in agentic commerce: AI agents that find, compare, and buy. This guide stays on identity.

The four-layer trust stack

Coverage of Mastercard's Agentic Commerce Trust Framework describes four layers that together decide whether an agent's purchase should go through:

1. KYA identity verification. Who is the agent, and who operates it?
2. Transaction-level probability scoring. Did this agent initiate this transaction on the customer's authority, and does it fit expected behavior?
3. Payment execution with controls. Spend limits, merchant restrictions, and tokenized credentials at the point of payment.
4. Consumer protection signals. The signals that support disputes, refunds, and the customer's ability to say "I did not authorize that."

CIAM does not own all four. It does own the evidence that layers 1, 2, and 4 depend on: which customer delegated, to which agent, for what, and when.

Agent transaction probability scores

This is different from fraud scoring. A fraud score asks whether a transaction looks criminal. A probability score asks whether a legitimate customer really delegated this action to this agent within the limits they set. A purchase can pass every fraud check and still fail the trust check because the agent went past its mandate. See the agent transaction probability score glossary entry.

The first named instance is Mastercard's Probability Score, announced September 30, 2026, inside its Agentic Commerce Trust Framework. According to coverage of the launch, it draws on web and payment signals from Cloudflare and KYA verification from Skyfire. It is in testing in the US only. Mastercard has not disclosed thresholds, APIs, or pricing.

For a CIAM team, the practical point is narrow. You will not compute this score. You will supply some of its inputs, and you will receive its outcome as a reason to step up or deny.

What the CIAM team owns

Six capabilities sit squarely in the customer identity platform. Each one produces evidence that a payment network or merchant risk engine can use.

1. Bind the agent to the account through delegated consent

The agent should hold its own credential, issued through an OAuth consent the customer granted. That grant needs three limits:

• Narrow scopes. orders:create and cart:read, not a broad account:*.
• A spend limit. A per-transaction and per-period ceiling stored with the grant, enforced at your API, not just displayed in the UI.
• An expiry. Delegations that last weeks or months, not indefinitely. Re-consent on expiry.

Where the agent calls downstream services, use token exchange (RFC 8693) so each hop gets a token naming both the customer (sub) and the agent (act). The mechanics are in token management for AI agents and authorization patterns for agentic workflows.

2. Recognize agent sessions as distinct from human sessions

Every token and session should carry whether a human or an agent is present. Mark agent sessions with the agent's client identity and the delegation ID. Your APIs, risk engine, and analytics can then apply different rules to each.

CIAM Compass tracks this capability in vendor profiles as agent-versus-human token separation. At the time of review, Auth0 was marked as supporting it, Descope as partial, and Stytch as not supporting it. Check the profiles for the current state.

3. Step up to the human for out-of-policy actions

When an agent asks for something outside its grant, such as a purchase over the limit or a new shipping address, pause and ask the customer. The fitting pattern is CIBA: the platform sends an approval request to the customer's device while the agent waits.

On approval, issue a token scoped to that single action. On denial or timeout, refuse it and record the attempt. Never let the agent widen its own scope.

4. Keep consent and audit records that name both parties

Each consent and each action should record the customer, the agent, the agent's operator, the scopes, the limits, and the time. An audit line that says only "user 4182 bought X" is useless in a dispute. It cannot show whether the customer or their agent acted.

These records are the raw material for consumer protection. When a customer disputes an agent purchase, the question is whether the action fell inside a delegation they granted. Only CIAM can answer that.

5. Let the customer revoke from their account page

Customers need one place that lists every agent they have authorized, with scopes, limits, last use, and a revoke button. Revocation must kill the grant and its refresh tokens immediately, not at the next expiry. This is the same pattern as connected apps, with spend limits added.

6. Feed identity signals to the network's score

Do not build your own competing probability score. Supply the inputs only you hold:

• Account age and history. How long the customer account has existed and how it was verified.
• Delegation age. When the customer granted this agent access. A grant made minutes before a large purchase is a different signal from one made months ago.
• Scope fit. Whether the requested action matches the scopes and limits on the grant.
• Recent authentication strength. Whether the customer recently signed in with a passkey or only a weak factor.

How these signals reach a payment network is not standardized yet. Design them as internal events first, so you can map them to whatever interface the networks publish.

Who owns each KYA layer

The table maps each part of the trust stack to the team or system that usually owns it.

Layer	Question it answers	Primary owner	CIAM's contribution
Agent identity verification	Who is this agent and who operates it?	KYA provider, agent platform	Registered client identity for the agent
Permission controls	What may this agent do for this customer?	CIAM	Delegated OAuth grant, scopes, spend limits, expiry
Authorization monitoring	Did the customer really authorize this action?	CIAM with the risk engine	Agent session marking, CIBA step-up, audit records
Transaction probability scoring	Does this transaction fit the agent's mandate and behavior?	Payment network	Account age, delegation age, scope fit signals
Payment execution controls	Can this payment run within its limits?	Payments team, network	Grant limits exposed to the payment layer
Consumer protection	Can the customer dispute and recover?	Payments, support	Consent and action records naming both parties; revocation

Pitfalls

Three mistakes show up repeatedly when consumer platforms first meet agent traffic. Each one either blocks legitimate customers or erases the evidence you need when a purchase is disputed later.

For the fraud models that run alongside these controls, see AI fraud detection in CIAM. For proofing the human behind the account, see identity verification and KYC.

What is still undefined

Several pieces of this stack have no standard yet. Plan for change rather than lock in a guess.

• Proof of agent initiation. No published standard defines how an agent proves it initiated a transaction on a customer's authority.
• The probability score interface. Mastercard has not disclosed thresholds, APIs, or pricing, and testing is US-only.
• Signal exchange. There is no agreed format for a CIAM platform to send delegation and account signals to a payment network.
• Agent identity itself. How an agent authenticates as itself is still evolving. See authentication for AI agents for the current patterns.

Our opinion, not a reported fact: the delegation record will become the center of this stack. Networks can score behavior, but only the identity platform knows what the customer actually agreed to. Teams that already store delegations with scopes, limits, and expiry will adapt to whatever interface arrives. Teams that let agents borrow passwords will start over.