TL;DR: AI agents are now signing in, browsing, and buying through customer sessions at machine speed, and Strivacity argues that legacy CIAM was built for people and partners, not software acting inside accounts. The core issue is not a new identity pattern but a scale and authorization problem that breaks broad session-based access, audit trails, and human-paced review.
At a glance
What this is: This is an analysis of how agentic commerce exposes the limits of customer IAM, with the key finding that agents are entering accounts through human sessions and credentials.
Why it matters: It matters because CIAM teams now have to govern software acting on behalf of customers without collapsing customer authentication, delegated authorization, and auditability into one broad session.
By the numbers:
- Almost 20% of people surveyed had used an AI agent to help or assist with a purchasing decision in the past 3 months.
Context
Agentic commerce is what happens when software acts inside a customer account to browse, compare, and buy on the customer’s behalf. That creates a customer IAM problem because the actor is no longer just a person at the keyboard, yet the account still looks like a normal customer session to the systems governing it.
Legacy CIAM was designed to answer whether a person is who they claim to be, then let that person continue through the session. The problem now is delegated action inside the same account, where origination, permission, and record all matter more than a single login event.
Key questions
Q: What breaks in CIAM when AI agents can act for customers?
A: What breaks is the assumption that authentication alone defines access. Once an AI agent can act on behalf of a customer, teams need explicit authority, scope, approval, and revocation controls. Without those, the identity layer may authenticate a session but fail to govern what that agent is allowed to do after login.
Q: Why does agentic commerce increase identity risk for customer accounts?
A: Agentic commerce increases risk because the actor performing the transaction may not be the customer who authenticated. That creates gaps in intent, scope, and traceability. If the organisation cannot prove what the agent was allowed to do, the customer session becomes an ambiguous trust container rather than a controlled access path.
Q: What should security teams do about delegated access across sub-agents?
A: Security teams should require revalidation at each hop in the delegation chain. Every downstream agent should carry the current identity, current context, and the original intent so inherited access does not turn into a blanket pass.
Q: What should CIAM teams do when customer accounts start using AI agents?
A: Teams should treat AI agents as a distinct actor in the account lifecycle and govern them with explicit delegation, not inherited human access. That means separating customer authentication from agent authorization, limiting permissions to specific tasks, and preserving evidence strong enough for later review. If those controls are missing, customer identity and agent identity are being conflated.
Technical breakdown
Why session-based customer IAM breaks for AI agents
CIAM is built around a human authentication moment followed by a session that can be trusted for a bounded period. Agentic commerce changes the runtime actor inside that session. A person may approve the start, but the software can then execute many steps, across many pages or services, without a fresh interaction. That is why the control plane has to move from “who logged in” to “what this actor is allowed to do right now.” OpenID Connect can still assert identity and OAuth can still scope authorization, but broad session inheritance stops being a safe assumption when the actor is autonomous enough to continue acting beyond the user’s direct attention.
Practical implication: Reframe customer access decisions around delegated action scope, not just authentication state.
How OAuth, token exchange, and consent boundaries need to work
The article points to a standards-based model where the agent’s access is explicitly tied to human consent and narrowed through token exchange, rather than inheriting the customer’s whole session. Pushed Authorization Requests, Rich Authorization Requests, DPoP, and back-channel approval are all mechanisms for constraining what the agent can do and proving it is holding the right token. The technical point is that authorization must be specific, bounded, and reconstructable. In other words, the system should be able to answer not just whether the customer authenticated, but which transaction the agent was authorized to complete and which proof bound that permission to the correct actor.
Practical implication: Use scoped, token-bound delegated access for agent actions instead of broad session reuse.
Why audit trails and isolation matter more at agent speed
Agentic traffic is difficult because it compresses time. An agent can perform thousands of operations before a human review cycle even starts, so logs must preserve actor identity, token scope, and transaction-level detail. The article also highlights single-instance isolation as a way to avoid cross-customer ambiguity when reconstructing events. That is not just a hosting choice. It is an identity tracing choice, because multi-tenant commingling makes it harder to determine which agent acted, under whose authorization, and against which customer record. Without that traceability, the record requirement collapses under volume.
Practical implication: Ensure audit data captures agent identity, scope, and per-transaction evidence in an isolated trust boundary.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Agentic commerce exposes a customer identity blind spot, not a brand-new identity category: the core problem is that software is now operating inside customer accounts through the same sign-in and session constructs built for people. That means CIAM is being asked to govern delegated machine action while still optimising for human authentication. The implication is that customer identity programmes must distinguish the principal from the actor, not just the session from the login.
Broad session inheritance is the wrong governance assumption for agentic access: a customer session was designed for a human user whose intent is visible and pace is reviewable. That assumption fails when an agent can execute multiple actions without returning to a human-paced decision loop. The implication is that permissioning models need to move from session continuity to action-by-action authorization boundaries.
Identity trust debt is now a customer-side problem: many platforms already know how to onboard partners, but agentic commerce stretches those patterns into customer accounts where accountability, consent, and audit precision are harder to preserve. That makes CIAM a delegated-access governance layer, not just an authentication service. Practitioners should treat agent traffic as a test of whether their identity architecture can sustain explicit delegation without collapsing into implicit trust.
Auditability is the differentiator between delegated commerce and invisible automation: if the system cannot reconstruct who authorised the agent, what scope was granted, and which actions were taken, the customer experience may still work while governance fails. This is where the identity control plane matters most, because traceability is the only way to separate legitimate delegated purchasing from silent account abuse. The implication is that record quality becomes a security control, not a reporting feature.
From our research library:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Guide
What this signals
Identity trust debt: customer identity programmes now inherit the same problem machine identity teams have faced for years, which is that the actor can be software while the account still looks human. CIAM teams should expect consent, token scope, and audit precision to matter more than the initial login event.
The practical shift is from proving who signed in to proving what a delegated actor was authorised to do. That makes agent-bound authorization and traceable consent central design requirements for customer-facing identity systems.
Agentic commerce will force identity teams to decide whether their current account model can distinguish a customer from the software acting for them. If it cannot, the programme is already too coarse for the traffic pattern it is being asked to govern.
For practitioners
- Map delegated customer actions separately from human sessions Inventory where AI agents can already act inside customer accounts and separate those flows from normal human login journeys, consent, and step-up paths.
- Constrain agent permissions to specific transactions Replace broad inherited session access with narrowly scoped authorization that names the exact purchase, account task, or data touch the agent may perform.
- Bind tokens to the acting agent and human principal Require proof-of-possession or equivalent binding so the token cannot be replayed outside the intended agent and the approving customer remains identifiable.
- Test whether your audit trail can reconstruct agent activity Validate that logs retain actor identity, consent source, token scope, and per-transaction detail well enough to explain what the agent did after the fact.
Key takeaways
- Agentic commerce turns customer accounts into delegated execution environments, which exposes the limits of CIAM models built around human login assumptions.
- The main control gap is not authentication at entry but authorization, traceability, and audit quality once software is acting inside the session.
- Teams need explicit delegated access, token binding, and reconstructable logs if they want customer AI agents to remain governable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Agentic commerce still begins with customer authentication, but the article shows that authentication alone no longer defines the trusted actor. |
| NHI-10 — Human Use of NHI | The article centres on software acting on behalf of a customer inside the account session. | |
| Recommendation — Separate customer authentication from delegated agent authorization and avoid treating login as proof of agent trust. Prevent human session reuse by requiring explicit delegated access for any software acting in a customer account. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Delegated access in customer accounts depends on how tokens and authenticators are issued, scoped, and bound. |
| Recommendation — Apply authenticator management controls to narrow, bind, and revoke customer-facing delegated credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about whether AI agents should inherit or receive explicit permissions inside customer sessions. |
| Recommendation — Use entitlement governance to keep agent permissions explicit, bounded, and reviewable. | ||
| NIST SP 800-63 | SP 800-63C — Federation | The article relies on federated identity patterns such as OpenID Connect and token exchange for delegated access. |
| Recommendation — Use federation controls to ensure delegated access remains explicit and tied to the correct principal. | ||
Key terms
- Agentic Commerce: Agentic commerce is a buying and transaction model where software agents act on behalf of a person. The identity challenge is not just proving who owns the account, but constraining what the agent may do, for how long, and under what revocation and audit rules.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Token Binding: Token binding links a token to a specific device, certificate, or connection so it cannot be reused elsewhere without the bound proof. It reduces replay risk by making theft alone insufficient, although it does not remove the need for monitoring and revocation.
- Single-Instance Isolation: Single-instance isolation keeps each tenant or customer environment separate so identity records, permissions, and activity logs do not blur together. In agentic commerce, that separation improves attribution and reconstruction when automated actions happen quickly across many accounts.
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.
Published by the NHIMG editorial team on September 14, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org