Legacy CIAM is straining under AI, partners and agent identity

At a glance

What this is: This is an analysis of why legacy CIAM models struggle as customer identity expands to include partners and AI agents, with the key finding that architecture, not feature count, is now the limiting factor.

Why it matters: IAM and security teams need to treat customer identity, delegation, and policy consistency as one governance problem, because fragmented CIAM stacks now affect fraud control, privacy, and launch speed.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Strivacity's analysis of why legacy CIAM is straining under AI and partners

Context

Customer identity is no longer just about logging people into websites and mobile apps. In this article's framing, CIAM now has to govern customers, partners, consent, fraud controls, and AI agents acting on behalf of customers, which turns identity from a single channel service into a cross-journey control plane.

That shift exposes a familiar governance gap: products designed around human authentication often become a portfolio of modules, policies, and exceptions once delegation and multi-actor access enter the picture. The result is slower delivery, inconsistent policy enforcement, and less visibility into how identity affects both security and customer experience.

For IAM teams, the question is not whether AI features exist in the stack. The real issue is whether identity architecture can still keep policy, consent, audit, and recovery coherent when the actor is a customer, a partner, or an AI agent.

Key questions

Q: How should teams govern AI agents inside CIAM platforms?

A: Treat AI agents as distinct identity subjects with scoped credentials, explicit consent, and a traceable link back to the human or organisation that authorised them. The platform should show what the agent can do, when it can do it, and how access can be changed or revoked during the session. Otherwise, accountability becomes too weak for production use.

Q: Why do legacy CIAM stacks become bottlenecks for new digital journeys?

A: Legacy CIAM stacks slow launches when each new journey requires cross-product configuration, specialist identity knowledge, or custom integration work. The issue is architectural fragmentation, not just delivery speed. When policy changes, consent logic, and analytics sit in different products, even simple changes become coordination projects rather than configuration tasks.

Q: What breaks when customer identity is split across multiple products?

A: Policy consistency, troubleshooting, and lifecycle visibility break first. Teams have to understand which component owns authentication, orchestration, consent, or fraud controls before they can resolve issues or launch updates. That increases operational risk because the organisation is managing exceptions across products instead of enforcing one coherent identity model.

Q: Should isolation and predictable performance be part of the default CIAM design?

A: Yes. Customer identity sits directly in the revenue path, so isolation and predictable performance are baseline requirements, not premium extras. When those capabilities are gated behind higher editions, the organisation is paying to compensate for architectural limitations rather than buying additional control.

Technical breakdown

Why CIAM becomes a portfolio instead of a system

CIAM portfolios emerge when authentication, orchestration, consent, fraud controls, and analytics are split across separately licensed products or acquired modules. Technically, that creates different policy engines, different audit paths, and different ownership boundaries for what should behave like one identity surface. The complexity shows up when a policy change must be propagated across channels or when administrators need to know which component owns a given journey step. In practice, the stack can look unified to the user while remaining fragmented underneath. Practical implication: map every customer identity function to its owning control plane and remove duplicated policy logic.

Practical implication: map every customer identity function to its owning control plane and remove duplicated policy logic.

How delegation changes customer identity governance

AI agent identity is not just authentication because the system must represent what a customer delegated, what scope was approved, and when that authorization expires. That requires a durable link between the human principal, the delegated agent, the actions performed, and the audit trail that explains those actions later. If the agent sits in a separate product or console, the delegation chain becomes harder to govern and revoke. The architectural issue is continuity of identity context across actors, not a new login method. Practical implication: ensure delegated access inherits the same consent and revocation model as customer identity.

Practical implication: ensure delegated access inherits the same consent and revocation model as customer identity.

Why journey performance is now part of identity architecture

Customer identity sits on the revenue path, so latency, isolation, and regional deployment are no longer secondary deployment preferences. If dedicated environments and predictable performance are sold as premium extras, the product architecture is forcing a trade-off between business continuity and cost. That matters because identity failures appear as abandoned registrations, failed resets, and transaction drop-off, not only as security incidents. In other words, CIAM performance now has direct business and governance impact. Practical implication: test whether the default deployment model can support your highest-value journeys without architectural workarounds.

Practical implication: test whether the default deployment model can support your highest-value journeys without architectural workarounds.

NHI Mgmt Group analysis

CIAM fragmentation is now a governance problem, not a packaging problem. When identity functions are split across modules and consoles, policy consistency becomes dependent on human memory and integration quality. That means the organisation is governing customer identity through exceptions, not through a single policy model. Practitioners should treat portfolio sprawl as an identity control failure, not just a commercial arrangement.

