CIAM is shifting from human login to agent identity governance

At a glance

What this is: This is an analysis of Forrester’s 2026 CIAM Landscape and its key finding that agentic AI is now reshaping how customer identities, including AI agents, must be onboarded, authenticated, and authorized.

Why it matters: It matters because CIAM teams now have to govern both human and AI agent access across the same customer journeys, which changes how identity architecture, consent, and runtime authorization must be designed.

By the numbers:

• Forrester’s Customer Identity And Access Management Solutions Landscape, Q3 2026 profiles more than 30 CIAM vendors.
• Strivacity is named a Notable Vendor in the Q3 2026 landscape report.

👉 Read Strivacity’s analysis of the 2026 CIAM landscape and agentic AI shift

Context

CIAM is the control layer that governs how customers register, authenticate, recover access, and manage consent across digital and assisted channels. This article is really about how that control layer changes when AI agents become legitimate identity subjects, not just traffic to be filtered or bot activity to be blocked.

The governance gap is that many CIAM deployments were designed around a human customer model with relatively stable sessions and static permissions. Once an AI agent can act on behalf of a customer, identity teams have to decide whether the agent is treated as its own identity, how its consent is recorded, and how access is scoped and revoked without breaking existing journeys.

Forrester’s market framing is useful because it treats CIAM as both a security and experience discipline. That is the right lens for buyers: the question is not whether agentic AI is fashionable, but whether the platform can actually onboard and authorize agent identities in production today.

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 AI agents change customer identity risk models?

A: Because they can act on behalf of a customer without behaving like a person at every step of the journey. That breaks assumptions built around human login patterns, static sessions, and one-time authorization. CIAM teams need runtime policy decisions that can distinguish legitimate agent activity from abuse and still preserve customer experience.

Q: When should organisations move beyond sign-in-only CIAM controls?

A: When access conditions can change after authentication, which is now common in both high-risk customer journeys and agent-assisted interactions. Sign-in alone does not answer what the identity should be allowed to do next. Organisations should move to continuous authorization when transaction sensitivity, fraud risk, or policy drift can change mid-session.

Q: What should buyers ask before trusting AI agent support in CIAM?

A: Ask whether the vendor can onboard an agent today, authenticate it, authorize it for a specific task, and revoke it with full auditability. Then ask how the platform ties the agent back to the authorizing party and whether that control works across web, mobile, chat, and other customer channels.

Technical breakdown

Why AI agent identities change CIAM architecture

A human-centric CIAM stack assumes the identity subject can be challenged, guided, and recovered through familiar interaction patterns. An AI agent is different because it may authenticate on behalf of a customer, consume consent, and request scoped access during a transaction without following the same behavioural cues as a person. That creates a second identity object in the session, with its own credentials, authorization scope, and audit trail. If the platform cannot tie the agent back to the authorizing human or organisation, accountability becomes ambiguous and policy enforcement weakens.

Practical implication: model AI agents as first-class identity subjects and verify that the CIAM platform preserves traceability to the authorizing party.

Continuous authorization in CIAM sessions

Traditional login-first CIAM models often front-load the security decision at authentication and then allow the session to continue with mostly static permissions. That is increasingly inadequate for both humans and agents because context changes during the session, such as device risk, transaction sensitivity, or policy drift. Continuous, context-aware authorization shifts the decision point from a one-time gate to an ongoing control loop. In practice, this means access can be reduced, suspended, or re-scoped mid-session when the risk picture changes.

Practical implication: test whether your CIAM stack can re-evaluate access during the session, not just at sign-in.

Why modernization is now the hardest CIAM problem

The technical challenge is not adding agent support to a greenfield design. It is replacing heavily customized CIAM estates that already sit in the middle of customer journeys, fraud workflows, and compliance reporting. Those deployments usually include legacy integrations, bespoke rules, and application dependencies that make replacement risky. Adding AI agent support on top of that without a proper governance model often produces a split architecture, where the vendor can describe agent readiness but the operating model still behaves like a human-only system.

Practical implication: evaluate migration risk, integration debt, and operational breakage alongside feature claims when planning CIAM modernization.

NHI Mgmt Group analysis

CIAM is moving from human identity management to dual-subject governance. The important change is not that AI agents can log in, but that a single customer interaction may now involve both a human authorizer and an executing agent. That means identity records, consent, and access traces have to prove who authorised what and which actor executed it. Practitioners should treat that as a governance redesign, not a feature add-on.

