AI agents are becoming customer identities, and IAM must adapt

At a glance

What this is: Ory argues that AI agents are emerging as customer identities, which forces authentication and access patterns to shift from human-centric login design to machine-to-machine governance.

Why it matters: IAM teams need to rework authentication, session, and permission models because agentic commerce changes who the identity subject is, how often it acts, and what trust boundaries apply.

👉 Read Ory's blog on AI agents as customer identities and authentication

Context

AI agents are beginning to behave like customer identities in commerce flows, which means authentication can no longer be designed only around human users. The governance gap is not just scale, but identity type: a software actor does not authenticate, transact, and reauthenticate like a person does.

For IAM and CIAM teams, that shift affects every layer of the stack, from onboarding and assurance to session handling, account linking, and permission scope. Once agents act on behalf of customers at high volume, the programme has to distinguish between a human principal, a delegated software identity, and the controls that bind them.

Key questions

Q: How should security teams govern IAM access for AI agents in AWS?

A: Treat each AI agent as a non-human identity with its own execution role, trust policy, and review cycle. Scope permissions to the smallest working set, remove wildcard access, and validate what the agent can actually do across downstream services. The safest control is to govern the role, not the prompt.

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

A: AI agents complicate IAM because they do not behave like a human user or a simple service account. They can chain tools, delegate work to sub-agents, and reuse credentials across multiple backend systems. That means access must be governed by action, context, and delegation scope, not just by the identity that opened the session.

Q: What breaks when agent sessions are not isolated from each other?

A: Parallel agent runs can overwrite files, reuse context, and leak assumptions if they share state or credentials. That creates silent corruption instead of obvious failure, which is harder to detect and triage. The practical failure is not just data loss. It is unreliable execution across feature work, testing, and production-connected tasks that were meant to be independent.

Q: Should organisations create separate policies for AI agents and human users?

A: Yes. Human users, customer agents, and internal service identities have different lifecycle, risk, and assurance requirements. A single policy set usually overgeneralises and either blocks useful automation or leaves software actors over-privileged. Separate policy treatment makes ownership, scope, and auditability much clearer.

Technical breakdown

Machine-to-machine authentication for customer agents

Agentic commerce changes the authentication problem from verifying a person to binding a software identity to a scoped set of actions. That usually means moving beyond password or passkey centric flows toward OAuth, token-based delegation, workload identity, and short-lived credentials. The challenge is that the agent may act at a much higher frequency than a human user, so the authentication layer must support repeatable, low-friction verification without creating standing trust that outlives the transaction.

Practical implication: model customer-facing agents as non-human identities and design their authentication path around delegated, time-bound access.

Session scope and delegated authority

When an AI agent acts for a customer, the session is no longer just a browser session or a mobile app login. It becomes a delegated authority window that needs clear limits on what the agent can do, for how long, and under which conditions it can continue acting. Without that, the agent can accumulate unintended privilege through reuse of tokens, broad scopes, or poorly bounded APIs.

Practical implication: tie every agent session to explicit scope, expiry, and revocation rules rather than assuming human-style session management is enough.

Why customer IAM assumptions break at agent scale

CIAM systems are usually built around predictable human behaviour such as login frequency, recovery flows, and consent checkpoints. AI agents compress or bypass those patterns because they can act continuously, in bulk, and across channels. That creates pressure on identity proofing, fraud controls, and access policy design, especially where one customer may delegate to multiple software actors over time.

Practical implication: revisit rate limits, consent boundaries, and recovery logic so they reflect delegated software action rather than human interaction patterns.

NHI Mgmt Group analysis

AI agents are becoming a distinct identity class, not just a new client type. Once a software actor can initiate commerce actions at runtime, the old assumption that the customer is always a person stops holding. That shifts the identity problem from pure CIAM into NHI governance, because the actor now needs credentials, scopes, lifecycle controls, and revocation discipline. Practitioners should treat agent identity as a governance object, not a UI variation.