AI agent identity exposes the limits of authentication-first CIAM design. Customer identity now has to represent delegation, consent, revocation, and action history, not just prove a user is present. If the architecture cannot keep the agent tied to the customer context across its lifecycle, the result is an identity silo that security teams cannot govern cleanly. The implication is that customer identity and delegated machine identity must be managed as one policy domain.

Dedicated isolation should be a baseline identity property, not a premium feature. Customer identity sits in the transaction path, which means availability and performance are part of trust, not optional extras. When isolation, regionality, or predictable performance are gated behind higher editions, architecture is being used to shape procurement rather than resilience. Practitioners should re-evaluate any CIAM model that treats revenue-path reliability as an add-on.

Identity insight is becoming a core control, not a reporting accessory. A CIAM platform that cannot show where journeys fail, where friction is introduced, or where fraud controls depress conversion leaves security and product teams operating from different data sets. That weakens both governance and change management because no one can see the operational effect of policy changes in one place. The field should expect identity analytics to sit closer to policy control and journey design.

AI-era customer identity will be judged by architectural coherence, not feature count. The next generation of CIAM will not be differentiated by who can bolt on the most AI functions. It will be judged by whether customer, partner, and delegated-agent identity can share the same context, consent, audit trail, and operational model. Practitioners should use renewal cycles to test coherence, not just capability breadth.

From our research:

• strong>From our research: 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, which shows how immature the control baseline remains.
• If customer identity is already struggling to absorb AI agents, the wider NHI pattern points the same way: governance must move from feature-led expansion to lifecycle-led control.

What this signals

AI agent delegation will pressure CIAM programmes to align consent, audit, and revocation in one model. The organisations that keep AI agents in a separate identity layer will accumulate policy drift and fragmented investigations. Practitioners should expect renewal reviews to focus less on feature lists and more on whether one control plane can explain every actor interacting with the customer.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the governance gap is no longer theoretical. CIAM and IAM teams should prepare for delegated access patterns that outgrow human-centric approval and review cycles.

For practitioners

• Map the CIAM control surface Inventory every product, module, and service that influences authentication, orchestration, consent, fraud, analytics, and delegated access. Identify where policy is duplicated, where audit data splits, and where one change requires coordination across multiple consoles.
• Test delegated identity end to end Verify that AI agent or partner delegation carries the customer principal, approved scope, expiration, and revocation path in one continuous identity record. If revocation or audit requires checking another system, the governance model is already fractured.
• Treat journey failures as identity signals Correlate sign-in, recovery, registration, and abandonment data with fraud controls and policy changes. Use that evidence to determine whether identity is slowing launches or suppressing completion rates, especially when new channels are added.
• Set a baseline for isolation and performance Define minimum requirements for dedicated environments, regional deployment, and predictable response times before renewal discussions. If the default deployment cannot support business-critical journeys, document the operational cost of the workaround.

Key takeaways

• Customer identity is moving beyond human login flows into delegation, consent, and partner governance, which exposes architectural fragmentation quickly.
• When CIAM functions are split across modules and consoles, teams lose policy consistency, lifecycle visibility, and the ability to explain journey failures coherently.
• Practitioners should assess renewal candidates on architectural coherence, not feature count, because AI-era identity requires one control model across customers, partners, and agents.

Key terms

• Customer Identity And Access Management: Customer Identity and Access Management is the discipline of governing how external users sign in, recover access, and move through digital services. It combines authentication, profile management, and lifecycle control so organisations can deliver secure, low-friction experiences at scale.
• Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.
• Identity Portfolio: An identity portfolio is a stack where core identity functions are spread across multiple products, modules, or services that must be coordinated to work as one system. The risk is not just complexity but inconsistent policy enforcement, fragmented troubleshooting, and duplicated governance effort.
• Journey Telemetry: Journey telemetry is the operational data produced by registration, login, recovery, and transaction flows, used to understand where identity helps or hinders the user experience. In practice it links security events to conversion and abandonment outcomes so teams can see the business impact of identity decisions.

What's in the full article

Strivacity's full article covers the operational detail this post intentionally leaves for the source:

• The five diagnostic signs in a form teams can use during CIAM renewal reviews and architecture assessments.
• The article's full explanation of how customer, partner, and AI agent identity are intended to share one policy model.
• The vendor's discussion of dedicated single-instance SaaS and identity insights as part of its CIAM positioning.
• The specific questions the vendor recommends asking when evaluating whether a CIAM stack has become a portfolio.

👉 The full Strivacity article covers the five signs of CIAM sprawl and the vendor's renewal questions for practitioners.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.