Legacy CIAM assumptions break when an agent can act inside the session. The old assumption that access is granted to a known human subject at sign-in was designed for a stable operator and a predictable session. That assumption fails when an AI agent can be authorised for a task, act independently inside the workflow, and change the access pattern before the original review cycle even sees it. The implication is that least privilege must be defined around task scope and runtime behaviour, not just account attributes.

Continuous authorization is becoming the real policy boundary in CIAM. Authentication still matters, but it no longer answers the hardest question, which is what this identity should be allowed to do right now. That question now spans fraud prevention, customer experience, and security telemetry in the same decision path. Buyers should expect identity platforms to support dynamic policy evaluation across both human and agent sessions.

The named gap here is agent readiness versus agent theatre. Many CIAM vendors can talk about AI agents, but the practical difference is whether they can onboard, authenticate, authorize, and revoke an agent identity in production with auditable consent. That gap matters because buyers can mistake roadmap language for operational capability. The implication is that CIAM evaluation now has to distinguish marketing language from runtime identity governance.

CIAM is becoming connective tissue across security, fraud, and compliance. The category is no longer only about customer convenience at the front door. It now has to support traceable agent access, fraud resistance, and proof of control across channels where business teams expect identity to disappear into the experience. Practitioners should align CIAM decisions with the wider identity programme, not isolate them as a web login project.

From our research:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• For related analysis: Read OWASP NHI Top 10 for the agentic risk patterns practitioners should map to identity controls.

What this signals

Agentic CIAM will force identity teams to separate customer experience design from runtime authorization design. The first still optimises onboarding and recovery, but the second determines whether a task-scoped agent can continue acting when conditions change. For practitioners, that means CIAM roadmaps should now include session-level policy evaluation, traceability for delegated action, and explicit evidence that the authorizing party can be tied to every agent decision.

Trust in CIAM will increasingly hinge on the quality of identity evidence, not the elegance of the sign-in flow. If a platform cannot prove who authorised the agent, what it was allowed to do, and when that scope changed, it will struggle to support regulated or high-risk customer journeys. That is why buyer evaluation needs to move from feature checklists to evidence of runtime governance.

Identity blast radius is the right concept for this market shift: once AI agents become valid CIAM subjects, a weak authorization model can expand from one compromised account to a chain of delegated actions. Practitioners should align CIAM controls with the Top 10 NHI Issues and the OWASP Agentic AI Top 10 because agent identity now sits at the intersection of access, consent, and automation.

For practitioners

• Validate agent identity as a first-class subject Require vendors to show how an AI agent is onboarded, authenticated, consented, and revoked as a distinct identity object, including how the authorizing customer or organisation is linked to the agent’s actions.
• Test continuous authorization, not just login Ask for a live demonstration where access changes mid-session based on risk, context, or task scope, and confirm the platform can reduce or revoke access without breaking the transaction.
• Map consent and accountability together Make sure consent records, policy decisions, and audit logs can prove both who authorised the agent and what the agent was permitted to do at runtime.
• Separate roadmap claims from production capability Score vendors on whether agent support is operational today, with real onboarding and authorization flows, rather than treating agent language on a product page as readiness.
• Plan modernization around dependency risk Inventory the applications, fraud controls, and compliance reports tied to your current CIAM stack before changing architecture, because the hardest problem is replacing old systems without breaking customer journeys.

Key takeaways

• CIAM is no longer just a customer login layer, because AI agents now need onboarding, authorization, and revocation that can be audited end to end.
• The main governance shift is from static sign-in decisions to continuous, context-aware authorization that can change during the session.
• Buyers should test production agent readiness, not roadmap language, because modernizing old CIAM estates without breaking journeys is the real challenge.

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.
• 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.
• Continuous authorization: Continuous authorization is the practice of rechecking access as a session unfolds instead of trusting a single login decision. It matters for AI workflows because the request, context, retrieved data, and downstream action can all change between prompt and execution, making static approval too blunt.
• Delegated Consent: The authorisation a user or administrator gives to an application to act on their behalf. Once granted, that consent can outlive a password reset or even off-boarding unless it is explicitly reviewed and revoked, creating long-lived access that security teams must govern.

What's in the full article

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

• The report-framed vendor landscape context that explains how Forrester positioned the CIAM category in Q3 2026.
• The vendor’s own criteria for deciding whether an AI agent is truly supported in production versus only represented in roadmap language.
• The specific examples of how CIAM should handle onboarding, consent, and task-scoped authorization across customer journeys.
• The practical shortlist questions the vendor suggests buyers should ask when modernising legacy CIAM deployments.

👉 The full Strivacity article explains how it evaluates agent readiness, CIAM market dynamics, and buyer questions in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.