Unified identity control planes are now a governance requirement

At a glance

What this is: This analysis says unified identity control planes are becoming a governance requirement because siloed IAM tools cannot keep up with human, machine, and AI-agent access decisions.

Why it matters: IAM teams need to treat runtime authorization and shared context as core design requirements, because disconnected identity consoles create gaps in governance, telemetry, and revocation speed.

Context

Identity governance breaks down when access, privilege, and telemetry are split across separate consoles that do not share a common decision model. In that environment, policy drift is easy to miss because one system can authenticate a subject while another system governs it hours later.

The article is really about the governance gap created by identity silos, not just about AI. Once humans, service accounts, and AI agents all need to be authorised at runtime, the old assumption that identity decisions can be processed on batch cycles stops holding.

That shift matters because modern identity programmes now have to coordinate IAM, PAM, IGA, NHI, and authorization together rather than treating each as a separate control domain.

Key questions

Q: What breaks when identity governance is split across multiple consoles?

A: Policy drift, delayed revocation, and inconsistent enforcement break first. When IAM, PAM, and IGA each maintain their own state, the same identity event can be accepted in one system and invisible in another. That leaves attackers and legitimate users operating in different versions of the truth, which creates governance gaps that batch reconciliation cannot reliably close.

Q: Why do AI agents and NHIs require runtime authorization?

A: Because their work can happen faster than batch governance cycles. If an agent can complete thousands of actions in seconds, a once-per-session approval is already stale. Runtime authorization evaluates the specific action in the current context, which is the only control that matches machine-speed behaviour.

Q: What are the signs that an identity programme is still too fragmented for efficient operations?

A: A fragmented identity programme usually shows up as multiple ordering paths, separate billing cycles, inconsistent user experiences, and slow changes to authentication controls. It also creates unnecessary operational overhead when teams must manage the same identity capabilities through different systems. Those symptoms indicate the environment is costing more than it should and making it harder to adapt to new security requirements.

Q: Why do service accounts and AI agents need different controls from human users?

A: Service accounts and AI agents authenticate and act without the predictable patterns that human identity systems expect. They can operate across runtimes, scale quickly, and carry permissions into automated workflows. That means access decisions should consider workload context, runtime behaviour, and time-bound authority rather than relying only on user-centric IAM patterns.

Technical breakdown

Why identity silos create policy drift

A fragmented identity stack means authentication, privilege management, governance, and telemetry each operate in separate workflows. When role changes, privilege escalation, or offboarding must be replicated across multiple consoles, the control plane becomes inconsistent by design. Policy language, sync timing, and ownership all diverge, so an allowed action in one system may already be revoked in another. That gap is not just operational friction. It is a structural failure in how identity state is represented and enforced across the enterprise.

Practical implication: consolidate identity state and enforcement points so access changes do not depend on manual synchronisation across tools.

Why machine-speed identities break batch governance

An AI agent or workload identity can create and consume access in seconds, which makes hourly or daily reconciliation fundamentally too slow. The problem is not that the identity is complex. The problem is that the session length and the exposure window are now the same thing. If governance only evaluates after the activity has ended, it is observing history instead of controlling access. That is why runtime authorization matters: it turns decision-making into a live control rather than a retrospective compliance event.

Practical implication: move high-risk NHI and agent decisions from batch review into runtime policy enforcement.

How unified authorization changes control-plane design

A unified control plane does not just centralise logging. It creates a shared context for authentication, authorisation, and governance so that every access decision can consider current identity state, device health, and behavioural signals together. That matters because static permission checks assume context is stable for the whole session. In modern environments, context changes continuously. Continuous evaluation is therefore less about speed alone and more about making access decisions against current risk instead of cached assumptions.

Practical implication: design authorization so context updates can change an access decision before the next action is executed.

Threat narrative

Attacker objective: The attacker wants to use identity fragmentation as cover for privilege expansion and sustained unauthorized access.

