AI security needs a control plane across employees, apps and agents

At a glance

What this is: This is an editorial analysis of why AI security can no longer be treated as a single problem, and why runtime control across employees, applications, and agents is the emerging model.

Why it matters: It matters because identity and access teams now have to govern AI behaviour across human, NHI, and autonomous-style execution paths without relying on siloed controls that miss how risk propagates.

👉 Read Lakera's analysis of AI security across employees, applications and agents

Context

AI security is fragmenting because AI now appears in three different places at once: employee workflows, application logic, and agent execution. That breaks the old habit of treating security as one perimeter problem, because the risk path changes depending on whether the AI is assisting a person, embedded in an application, or acting across tools and data.

For IAM, PAM, and NHI teams, the key issue is not just visibility. It is governance across runtime behaviour, delegated access, and cross-system action. Once AI can retrieve data, invoke tools, and execute actions, the question becomes which identity controls are actually able to constrain those actions in the moment.

The source article argues for a unified control plane rather than separate point solutions. That is a familiar pattern in identity governance: when execution is distributed, security has to follow the execution path rather than the application boundary.

Key questions

Q: How should security teams govern AI systems that span employees, applications, and agents?

A: Security teams should govern AI by execution path, not by point solution. That means mapping where people use AI, where applications embed AI, and where agents take action, then assigning a control owner to each handoff. If you cannot trace a prompt to a decision and then to an action, governance is incomplete.

Q: Why do traditional security controls fail for agentic AI workflows?

A: Traditional controls fail because they are usually applied before or after execution, while agentic AI can retrieve data, invoke tools, and act during the session. The risk is produced in the gap between visibility, approval, and action. Runtime enforcement is therefore more relevant than static review alone.

Q: When does AI security become an identity governance problem?

A: AI security becomes an identity governance problem when systems can act with delegated access across enterprise tools and data. At that point, the issue is no longer just model output quality. It is who can authorise, monitor, revoke, and audit the identities that allow AI to act.

Q: How do organisations know whether their AI control plane is working?

A: A working AI control plane can trace behaviour across layers without losing accountability. Organisations should be able to see which identity requested access, which policy allowed the action, and which system executed it. If any one of those links is missing, the control plane is only partial.

Technical breakdown

Why point solutions fail across AI execution layers

AI risk becomes hard to control when the same system spans people, applications, and agents. Each layer has different entry points, different decisions, and different failure modes. A browser assistant leaks through user behaviour, an application leaks through dynamic prompt assembly, and an agent leaks through delegated execution. Traditional tools tend to inspect one layer well and miss the handoffs between layers, which is where the most consequential exposure occurs.

Practical implication: map AI controls to execution layers, then identify where data or decisions cross between them without inspection.

Runtime policy enforcement in the execution layer

The execution layer is where AI stops producing output and starts causing action. That means policy cannot live only in code review, content filters, or data-at-rest controls. Runtime governance has to evaluate what the system is allowed to do at the moment it is about to do it, especially when tool calls, context retrieval, and delegated access are involved. This is where conventional pre-approval models start to fail.

Practical implication: move from static review to runtime decision points for tool use, data access, and action execution.

AI control planes and identity governance

A unified AI control plane is best understood as a governance layer, not a product category. It connects visibility, protection, and policy enforcement across identities that are human, machine, or agentic in behaviour. The identity lesson is straightforward: if AI can act across enterprise systems, then access control, delegation, and auditability have to be managed as one chain rather than as separate tool events.

Practical implication: align AI governance with IAM, PAM, and NHI lifecycle controls so delegated access is observable end to end.

NHI Mgmt Group analysis

The real problem is not AI volume, it is execution spread. AI security fails when organisations treat employee use, application embedding, and agent action as unrelated issues. The controls are then scoped too narrowly to see how prompts become decisions and decisions become actions. The practical conclusion is that AI governance has to follow the execution path, not the surface label.

Point solutions break down because AI risk moves between control domains. A model test, a browser policy, and an API filter can each look adequate in isolation and still fail together. That is because the enterprise risk is produced in the gaps between those controls, where context, delegation, and tool invocation intersect. Practitioners should therefore judge coverage by handoff visibility, not by control count.

