What should IAM and fraud teams do together for agentic commerce?

They should define a shared delegation policy that ties consumer consent, transaction scope, and evidence retention to the same control model. IAM owns who may act, fraud teams judge whether the action is suspicious, and both need a common record of what the agent was allowed to do.

How IAM and fraud should split responsibility in agentic commerce

For agentic commerce, IAM and fraud teams should treat the agent’s delegated authority as a shared control surface, not as two separate problems. IAM sets the rules for who can act, under what consent, and with what transaction limits; fraud decides when a permitted action still looks abnormal. The useful outcome is a single delegation model with clear evidence for both authorization and review.

The shared model matters because agentic commerce often crosses normal checkout assumptions. A consumer may approve a mandate once, but the agent may later initiate purchases, modify details, or retry a transaction under the same relationship. If consent, scope, and logging are not aligned, IAM sees a valid grant while fraud sees only an opaque payment event.

Practically, the control boundary should start with the Agentic Commerce Identity Guide model of mandate, scope, and agent identity. That lets the organisation distinguish a legitimate delegated action from a suspicious one without forcing fraud analysts to reconstruct who the agent was allowed to be. It also prevents IAM from granting broad standing permission that fraud later has to interpret after the fact.

What the shared delegation policy has to define

The policy needs to define the minimum set of fields both teams will trust: consumer intent, agent identity, allowed merchant or category scope, transaction ceiling, duration, and revocation conditions. Those fields should be expressed in the same policy language that drives enforcement, case review, and audit trail retention.

That is especially important when the action chain includes retries, substitutions, refunds, or changes to shipment and fulfilment details. If the policy only says “the agent may buy,” then fraud cannot distinguish a normal delegated purchase from a malicious one that uses the same authority in a different context. A common record of allowed actions makes review measurable instead of speculative.

This is where AI Agent Authorisation Guide is useful: it frames task-scoped access, per-action policy decisions, and human approval as the right operating pattern. The practical lesson for commerce is that broad agent permission should be replaced with short-lived, purpose-bound authority that can be evaluated action by action.

How to make fraud review and IAM enforcement work from the same record

Fraud teams need more than an authorization decision. They need the evidence chain behind it, including when consent was given, what scope was granted, which device or session initiated the action, and whether the action stayed within the declared mandate. IAM teams should make those attributes available as authoritative transaction metadata, not as an afterthought in a separate log.

That shared record should also support revocation and exception handling. If the consumer withdraws consent, if the agent exceeds its scope, or if the merchant pattern changes materially, the control should move from “allowed” to “reviewed” or “blocked” without forcing teams to reconcile two different sources of truth. For that reason, retention must be long enough to support dispute handling and fraud investigation, not just real-time enforcement.

For the identity and access side, the Zero Trust for AI Agents guidance reinforces the right judgment: verify the principal and the request continuously, and remove standing privilege wherever possible. In commerce terms, that means the agent’s authority should be checked against the current transaction context, not presumed because it was valid earlier in the session.

Risk and Threat Considerations

Agentic commerce creates a failure mode where legitimate delegation becomes too broad to distinguish from abuse. If the consent record is vague, the scope is open-ended, or logs do not preserve the allowed action set, fraud teams may miss misuse until after funds move or disputes begin.

Failure mechanism: An attacker or malicious agent can stay inside a valid mandate while changing the practical intent of the transaction, for example by inflating quantity, switching merchants, or chaining retries until a higher-value action succeeds. When IAM and fraud do not share the same delegation record, that abuse looks authorized in one system and suspicious only in another.

Impact: The organisation gets weak attribution, harder dispute resolution, and a larger blast radius from a single delegated credential or approval. The consumer experience also degrades because legitimate actions are more likely to be blocked or reversed after the fact.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Agentic commerce hinges on delegated authority and action scope.
Recommendation — Constrain each agent action to least-privilege, per-request authorization.
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Commerce agents can hold excessive delegated permission and scope.
Recommendation — Reduce standing privileges and scope every delegated commerce grant.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Commerce delegation depends on controlling credential and token lifecycle.
	AU-10 — Non-repudiation	Shared evidence is needed to prove what an agent was allowed to do.
	AC-6 — Least Privilege	Shared delegation policy should limit what the agent may do.
Recommendation — Manage token and credential issuance, rotation, and revocation tightly. Preserve transaction evidence that binds consent, scope, and action. Limit each agent to the minimum commerce actions required.
ISO/IEC 27001:2022	A.5.15 — Access control	Delegated commerce authority must be governed as controlled access.
Recommendation — Define and enforce access rules for delegated agent actions.

Practitioner Guidance

What to verify: Confirm that consent, scope, transaction limits, and revocation all land in one authoritative record that both IAM and fraud systems can query. If either team is relying on a different source of truth, the control is already split.

Decision rule: If the agent can initiate or modify a payment, treat the delegation as a high-value authorization object, not just a checkout convenience. Use short-lived, purpose-specific grants for active commerce and preserve the evidence needed to explain every permitted action.

Common mistake: Do not let fraud own only post-transaction scoring while IAM owns only pre-transaction approval. That split leaves the organisation unable to answer the most important question in a dispute or investigation: was the agent allowed to do exactly this?

Practitioner takeaway: The best operating model is one policy, one record, and two interpretations: IAM enforces delegated authority, and fraud tests whether the authorised action still looks trustworthy in context.