High-volume agent commerce exposes the limits of human-paced authentication design. Login, consent, and recovery patterns built for people do not map cleanly to agents that may transact repeatedly and without interruption. The result is either over-friction, which breaks use cases, or over-trust, which creates sprawling access. The practitioner conclusion is that authentication architecture must separate user assurance from delegated software authority.

Customer-facing agents create a delegated identity chain that must be governed end to end. A human may authorise the action, but the software identity executes it, often through APIs and tokens. That chain needs explicit ownership, expiry, and offboarding logic because the risk is not the customer account alone, but the bound agent permissions that persist beyond intent. Teams should manage the chain as one governed path, not as isolated components.

Ory's framing highlights a broader market shift toward agent IAM as a product category. The industry is moving from identity systems that authenticate users to systems that authenticate, authorise, and constrain software actors operating in customer contexts. That does not replace CIAM or IAM; it forces those disciplines to extend into autonomous and delegated execution. Practitioners should expect identity roadmaps to converge around machine identity, customer delegation, and runtime authorisation.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a persistent behaviour gap across software delivery.
• That gap makes delegated agent identity more brittle, so teams should also review OWASP NHI Top 10 for runtime identity and privilege risk patterns.

What this signals

Delegated agent identity will push IAM teams to separate user authentication from software authority more sharply than most CIAM roadmaps currently do. The programme risk is not only access sprawl, but also unclear accountability when a customer approves an action and a software actor executes it later under a different trust envelope.

Agent IAM will become a practical design problem before it becomes a formal category in many organisations. Teams that already manage workload identity, OAuth scopes, and lifecycle controls will be better placed to handle customer-facing agents because they can reuse governance patterns instead of treating every agent as a special case. That is where identity programmes should begin planning now.

For practitioners

• Define customer agent identity as a governed subject Create a policy that classifies customer-facing AI agents as non-human identities with named owners, approved scopes, and revocation criteria. Do not allow them to inherit broad customer privileges by default.
• Use short-lived delegated credentials Issue time-bound tokens or equivalent delegated credentials for each transaction or task, and revoke them when the task ends. Avoid persistent tokens that let an agent continue acting after the original intent expires.
• Separate human assurance from agent authority Keep the customer authentication step distinct from the agent's runtime permissions so that a verified person does not automatically create open-ended machine access. Map approval, consent, and transaction scope to different control points.
• Review offboarding for software actors Build explicit offboarding steps for agents, including token revocation, API key cleanup, and policy removal when a service, workflow, or customer delegation ends.

Key takeaways

• AI agents are moving into customer identity territory, which means IAM must govern delegated software actors as first-class identities.
• Human-centric login and session patterns do not translate cleanly to agentic commerce, so scope, expiry, and revocation become central controls.
• Identity teams should separate human assurance from agent authority now, before delegated access becomes harder to observe and unwind.

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.
• Machine-to-Machine Authentication: Machine-to-machine authentication is the process of proving the identity of one system to another before data or commands are exchanged. In practice, it must be paired with authorization, audit logging, and short-lived trust, or the same credential can become a reusable path into production systems.
• Customer Agent: A customer agent is an AI agent that interacts with external users or operates in customer environments. It must protect tenant boundaries and delegated permissions because it often handles sensitive data across shared infrastructure, which makes isolation and auditability more important than broad capability.

What's in the full article

Ory's full blog covers the operational detail this post intentionally leaves for the source:

• The product and platform context behind Ory Agent IAM and how it maps to machine-to-machine commerce.
• The broader Ory ecosystem touchpoints for CIAM, B2B IAM, and agent security that shape deployment choices.
• The implementation framing for high-volume authentication and permissioning in customer-facing agent workflows.
• The article's own positioning on future-proof IAM design for agentic commerce.

👉 The full Ory post covers the agent IAM framing, customer commerce context, and implementation direction.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.