The scaling problem: Why legacy CIAM platforms will struggle with agentic identity management

Jessica Morrison

September 10, 2026

Today, AI agents now sign in, browse, and buy on a customer’s behalf, often through the exact same session and credentials a person would use. In fact, according to a recent McKinsey report, almost 20% of people surveyed had used an AI agent to help or assist with a purchasing decision in the past 3 months. This trend, sometimes referred to as “agentic commerce,” is completely revolutionizing the challenge of identity management, especially for customers. However, agentic commerce is not an entirely new kind of identity problem. It is an old one, arriving at a scale that legacy customer identity and access management (CIAM) platforms were never built to handle.

CIAM exists to answer one question: is this person who they claim to be? Legacy systems answer that question well for people, but poorly for everything else trying to get through the same door, including the AI agents now acting inside customer accounts at machine speed. CIAM has already answered part of the question for partners, and that precedent is the fastest way to understand what agent identity actually requires.

The partner network around most platforms today is already enmeshed with the customer experience: checkouts, member rewards, approved AI agent partners, and more all sit inside the same user management system. That integration work built some of the runway that agentic identity now needs. But, as the next section shows, the agent problem stretches that runway further than partner integration ever had to.

What legacy CIAM platforms already solved for partners

A partner’s system requesting access to a customer record is not a person, and the questions that need to be asked of an AI agent are essentially the same:

Origination: Who does this system belong to?
Permission: What is it actually allowed to touch?
Record: Is there a record of what it did?

The standards work already exists, and you’ve probably been leaning on parts of it for years without thinking twice. OpenID Connect handles authentication (proving who someone is), while OAuth handles authorization (defining what they are allowed to do). This distinction already applies to partners, ensuring a partner’s system is authenticated without gaining unnecessary account access. That’s how partners have been plugged into customer journeys for years without breaking the identity model built for people.

AI agents need the same treatment, with a few more moving parts. Strivacity for Agentic AI is built on open identity standards:

Open Authorization (OAuth) 2.1 and Model Context Protocol (MCP) Authorization for the core handshake between Strivacity and the AI agent
Pushed Authorization Requests (PAR) for securely sending authorization parameters directly to the server via a back-channel, preventing sensitive data from being exposed in browser URLs.
Rich Authorization Requests (RAR) for spelling out exactly what access an agent is asking for
Demonstrating Proof-of-Possession (DPoP) for keeping tokens tied to the agent holding them
Token exchange for narrowing a credential down when an agent needs to call a different system on a user’s behalf
Identity Assertion JWT Authorization Grant (ID-JAG) for letting an agent carry that identity across apps without a fresh consent screen every time
Client Initiated Backchannel Authentication (CIBA) for pulling a human back in when an agent needs a real approval.

None of it means ripping out what you’ve already built. It extends the identity architecture you have to cover agents, too.

Why agent identity feels new: it’s a scale problem, not a new pattern

The same three questions that govern partner access apply directly to agents.

Origination: is this agent coming from a known, accountable organization?
Permission: does it have explicit authorization for this specific action, not blanket access inherited from the session it previously accessed?
Record: is there an audit trail precise enough to track what happened, if it needs reconstructing?

What makes agents harder to manage is not the absence of a technical pattern to apply; it’s scale and speed. A partner integration gets provisioned once, reviewed periodically, and rarely changes. An agent might be granted a narrow permission, use it for a single transaction, and never appear again. Or, it might act continuously across thousands of accounts in a way no manual review process was ever built to keep pace with. The pattern is familiar. The volume and speed are not, and that difference is exactly where legacy CIAM platforms start to strain.

Most businesses underestimate how prevalent this already is. According to an Adobe survey of 5,000 U.S. consumers, 38% of US consumers have used GenAI for online shopping, and 52% plan to. People are using agents to reschedule flights, manage subscriptions, and execute purchases inside accounts they hold, using the same session and credentials a person would use. Businesses are already anticipating the downstream risk: 97% of enterprise leaders expect a material AI-agent-driven security or fraud incident within the next 12 months. Legacy identity systems have no reliable way to tell the difference between the customer and the software acting for them, which is precisely the trust problem that CIAM was built to solve, and is now facing an actor it was never designed to recognize.

