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

At a glance

What this is: Lakera argues that AI security is no longer one problem because risk now spans employees, applications and agents, making a unified control plane the practical model.

Why it matters: IAM, security architecture and governance teams need to control AI behaviour at runtime across human, application and agentic contexts, not just at the point of access.

Context

AI security is the set of controls that govern how people, applications and autonomous systems interact with models, data and tools. The article’s core claim is that this risk has fragmented across multiple execution surfaces, so traditional point solutions no longer give a complete picture.

For IAM and security teams, the shift matters because the control problem has moved from isolated access checks to continuous oversight of how AI is used, what it can reach, and what actions it can take. The article frames that as a single control plane rather than separate defences for users, apps and agents.

Key questions

Q: How should security teams govern AI in the security stack?

A: Security teams should treat AI as a governed decision aid, not an autonomous authority. Define where it can assist detection, prioritisation, and enrichment, then require human or policy approval for privileged actions and access decisions. The key control is traceability, so every AI-supported recommendation can be reviewed, challenged, and overridden.

Q: Why do point solutions fail for AI security?

A: Point solutions fail because AI risk is distributed across human use, application behaviour and agent actions. A control that sees only one layer misses the handoff where data, context and authority combine. The result is fragmented oversight, which is exactly where harmful AI behaviour tends to emerge.

Q: What are the signs that AI governance is too fragmented to support scale?

A: Common signs include duplicated governance tools, inconsistent policies across business units, and teams managing AI or data controls in isolation. Another warning is when organisations cannot confidently explain how data is governed across platforms. If governance only exists in pockets, scaling AI usually creates more risk, not less, because controls fail to follow the use case end to end.

Q: What happens when AI agents are allowed to act on behalf of users without tight consent controls?

A: When AI agents can access sensitive APIs without tight guardrails, a prompt mistake, hallucination, or hijacked instruction can turn delegated access into unauthorized action. The risk is not only data exposure. It also includes actions taken with valid credentials that users did not intend, which makes review, containment, and attribution much harder after the fact.

Technical breakdown

Why point solutions miss AI execution risk

Traditional security stacks were built around discrete boundaries such as applications, data stores and infrastructure. AI breaks that model because the same workflow can begin with a human prompt, pass through an application, and end with an agent taking an action through delegated access. Each step may look normal in isolation, but the security meaning changes once the steps are chained together. The operational blind spot is not the model alone. It is the handoff between context, decision and execution, where legacy controls lose continuity.

Practical implication: map AI controls to the full execution path, not just the model endpoint or application front door.

Why runtime governance matters more than static policy

The article’s control-plane argument is really about timing. AI systems can retrieve data, invoke tools and generate actions in real time, which means policy enforced only at build time or storage time misses the moment when harm occurs. Runtime governance means evaluating what the system is allowed to do at the point it acts, not only what it was allowed to access earlier. That distinction is central for AI security because the relevant risk is often the action itself, not the prompt or dataset alone.

Practical implication: enforce policy where AI decisions are executed, with visibility into prompts, tool use and resulting actions.

How employees, applications and agents create a shared risk surface

The article separates three AI exposure layers, but the important technical point is that they are not independent. Employees may paste sensitive data into copilots, applications may assemble prompts dynamically from internal systems, and agents may combine retrieval with tool use to complete tasks. Data and decisions move across these layers, which creates compounding exposure that a single control cannot contain. Security teams should treat those layers as one operational system with multiple entry points and one downstream outcome surface.

Practical implication: correlate telemetry across user activity, application behaviour and agent actions to detect chained AI risk.

NHI Mgmt Group analysis

AI security has become a control-plane problem, not a point-control problem. Once AI reaches across employees, applications and agents, the unit of governance stops being the single tool or model and becomes the execution path. That changes how practitioners think about visibility, enforcement and accountability, because risk now travels across systems rather than living inside one of them. The implication is that AI security programmes need to be designed around coordination, not isolated inspection.

Visibility into AI use is now a governance requirement, not a nice-to-have telemetry layer. The article correctly frames the issue as fragmented by design, because AI usage often starts outside formal architecture and continues through systems that legacy controls never mapped. That fragmentation makes blind spots a structural feature, not an operational accident. Practitioners should treat discovery and runtime observability as core control objectives across the full AI estate.

Execution lifecycle control is the decisive boundary for AI governance. The article’s strongest insight is that harm emerges when a prompt becomes an application action and then an agent action. That means the most important question is no longer only who can access a model, but what the system can do after access is granted. Security teams should align governance to actionability, not just access.

Human, application and agent behaviour now share the same security surface. Employees can introduce risk, applications can amplify it, and agents can execute it. Those are different actor types, but they now participate in one connected chain, which means separate control regimes leave gaps at the seams. Practitioners need a programme view that spans IAM, application security and agent oversight together.

Unified AI control will become the differentiator between managed and unmanaged adoption. As organisations expand AI use, the practical dividing line will be whether they can observe, govern and constrain AI consistently across user workflows, application logic and delegated actions. That is the new identity-security frontier for AI programmes, and it will reward teams that design for cross-surface governance early.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.

What this signals

AI control has to move closer to execution. The practical lesson for governance teams is that access management alone does not describe what AI systems do once they are inside workflows. Control needs to follow the action path, because that is where prompt, context and delegated authority combine into operational risk.

Cross-surface observability will define mature AI governance. Teams that can correlate employee behaviour, application events and agent actions will be able to distinguish normal AI use from risky AI use. That creates the foundation for policy enforcement, incident review and future accountability across the AI stack.

For practitioners

• Map the AI execution lifecycle Identify where AI begins in employee workflows, where applications assemble prompts and context, and where agents can take action. Use that map to define which controls belong at discovery, at decision time and at execution time.
• Enforce runtime policy for AI actions Apply rules at the moment an AI system retrieves data, calls tools or triggers an external action. Static approval checks and storage controls are not enough when the risk materialises during execution.
• Correlate telemetry across AI surfaces Tie together employee usage, application events and agent activity so that one workflow can be traced end-to-end. That is the only reliable way to see how a prompt becomes a downstream action.
• Classify delegated AI access explicitly Separate human access, application permissions and agent delegation in your governance model so that each can be reviewed against its actual authority. Treat delegated access as a distinct control problem, not as an extension of the user account that triggered it.

Key takeaways

• AI security is fragmenting across users, applications and agents, which makes isolated controls incomplete by design.
• The important control point is runtime behaviour, because that is where prompts, context and delegated actions become real outcomes.
• Programmes that can correlate visibility and policy across the full AI execution lifecycle will be better positioned to govern adoption without losing oversight.

Key terms

• Automation control plane: The central system that coordinates actions across other tools, services, and data stores. In practice, it becomes a high-trust orchestration layer that can hold credentials and issue privileged requests, which means compromise of the plane can cascade into many downstream systems.
• Execution Lifecycle: The end-to-end sequence from AI input to system action, including prompts, context retrieval, tool calls and resulting outcomes. For autonomous or delegated AI, this lifecycle is where security controls must operate because the highest-risk decisions happen during execution.
• Delegated AI Authority: Delegated AI authority is the permission a person gives an assistant to act inside business systems on their behalf. It turns a conversational tool into an execution layer, which means security teams must govern scope, auditability, and revocation with the same seriousness they apply to privileged access.
• Cross-Surface Visibility: The ability to correlate AI activity across employee use, application behaviour and agent actions. This is essential for spotting chained risk, because isolated logs rarely explain how a prompt became a downstream operational event.

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 building or maturing an IAM programme, it is worth exploring.