TL;DR: Platform leaders at KubeCon North America described a three-lane model for AI adoption that separates low-risk experiments, managed internal apps, and critical production systems, while highlighting how procurement, automation, and shared platform controls are becoming the main blockers to safe scale, according to Cerbos. The real issue is not AI novelty but identity and authorization models that must work for non-human access without collapsing developer velocity.
At a glance
What this is: This is a platform engineering roundtable recap showing that enterprises are moving toward a three-lane model for AI adoption, with shared platform controls and automated governance emerging as the practical answer.
Why it matters: It matters because IAM, NHI, and platform teams now need one governance model that supports experimentation, managed internal tools, and production-grade AI without forcing every use case through the same control path.
By the numbers:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
- 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.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.
👉 Read Cerbos' analysis of AI governance, platform engineering, and the three-lane model
Context
AI adoption in enterprise environments is increasingly being shaped by the identity and authorization controls that sit underneath it. The article centers on a three-lane operating model for AI, where low-risk experimentation, managed internal applications, and critical production systems are governed differently so that innovation does not get trapped in production-grade controls from day one.
That matters to IAM, NHI, and platform engineering teams because AI features do not behave like conventional human applications. They rely on non-human access, shared platform services, and policy enforcement that must be automated if teams want to preserve velocity. The article’s core point is that governance has to move into the platform layer rather than rely on manual coordination and developer exception handling.
The strongest signal is that organisations are converging on shared services for authentication, authorization, logging, and compliance. In other words, AI governance is turning into an identity architecture problem, not just a tooling or procurement problem.
Key questions
Q: How should security teams govern AI experimentation without slowing delivery?
A: Use lane-based governance. Low-risk experiments belong in isolated sandboxes with minimal guardrails, while managed and critical workloads should inherit progressively stronger controls. The goal is to make experimentation safe by default, not to force every AI use case through production-grade approval gates before value is proven.
Q: Why do AI agents create different identity risks than ordinary applications?
A: AI agents act as non-human identities that can make decisions and execute work at machine speed, so overbroad access becomes dangerous very quickly. They do not provide human judgment to stop themselves from taking harmful actions, which makes least privilege and strong authorization boundaries much more important.
Q: What do platform teams get wrong when they leave authorization inside each app?
A: They create fragmented policy enforcement, inconsistent access decisions, and repeated engineering work across every AI project. Shared authorization in the platform layer gives teams one place to update policies, one place to log decisions, and one place to enforce compliance across many applications.
Q: How do organisations keep AI governance from becoming a blocker?
A: Automate it. The article’s core lesson is that governance only works when it is invisible to developers and embedded in the platform. If teams must request manual exceptions or wait on slow approvals, they will route around the controls and create shadow AI instead.
Technical breakdown
The three-lane model for AI governance
The three-lane model separates AI use cases by criticality. The fast lane is for low-risk experimentation with minimal guardrails, often in isolated environments such as Cloud Run or similar sandboxed execution. The managed lane is for internal applications with defined boundaries and standardized controls. The critical lane is reserved for production systems that require full governance, observability, and compliance. This is not about lowering standards, but about matching control depth to risk so experimentation can happen without forcing every project through production-grade assurance on day one.
Practical implication: map AI initiatives to a lane before they enter the build queue, and define the control baseline for each lane in advance.
Shift down: moving authorization into the platform layer
The article argues that shift left has become a burden-shifting pattern, while shift down places authentication, authorization, and compliance into shared platform services. In practice, this means policy enforcement is externalized from each app and inherited from common infrastructure. That architecture reduces duplication, improves consistency, and makes policy changes propagate everywhere at once. For identity teams, this is the difference between one enforceable control plane and fifty custom implementations that drift over time.
Practical implication: centralize authorization and compliance controls in shared platform services instead of embedding them repeatedly in individual AI applications.
AI agents as overprivileged non-human identities
AI agents are exposing a long-standing identity problem rather than inventing a new one. They operate with access, autonomy, and machine speed, but without human judgment to compensate for overbroad permissions. That makes least privilege operationally decisive rather than merely aspirational. If an agent is allowed to act across too many systems, it can compound decisions faster than a human reviewer can intervene. The security model must assume non-human execution without contextual restraint.
Practical implication: treat AI agents as non-human identities that require tightly scoped, task-specific authorization and logging from the start.
Threat narrative
Attacker objective: The objective is to exploit broad AI access paths to achieve outsized operational change, data exposure, or infrastructure disruption before human controls can contain it.
- Entry occurs when AI tools are introduced into developer portals, internal workflows, or sandboxed business applications with broad initial access to data and systems.
- Escalation happens when those tools are reused, hardened, or promoted from experimentation into managed or production environments without re-scoping the underlying authorization model.
- Impact follows when overprivileged AI systems can execute too broadly across infrastructure, increasing the blast radius of faulty or malicious actions.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
The real governance failure is not AI complexity, but the assumption that all AI deserves production-grade controls from day one. The article shows that organisations are splitting experimentation from critical operations because a single control standard slows adoption and pushes teams to route around governance. That is a platform design problem, not a user discipline problem. Practitioners should treat lane design as a governance primitive, not an afterthought.
Least privilege for AI agents is now a control boundary, not a best practice slogan. The article’s warning is clear: AI systems do not compensate for overbroad access with human judgment, so permission scope becomes the main determinant of blast radius. OWASP-NHI and NIST CSF both point toward explicit access scoping and shared accountability, but the operational lesson is simpler. If the access model is too generous, the platform has already lost the argument.
Shift down is becoming the dominant identity pattern because scattered application-level controls cannot keep pace with AI deployment speed. Shared authorization, logging, and compliance services let policy changes propagate without cross-team coordination overhead. That is especially important for NHI governance, where the identity subject is often invisible to business teams and easy to overprovision. The implication is that identity architecture now sits inside platform engineering, not beside it.
AI adoption is collapsing the old boundary between experimentation governance and production governance. The article describes a progression from sandboxed domain tools to hardened enterprise use, which means lifecycle, authorization, and observability must follow the asset as it matures. This is where IAM and NHI teams need a shared operating model. If the controls cannot travel with the use case, the organisation will either stall innovation or accept unmanaged risk.
Runtime authorization needs to be built for shared fate, because AI features are no longer isolated point solutions. When a policy update in the platform layer changes behaviour across all AI-enabled applications, governance becomes a system property instead of a project task. That is the right direction for NHI and agentic access alike. Practitioners should design for centralized policy inheritance, because the alternative is repeated reinvention and inconsistent enforcement.
From our research:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to the 2026 Infrastructure Identity Survey.
- From our research: 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, according to the 2026 Infrastructure Identity Survey.
- The gap between experimentation and control is closing only when policy enforcement moves into the platform layer, where identity decisions can be applied consistently across every AI-enabled workload.
What this signals
Identity governance for AI is moving from project-level controls to platform-level inheritance. That shift matters because organisations cannot keep multiplying bespoke authorization logic every time a team adds an AI feature. The programme signal is clear: if policy cannot be reused, AI adoption will outpace governance and force more exceptions than controls.
Least privilege will become the main differentiator between controlled AI and operational chaos. With 70% of organisations already granting AI systems more access than human employees, per the 2026 Infrastructure Identity Survey, the next maturity step is to make access scope a design input rather than a post-deployment review item. Teams should expect tighter entitlement reviews and stronger platform standardization.
Platform engineering is becoming an identity function whether organisations label it that way or not. Shared authentication, authorization, logging, and compliance services are now the practical control plane for AI adoption. Practitioners should prepare for closer alignment between IAM, NHI, and platform teams, because the control boundary is moving downward into infrastructure.
For practitioners
- Define lane-specific control baselines Classify AI use cases into fast, managed, or critical lanes before build work starts. Tie each lane to a minimum set of controls for authentication, authorization, logging, and compliance so teams are not negotiating scope during delivery.
- Externalize authorization into shared platform services Move access enforcement out of individual applications and into reusable platform layers so policy changes propagate consistently. This reduces duplication and makes it possible to govern many AI features with one policy model instead of many bespoke ones.
- Scope AI access as if every system were a non-human identity Review whether AI tools have broader access than the task requires, especially when they touch developer portals, knowledge systems, or infrastructure automation. Narrow entitlements to the smallest operational boundary that still allows the use case to function.
- Automate compliance so developers do not have to remember it Build sandbox environments and policy checks that apply automatically, because manual exception handling is the fastest path to shadow AI and policy drift. The secure path should also be the easiest path for teams to follow.
Key takeaways
- AI adoption is forcing organisations to separate experimentation from production rather than treat every use case as a critical system.
- Shared authorization and automated compliance are emerging as the scalable answer to AI governance in platform-heavy environments.
- Overprivileged AI access is the core risk signal, and least privilege remains the most effective control lever for reducing blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AI agents need scoped access and runtime control in shared platform environments. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | AI tools operate as non-human identities with overprivilege risk and shared access needs. |
| NIST CSF 2.0 | PR.AC-4 | Shared authorization and least privilege map directly to access control governance. |
Apply agentic access boundaries before production rollout and externalize policy enforcement.
Key terms
- Three-lane model: A governance pattern that separates AI work into fast, managed, and critical lanes based on business risk and control depth. It lets organisations support experimentation without forcing every use case into production-grade governance, while still reserving full assurance for systems that handle sensitive or mission-critical operations.
- Shift down: An identity and security operating model that moves authentication, authorization, logging, and compliance into shared platform services instead of scattering them across individual applications. It reduces duplication, improves consistency, and makes policy changes propagate across all workloads that inherit the platform layer.
- Non-human identity: Any machine-based identity used by software, services, or AI systems to access data or infrastructure. In this context it matters because the identity can act without human judgment, so entitlement scope, logging, and lifecycle controls must be designed for machine-speed execution rather than human review cycles.
- Shared authorization: A centralized policy enforcement approach where multiple applications consume the same decision engine instead of implementing their own access logic. This reduces drift, makes governance easier to audit, and gives platform teams one place to update controls when AI behaviour or risk appetite changes.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by Cerbos: a platform engineering roundtable recap on AI adoption, governance, and the three-lane model. Read the original.
Published by the NHIMG editorial team on 2025-11-18.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org