Runtime governance is the decisive shift for AI-enabled identity risk. Once a system can retrieve data and invoke tools, the classic assumption that policy can be decided upstream is no longer reliable. This is where NHI, IAM, and agentic oversight converge: if the action is happening now, the decision has to happen now too. The implication is that governance models built for static access are no longer sufficient.

Unified control planes are becoming the identity operating model for AI. The article’s central claim maps cleanly to identity discipline: if one system spans humans, applications, and agents, then access and accountability must be unified as well. That does not mean one tool for everything. It means one governance view across delegated access, runtime use, and downstream effects. Practitioners should re-evaluate whether their current model can actually trace AI action end to end.

AI security is now an identity problem as much as a model problem. The most dangerous failures are not only malformed outputs, but unauthorised actions taken under borrowed or delegated access. That puts IAM, PAM, and NHI teams into the centre of AI governance whether the organisation has planned for it or not. The field should now treat AI execution as part of identity control, not a separate security silo.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• For a broader NHI governance baseline, see NHI Lifecycle Management Guide, which frames provisioning, rotation, and offboarding as one lifecycle rather than separate tasks.

What this signals

Execution-lifetime governance is now the right mental model for AI security. If AI can move from prompt to action inside one workflow, then the real programme question is whether your controls can keep up with the full execution lifecycle, not whether a model was tested in isolation.

The practical signal for IAM and NHI teams is that delegated access must become traceable across tools, not just granted at the source system. When AI touches many surfaces, the control problem starts to resemble lifecycle fragmentation, which is exactly where identity programmes tend to lose accountability.

With 75% of organisations expressing strong confidence in their secrets management capabilities while remediation still averages 27 days, the governance gap is already measurable. That same confidence gap will appear in AI control planes unless practitioners tie policy to runtime and lifecycle evidence.

For practitioners

• Map AI controls by execution layer Inventory where AI appears in employee workflows, embedded applications, and agentic actions. Then document which control owns each handoff between those layers, especially where data, decisions, or tool calls move without inspection.
• Add runtime checkpoints for tool use and action execution Require policy decisions at the point where AI requests data, invokes tools, or triggers a downstream action. Static filters and pre-use review should not be the only line of defence when AI can act across systems.
• Align AI governance with identity lifecycle controls Treat delegated access, service credentials, and agent permissions as lifecycle-managed assets. Review who can grant, revoke, and audit AI-linked access across the full chain, not just the application that exposed it.
• Measure handoff visibility, not just control coverage Test whether your current stack can trace a prompt to an action and an action back to an accountable identity. If that trace fails anywhere, the control plane is fragmented even if individual tools report coverage.

Key takeaways

• AI security has become a cross-layer governance problem because risk now moves through employees, applications, and agents at the same time.
• Point controls miss the handoffs where prompts become decisions and decisions become actions, which is where the most material failures occur.
• Practitioners should evaluate AI control planes by traceability, runtime enforcement, and lifecycle accountability rather than by the number of tools deployed.

Key terms

• Execution Layer: The execution layer is the part of an AI system where outputs turn into actions, such as tool calls, data retrieval, or workflow changes. It matters because governance failure often appears here, not at model generation time. For autonomous or agentic behaviour, the layer is where runtime control must exist.
• AI Control Plane: An AI control plane is a governance layer that provides visibility, policy enforcement, and accountability across AI use. It is not a single product. In practice, it connects identity, runtime decisions, and downstream actions so organisations can manage AI consistently across employees, applications, and agents.
• Delegated Access: Delegated access is permission granted to a system or agent to act on behalf of another identity. In AI contexts, it creates risk when the delegate can retrieve data, call tools, or make decisions beyond the original intent. Governance must therefore include revocation, scoping, and audit trails.
• Handoff Visibility: Handoff visibility is the ability to see what happens when control passes from one system, identity, or layer to another. It is a key identity governance requirement because many AI failures occur between controls, not inside them. Without it, organisations can overestimate coverage and miss real exposure.

What's in the full article

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

• How the AI Defense Plane is positioned to connect visibility, runtime protection, and policy enforcement in one operating model
• The article's breakdown of the three AI exposure layers, including where employee, application, and agent risk diverge
• The specific language Lakera uses to describe execution-lifecycle control and how it maps to day-to-day AI security work
• The vendor's own framing of where practitioners should start when AI is already embedded in the business

👉 Lakera's full article expands on the AI Defense Plane and the control gaps between AI layers

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 governance in your organisation, it is worth exploring.