AI agents are becoming customer identities, and IAM must adapt

At a glance

What this is: This is a product blog arguing that AI agents are becoming customer identities and that existing IAM patterns need to adapt to machine-to-machine commerce at scale.

Why it matters: IAM teams need to understand how customer identity, authentication, and authorisation change when the subject is a software actor rather than a person, especially for bot-driven transactions and delegated access.

Context

AI agents are starting to occupy customer-facing identity flows that were built for people. In practical terms, that means the identity programme has to decide whether the subject is still a human user with a browser session or a machine identity acting on behalf of that user.

The governance gap is not just volume. When an AI agent becomes the buyer, existing assumptions about login cadence, consent, session duration, and fraud review stop mapping cleanly to the real interaction. That makes customer identity design an IAM problem, a machine-to-machine authorisation problem, and a lifecycle problem at the same time.

For identity teams, the question is whether current customer authentication can distinguish an autonomous purchase flow from a delegated one, and whether the controls around that flow can scale without degrading trust.

Key questions

Q: How should security teams authenticate AI agents in enterprise environments?

A: Use the strongest method the environment can support while keeping access short-lived and scoped. For federated and cross-system access, OAuth 2.1 with OIDC is usually the default. For trusted cloud runtimes, workload identity is often cleaner. For service-to-service traffic, mTLS can work well if certificate automation and revocation are mature.

Q: When does customer authentication fail in agent-driven commerce?

A: It fails when controls assume a person is present to complete the flow. If the system depends on browser interaction, step-up prompts, or slow human pacing, agent traffic can bypass the intended assurance model or overwhelm it with volume. The failure is architectural: the trust model no longer matches the actor.

Q: What are the signs that AI agents are overloading customer identity controls?

A: Look for abnormal retry rates, excessive token issuance, sudden bursts of authenticated transactions, and audit logs that cannot explain who initiated the action versus who benefited from it. Those signals usually mean the identity layer is being asked to govern machine pace with human-era assumptions.

Q: What is the difference between customer identity and delegated software identity?

A: Customer identity identifies the human principal who owns the relationship. Delegated software identity identifies the system that is allowed to act within that relationship on the customer’s behalf. The difference matters because the delegate should have narrower, revocable authority, while the customer retains the underlying relationship and accountability.

Technical breakdown

Customer identity shifts from person to software actor

Customer identity traditionally assumes a human subject with a browser, a stable device, and an interaction pattern that can tolerate MFA prompts, step-up checks, and session state. AI agents break that assumption because the consumer can be a software process acting continuously, at high frequency, and often across multiple services. That changes the shape of identity proofing, authentication, and consent. The core design question becomes whether the IAM layer is authenticating the human principal, the software delegate, or both, and which of those should own the resulting permissions.

Practical implication: separate human authority from machine execution in the identity model before an agent starts transacting on behalf of a customer.

Machine-to-machine auth becomes customer commerce infrastructure

When an agent acts as a customer, the authentication flow stops being a niche integration pattern and becomes core commerce infrastructure. Machine-to-machine auth must carry not just API access, but customer-scoped permissions, transaction boundaries, and revocation logic that make sense for delegated action. That requires tighter alignment between identity, authorisation, and policy enforcement than many consumer IAM stacks were built to handle. The technical issue is not simply issuing tokens to machines; it is constraining what the machine can do, when it can do it, and under whose authority.

Practical implication: design customer-facing machine auth with explicit delegation scope and revocation, not generic service access.

High-volume agent traffic exposes scaling and trust limits

Custobots create load patterns that differ from human behaviour in both speed and predictability. A system sized for interactive users can fail when an agent retries, parallelises, or chains actions far faster than a person would. That stresses rate limiting, fraud controls, session handling, and audit pipelines. It also exposes a trust problem: if every agent request looks like a legitimate customer action, then signal quality becomes a governance issue, not just an infrastructure issue. IAM has to support scale without turning every interaction into either a false positive or an open door.

Practical implication: test customer identity and fraud controls against agent-level transaction rates, not just human traffic patterns.

