Why do AI agents complicate identity and access management for retailers?

Why This Matters for Security Teams

Retailers are adopting AI agents to handle product content, customer support, fraud review, replenishment, and supplier workflows, but those agents do not operate like a person sitting at a keyboard. They can move from one system to another, call APIs in sequence, and reuse a token in ways that make traditional access reviews too coarse. Current guidance suggests that the real risk is not the model alone, but the identity and delegation path behind it, a theme also reflected in OWASP NHI Top 10 and OWASP Agentic AI Top 10.

For retail environments, the challenge is amplified by seasonal spikes, distributed commerce stacks, and third-party integrations that already rely on secrets, service accounts, and partner tokens. NHIMG research on LLMjacking shows how quickly exposed cloud credentials can be abused, which is exactly why agent identity needs tighter control than a conventional application login. In practice, many security teams encounter overprivileged agent access only after the agent has already touched inventory, pricing, or customer data.

How It Works in Practice

AI agent IAM should be treated as workload identity plus runtime authorisation, not as a simple user account problem. The agent first proves what it is, then receives only the minimum authority needed for the current task. That is why many teams are moving toward short-lived credentials, ephemeral tokens, and policy decisions made at request time rather than static RBAC roles assigned months earlier.

In practical terms, a retailer can separate the agent’s identity from the human who launched it, then constrain each tool call by context. For example, a merchandising agent may be allowed to read supplier pricing, but only within a specific tenant, time window, and delegation scope. A support agent may be able to draft a refund, but not execute it unless a second policy step is satisfied. This is where workload identity standards such as SPIFFE, OIDC-based service tokens, and policy engines like OPA or Cedar become relevant, because they let the platform decide based on the action being attempted, not just the session that was opened.

The operational pattern usually looks like this:

• Authenticate the agent as a workload, not as a person.
• Issue a JIT credential with a short TTL for one job or one workflow step.
• Evaluate access at runtime using context such as tenant, tool, data class, and risk signals.
• Revoke or expire the token immediately after completion or interruption.

NHIMG’s Ultimate Guide to NHIs and NHI Lifecycle Management Guide both reinforce that lifecycle discipline matters as much for machine identities as it does for human ones. These controls tend to break down when retailers bolt agents onto legacy ERP or ecommerce platforms that only support long-lived API keys and coarse role assignment.

Common Variations and Edge Cases

Tighter agent controls often increase operational overhead, requiring retailers to balance faster automation against more frequent policy tuning and token issuance. That tradeoff becomes visible when an agent must cross multiple business domains, such as fraud, customer service, and supply chain, because each domain may carry different data sensitivity and approval requirements.

Best practice is evolving, but there is no universal standard for how much autonomy a retail agent should receive before human approval is required. Some teams use one policy tier for low-risk read-only actions and another for write actions, while others require step-up controls whenever the agent attempts to chain tools or delegate to sub-agents. Current guidance from NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework supports that kind of risk-based approach, rather than a one-size-fits-all access model.

Retailers should also expect edge cases where delegation is legitimate but hard to govern, such as when one agent hands work to another during peak demand. That is why the authorization record should preserve who authorized the agent, what the agent was allowed to do, and which downstream systems were touched. In practice, agent IAM becomes fragile when shared secrets, vendor integrations, and exception handling are mixed into the same control plane.

Related resources from NHI Mgmt Group

• Why do AI agents create new risk in non-human identity management?
• Should companies develop centralized identity management practices for AI agents?
• Why do AI agents complicate zero trust in identity and access management?
• Why does identity security become harder when workloads and AI agents are part of the access model?