1. Entry begins when attackers exploit the gap between separate identity tools by using social engineering or stale state to obtain a valid foothold.
2. Credential or privilege abuse follows when one system recognises an authenticated user while another system has not yet reconciled the unauthorized privilege change.
3. Escalation and lateral movement continue because disconnected consoles and batch synchronisation leave no shared, real-time signal to stop the drift.
4. Impact occurs when the attacker operates inside the ungoverned window long enough to expand access, move across systems, and evade timely detection.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Unified identity control planes are now an identity governance requirement, not an architecture preference. When authentication, privilege, governance, and telemetry are scattered across separate tools, the enterprise creates its own enforcement gaps. The article is right to frame this as an architectural problem because policy drift is predictable when identity state is duplicated, delayed, and interpreted differently across consoles. Practitioners should treat the control plane as the governance boundary, not the individual product.

Runtime authorization is now the only control model that matches machine-speed identity behaviour. Human-paced review cycles assume there is time to reconcile, certify, and revoke after the fact. That assumption fails when AI agents and NHIs can execute large volumes of actions in seconds. The implication is not merely to add more review. It is to rethink when the authorization decision is made and what context it must consume.

Identity does not select or combine tools dynamically mid-session; it operates within predefined constraints. That assumption fails when the actor is an AI agent that can spawn, act, and terminate inside one short execution window, because access may be acquired and used before governance tools reconcile the event. The implication is that access review cadences no longer describe the real risk window, so governance must shift to issuance-time and runtime controls.

Identity blast radius is the real metric exposed by fragmented IAM stacks. The article shows that the issue is not simply too many products, but too little shared context across products that all claim authority over the same identity. Omdia’s cited observation about an average of 11 tools reinforces that complexity is now a governance risk in itself. Practitioners should measure how far an identity event can propagate before the stack reaches consensus.

Scattered Spider illustrates how attackers exploit governance latency, not just authentication weakness. The article’s attack sequence shows identity gaps, target-app drift, and delayed IGA reconciliation working together as a single failure pattern. That matters because the weak point is the time gap between systems, not one isolated misconfiguration. Security teams should expect adversaries to keep chaining identity delays until governance and telemetry are truly unified.

What this signals

A unified control plane is becoming the practical test of whether an identity programme can handle humans, service accounts, and AI agents together. If teams still rely on separate policy engines and batch reconciliation, they should expect governance lag to show up first as inconsistent privilege state and then as missed containment opportunities.

Identity blast radius: the important question is no longer how many identity tools exist, but how long it takes for those tools to agree on what changed. When the answer is measured in hours instead of seconds, runtime authorization has already become the stronger control boundary.

For practitioners

• Map identity control-plane fragmentation Inventory where authentication, PAM, IGA, NHI, and authorization decisions are being made in separate consoles, then identify where the same identity change must be updated manually more than once.
• Shorten governance feedback loops Replace batch reconciliation for high-risk identities with event-driven or runtime evaluation so privilege changes are assessed before the next action, not after the next sync window.
• Treat AI agents as first-class identities Apply the same lifecycle, authorization, and revocation discipline to AI agents and service accounts that you already expect for human identities, but validate it at machine speed.
• Rework telemetry into a shared decision layer Correlate identity, device, and threat context in one policy path so authorization can change while the session is still active, instead of waiting for separate tools to agree later.

Key takeaways

• The article’s central warning is that identity silos create governance drift even before AI enters the picture.
• Machine-speed identities compress the window between access grant and exposure, making batch-driven control models increasingly ineffective.
• A single control plane matters because authorization decisions now need shared context at the moment an action is attempted.

Key terms

• Unified Control Plane: A unified control plane is an identity architecture where discovery, access governance, audit, and response operate across humans, machines, and AI agents together. It reduces blind spots caused by siloed tooling and gives security teams context for decisions about permissions, data, and containment.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Identity Silos: Identity silos are isolated identity systems that manage access independently and do not share policy or lifecycle signals cleanly. They create fragmented governance, duplicate administration, and inconsistent audit outcomes, especially in hybrid and multi-cloud environments.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.