NHI Mgmt Group analysis

Customer identity is no longer automatically human identity: once software begins acting as the shopper, the customer IAM model has to distinguish principal, delegate, and beneficiary. That separation matters because authentication no longer proves who is clicking, only which actor is authorised to act. The implication is that customer identity architecture now has to govern delegation explicitly, not assume it.

Machine-to-machine commerce creates a new trust boundary: the old boundary was the browser session, but agent-driven commerce moves the trust decision into backend identity and authorisation layers. That means the control plane, not the front end, decides whether the action is legitimate. Practitioners should treat this as a customer IAM redesign problem, not an application feature request.

Scaling customer auth for agents changes fraud and assurance economics: high-volume software buyers compress interaction times and increase the cost of manual assurance. The result is that every weak step in authentication or consent handling becomes more expensive to monitor and harder to explain after the fact. The practitioner conclusion is that customer identity assurance must be redesigned for machine pace, not human patience.

Custobot identity reveals the limits of human-centric IAM assumptions: access reviews, session expectations, and challenge flows were built around human behaviour and predictable interaction windows. AI agents can outpace those assumptions without violating policy syntax, which means governance has to move from login-centric thinking to delegated-action governance. The conclusion is that identity controls must recognise software actors as first-class customer subjects.

Named concept: delegated customer identity: this is the point where a human customer authorises software to transact inside the customer relationship. It is not the same as a service account because the permissions are anchored in customer intent and can change transaction by transaction. The practitioner takeaway is to design policy around delegated intent, not static user accounts.

From our research library:

• Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
• Read next: Agentic AI Identity Guide

What this signals

Delegated customer identity: AI agents that shop, book, or trigger services on behalf of people create a new governance layer between human intent and machine execution. That layer needs explicit scope, revocation, and auditability, otherwise customer IAM turns into account-sharing by another name.

Customer-facing agent traffic should be evaluated against machine-speed transaction patterns, not human browsing baselines. If the control stack cannot absorb bursts, retries, and parallel actions without misclassifying them, the organisation has not adapted its customer identity model to autonomy.

The right design question is not whether an agent can log in, but whether the IAM architecture can prove delegated intent throughout the full transaction path. That shifts the programme from authentication only to delegated-action governance.

For practitioners

• Define the customer delegate model Specify when an AI agent is acting for a customer, what authority it inherits, and which actions require separate approval or fresh consent.
• Separate human and machine credentials Avoid collapsing customer sign-in and agent execution into one credential path. Use distinct authentication and authorisation controls for the person and the software actor.
• Bound delegated transaction scope Limit the actions, spend, and data access that a customer-authorised agent can exercise so token misuse does not become full account misuse.
• Test controls at machine speed Load-test rate limits, fraud signals, session handling, and audit logging using agent-like burst patterns rather than human browsing assumptions.

Key takeaways

• AI agents change customer identity from a human login problem into a delegated software-actor problem.
• The weak point is usually not credentials alone, but the mismatch between human-era IAM controls and machine-paced commerce.
• IAM teams should separate human authority, machine execution, and delegated scope before agent-driven transactions reach production.

Key terms

• Delegated Customer Identity: A delegated customer identity is a software actor authorised to act inside a customer relationship on behalf of a person. The authority comes from customer intent, but the permissions, revocation, and audit trail must be managed separately from the human account.
• Customer identity assurance: Customer identity assurance is the confidence a business has that a digital customer is real, reachable, and behaving within expected bounds. It combines proofing, authentication, behavioural context, and recovery controls so the programme can reduce fraud without treating every user as suspicious.
• Machine-to-Machine Communication: Interactions where software systems exchange data or invoke actions without a person present in the loop. These connections are often legitimate business dependencies, but they still need identity governance because they can be abused through stolen credentials, over-scoped tokens, or automated attacks.
• Delegated Action Governance: Delegated action governance is the set of policies that limit what a software delegate can do, for how long, and under whose authority. It becomes critical when AI agents transact on behalf of customers, because static user-centric IAM patterns do not fully capture the trust boundary.

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.