Why do traditional IAM controls fall short in agentic commerce?

Why Traditional IAM Fails for Autonomous Commerce Workloads

Traditional IAM was built around a person signing in and then performing bounded actions inside a predictable session. agentic commerce breaks that model because the software agent can decide which tool to call, which vendor workflow to invoke, and when to continue acting after the human has left. That means authentication alone does not answer the real question: what is this agent allowed to do right now, in this context?

This is why static RBAC and long-lived entitlements become brittle. An agent may chain tools, switch tasks, or retry operations in ways that were never reflected in a role matrix. The issue is not just over-permissioning, but the mismatch between human-centric policy design and autonomous execution. Guidance from the OWASP Agentic AI Top 10 and NHI research such as OWASP NHI Top 10 points to the same gap: identity proofing is not enough when execution is delegated to software.

The 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM practices lag behind or only match human IAM, which is a strong signal that most controls have not caught up to autonomous workloads. In practice, many security teams encounter agent overreach only after a payment, refund, or data access path has already been exercised in production.

How Agentic Commerce Should Be Governed at Runtime

Current best practice is shifting toward workload identity, runtime authorisation, and short-lived credentials. The practical model is not “log in once and inherit a broad role,” but “prove what the agent is, evaluate what it is trying to do, then issue only the access needed for that task.” That aligns with NIST AI Risk Management Framework principles and the threat assumptions in CSA MAESTRO agentic AI threat modeling framework.

In practice, teams should treat the agent as a workload, not as a proxy human. That means using cryptographic workload identity, such as OIDC-backed tokens or SPIFFE/SPIRE-style identity, so the system can verify the agent itself before any action is authorized. The policy layer should then evaluate intent and context at request time, using policy-as-code approaches rather than static access lists. For commerce flows, that can include order value, vendor trust tier, transaction step, customer consent state, and whether the action is reversible.

• Issue just-in-time credentials per task, not persistent secrets for the whole agent lifecycle.
• Bind each token to a narrow scope, short TTL, and a specific service or action class.
• Revoke access automatically when the task completes or the context changes.
• Log both the agent identity and the delegated human origin for auditability.

NHIMG research on LLMjacking shows how quickly exposed credentials can be abused, which is why ephemeral secrets are operationally safer than static keys. These controls tend to break down in multi-step commerce automations that must hand off across vendors and APIs because session continuity often tempts teams to extend token lifetimes beyond the original task boundary.

Where the Control Model Breaks Down in Real Deployments

Tighter runtime control often increases integration overhead, requiring organisations to balance safety against transaction latency and developer complexity. That tradeoff is real, especially when agentic commerce spans checkout, fraud checks, refunds, inventory, and customer support across different systems. There is no universal standard for this yet, so guidance should be treated as evolving rather than settled.

One common edge case is delegated approval. If a human authorizes a purchase but the agent later modifies shipping, coupon logic, or refund routing, a stale approval can no longer be assumed to cover the new action. Another edge case is tool chaining, where the agent uses one permitted API call to reach a second, higher-impact action that was never intended by the original role design. This is exactly why the OWASP Agentic Applications Top 10 and the MITRE ATLAS adversarial AI threat matrix both emphasize runtime abuse paths and chained behavior, not just login security.

Current guidance suggests separating agent identity, human approval, and business authorization into distinct control points. That is especially important when vendors share APIs, when a model can call external tools, or when the commerce flow includes refunds and wallet transfers. Traditional IAM breaks down fastest when one broad token is reused across many steps, because the system loses the ability to distinguish the original intent from the agent’s next move.

Related resources from NHI Mgmt Group

• Why do traditional IAM and DLP controls fall short for agentic AI?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• Why do traditional IAM controls fall short in multi-ERP environments?
• Why do traditional IAM controls fall short for SaaS data security?