Where the old architecture breaks under agent-scale traffic

Identity infrastructure designed around human consumers starts to strain under AI agents with entirely different behavior, and the strain shows up in specific places rather than everywhere at once.

Permission models built around broad, session-level access do not hold up when the actor inside that session is software making decisions no person explicitly reviewed. Audit logging designed to capture human-paced activity was not built for an actor that can execute in milliseconds and repeat an action thousands of times before anyone notices. Identity infrastructure built on a shared, multi-party architecture makes it harder to isolate exactly which agent took which action, precisely when isolation is the thing most needed.

A single-instance architecture, where each customer’s identity data and configuration are isolated by design rather than commingled, addresses that last point directly. Tracing an agent’s actions is easier when the environment it acted in was never shared with another organization’s data in the first place.

How Strivacity solves the scaling issue

Strivacity extends the same identity foundation already built for customers and partners to cover agents, rather than treating agent identity as a separate system layered on top. In practice, that means the identity extends to AI agents acting on a customer’s behalf through the same standards-based flow already verifying people and partners. The system captures human consent and binds it to the token before an agent can act, so every automated action is both verified and human-approved. Adaptive access evaluates risk against that same activity, and the system logs, audits, and governs every action within an isolated single-instance environment. That verification layer runs on infrastructure built to autoscale horizontally and vertically as traffic grows, so agent volume doesn't degrade the review process the way it does on systems sized for human-paced traffic. The result is an agent that stays clearly verified, with an identifiable, traceable connection back to the human it’s acting for.

What your business needs to do now

The organizations handling agentic commerce or agentic identity management well are not waiting for agent volume to force the issue. They’re scaling the governance they already have, rather than starting a separate initiative once agent traffic becomes too large to ignore.

That means asking, today, whether your identity infrastructure can tell an agent apart from the person it’s acting for, at the speed and volume in which agents actually operate, and not just during a periodic review. It means asking whether permissions are sufficiently granular to independently audit thousands of automated agent operations, instead of broadly granting access inherited from an initial login session. Strivacity’s position is that this readiness has to be built into a product’s core, not added on afterward: as agent traffic scales, a business needs one connected framework for partner, customer, and agentic identity, not three separate systems bolted together after the fact.

Identity journeys don’t end at the sign in button

For years, customer identity was measured by authentication, a single moment at the door. Today, identity spans every digital interaction: account opening, verification, fraud prevention, consent, partner access, and a growing volume of AI agents acting on a customer’s behalf. Managing each of these touchpoints with a separate product creates more complexity, more risk, and more work.

Strivacity brings them together in one identity product built to scale with the volume agentic identity now demands.

[Discover More]

FAQs

How do AI agents differ from partner API integrations in CIAM?

Partner integrations use fixed, pre-approved credentials, such as static OAuth tokens, and change infrequently. AI agents act dynamically, executing multi-step tasks autonomously across platforms at machine speed on behalf of individual customers. This variable execution requires real-time, session-specific authorization rather than broad API access.

Why shouldn’t an AI agent inherit a human customer’s session credentials?

Inheriting broad session credentials lets software execute actions without explicit human approval or oversight. If an agent encounters an exploit or a logic error, it can carry out unintended high-value transactions at machine speed. Granting an agent unique, token-bound permissions keeps its actions inside strict operational boundaries instead.

What standard protocols manage partner and agent identity?

Identity systems rely on OAuth 2.1 for scoped authorization, and OpenID Connect (OIDC) for identity assertion. For AI agents, these standards extend further using token exchange mechanisms that issue short-lived, delegated access tokens tied to verified human consent.

How do systems establish an audit trail for autonomous agent actions?

Audit trails capture the agent’s unique identity, the human principal who authorized it, the exact token scope granted, and full transaction telemetry. Maintaining single-instance isolation for identity data lets organizations trace operations directly back to the originating agent without cross-contaminating other customers’ data.

What is adaptive risk evaluation for agentic traffic?

Adaptive risk evaluation monitors continuous session signals, such as velocity, request patterns, and IP provenance, to calculate a real-time threat score. If an agent’s behavior deviates from expected parameters, the system triggers step-up verification or revokes token access dynamically.

Discover more term definitions and industry practices in the [glossary].