By NHI Mgmt Group Editorial TeamPublished 2026-04-22Domain: Agentic AI & NHIsSource: Lakera

TL;DR: AI agents now retrieve data, invoke tools, and execute workflows in real time, which means access can be valid while the outcome is still wrong, according to Lakera. The security model is shifting from permission checks to behaviour and policy enforcement across agent actions, tool calls, and runtime context.


At a glance

What this is: This is an analysis of how AI agent security is moving from access control to outcome control, with runtime policy and observability becoming the next control layer.

Why it matters: It matters because IAM, PAM, and NHI teams now need to govern what an agent is allowed to do in context, not just what it can reach.

By the numbers:

👉 Read Lakera's analysis of outcome control for AI agents on Google Cloud


Context

AI agent governance is moving beyond classic access control. In this model, an agent may be authenticated, authorised, and connected correctly, yet still produce an unsafe or incorrect action because its behaviour changes with context, prompt inputs, or tool responses.

That creates a new identity problem for IAM and NHI programmes. The control question is no longer only whether an agent has permission to call a tool, but whether the tool call, timing, and resulting action are appropriate for the current task and risk context.


Key questions

Q: How should security teams govern AI agents that can take actions across systems?

A: They should govern the agent at the point of action, not only at authentication. That means brokering tool calls through a control layer, applying context-aware policy, and logging decisions as they happen. The goal is to stop unsafe outcomes even when access itself is technically valid.

Q: Why do AI agents complicate least-privilege design?

A: Because the agent’s next move is not always knowable at provisioning time. Least privilege assumes the task scope is stable and can be predicted in advance, but agentic systems can change their path based on runtime context and intermediate results. Practitioners need policies that bound outcomes as well as access.

Q: What breaks when organisations rely only on access control for AI agents?

A: They can approve the right identity and still allow the wrong behaviour. Access control does not reliably stop prompt-driven misuse, unsafe tool sequencing, or sensitive-data exposure that happens after a legitimate request is already underway. Behavioural enforcement must sit alongside permission checks.

Q: How do IAM teams decide whether an AI agent needs runtime policy enforcement?

A: Use runtime policy whenever the agent can retrieve data, invoke tools, or trigger workflows that have operational or data-loss impact. If the action can be harmful even when authorised, static entitlements are not enough. That is the point where outcome control becomes necessary.


Technical breakdown

Why access control is not enough for AI agents

Traditional access control answers a narrow question: can this identity reach a resource or invoke a function? Agentic systems extend that model because the same permission can produce different outcomes depending on the prompt, intermediate reasoning, prior context, and tool response. In practice, an agent can stay within its granted scope while still making a harmful choice, such as exposing sensitive data, chaining unsafe actions, or misusing a legitimate API. That is why behaviour-aware control is becoming a separate layer rather than a replacement for IAM.

Practical implication: teams need runtime policy that evaluates actions in context, not only permission at the point of access.

Agent gateways and control points in cloud AI platforms

A centralized agent gateway or control point creates a governance choke point for identity, access, policy, and observability. Architecturally, it sits between the agent and the tools or data sources it can reach, letting security teams inspect requests, apply policy, and log behaviour before actions complete. This is especially important where agents can retrieve data, call APIs, or trigger workflows across multiple systems. Without that control plane, security teams are left stitching together logs after the fact instead of governing the action itself.

Practical implication: place policy enforcement and telemetry where agent tool calls are brokered, not only where users authenticate.

Outcome control as a new security layer for agentic AI

Outcome control means judging whether an action is acceptable given the current context, not merely whether the actor is technically entitled to perform it. That requires signals such as prompt injection detection, tool-use review, sensitive data handling, and multi-step interaction analysis. It also changes the blast-radius model: an agent can start with legitimate access and still drift into an unsafe path if the prompt or context is manipulated. For identity teams, this is a governance shift from entitlement management to decision governance.

Practical implication: define policy for unsafe outcomes, not just forbidden resources or static entitlements.



NHI Mgmt Group analysis

Outcome control is becoming the missing layer in agentic identity governance. Access control still matters, but it cannot answer the question of whether an agent should take a specific action in a specific context. When the same entitlement can produce safe or unsafe behaviour depending on prompt and tool context, the programme needs a control point that evaluates intent, sequence, and result. Practitioners should treat this as a new governance layer, not a tuned version of old IAM.

The assumption that valid access produces valid behaviour is collapsing for AI agents. That assumption was designed for deterministic systems where permissions and outcomes were tightly coupled. It fails when an agent can retrieve data, call tools, and alter its own next step based on runtime context. The implication is that entitlement models alone no longer describe risk well enough for agentic systems.

Agent gateways matter because they make identity decisions observable at the moment of action. This is where policy can move from provisioning-time intent to runtime enforcement across tool calls, API requests, and workflow execution. The important shift is not simply visibility, but the ability to treat agent behaviour as governable identity activity. Practitioners should expect control architecture to move closer to the action path.

NHI and agentic AI governance are converging around the same problem: unchecked execution scope. Whether the subject is a service account, a workload, or an AI agent, the governance gap appears when access is broader than the task and behaviour can escape static review. The difference is that autonomous or semi-autonomous action compresses the time available to detect and correct misuse. Identity teams should align policy, telemetry, and lifecycle governance across all non-human actors.

Named concept: outcome control. This is the discipline of governing what an AI agent does, not just what it can touch. It becomes necessary when behaviour is shaped by runtime context, intermediate tool responses, and chained actions that are not fully predictable at provisioning time. Practitioners should treat outcome control as a first-class requirement for agent governance, especially in high-risk workflows.

From our research:

  • 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
  • Another 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 same survey.
  • For a broader view of the control problem, see OWASP Agentic AI Top 10 for the runtime risks that sit outside classic access review.

What this signals

Outcome control will become a programme design requirement, not an experimental control pattern. Once AI agents can act across tools and systems, identity teams need a policy layer that judges the appropriateness of actions in context. That is a different operating model from static entitlement management, and it should be built into governance roadmaps now.

With 53% of security leaders expecting AI to run major portions of infrastructure autonomously within three years, per The 2026 Infrastructure Identity Survey, teams should assume agent governance will move into core IAM and PAM processes.

Access review alone will not close the gap. The issue is not just who can authenticate or what a permission set contains. The issue is whether a runtime decision path can be inspected, constrained, and stopped before the wrong outcome is committed. That makes observability and policy enforcement operational, not optional.


For practitioners

  • Define outcome-based policy rules Specify unacceptable agent actions in context, such as sensitive-data disclosure, unsafe transaction execution, or tool misuse, rather than relying only on resource-level allowlists.
  • Broker agent actions through a control point Place identity, policy enforcement, and logging between agents and the tools or APIs they use so decisions are evaluated before execution completes.
  • Instrument prompt and tool-response checks Add detection for prompt injection, manipulative inputs, and risky multi-step interactions so security teams can see when an agent is being steered off course.
  • Review agent privileges by workflow outcome Reassess access based on what the agent is supposed to accomplish, then reduce permissions that are not necessary for the specific task path.

Key takeaways

  • AI agent security is no longer only about access, because a legitimate permission set can still produce an unsafe outcome.
  • The governance gap is moving to runtime, where tool calls, context, and behaviour determine whether the action should proceed.
  • Identity teams should treat outcome control as a new policy layer across IAM, NHI, and agentic AI programmes.

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 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10A2Agent tool misuse and unsafe actions are central to this article.
NIST AI RMFOutcome governance and trustworthiness are core AI RMF concerns.
NIST Zero Trust (SP 800-207)PR.AC-4Least-privilege and continuous verification underpin agent access decisions.

Enforce continuous verification for agent actions and scope permissions to the minimum required task.


Key terms

  • Outcome Control: Outcome control is the practice of governing what an AI agent is allowed to do in context, not just what it can access. It combines runtime policy, behavioural inspection, and execution-time enforcement so unsafe actions can be blocked even when the underlying identity is properly authorised.
  • Agent Gateway: An agent gateway is a brokered control point between an AI agent and the tools, data sources, or APIs it uses. It centralises policy enforcement, logging, and inspection so security teams can manage agent actions at the moment they are executed, not only at the point of login or provisioning.
  • Runtime Policy: Runtime policy is the set of rules applied while an agent is operating, based on current context rather than static entitlement alone. It is used to decide whether a tool call, data request, or workflow step should continue, be limited, or be stopped before harmful execution completes.
  • Prompt Injection: Prompt injection is a manipulation technique that steers an AI system away from its intended task by placing malicious instructions in user input, retrieved content, or tool output. For agents, it is especially dangerous because it can alter behaviour after access has already been granted.

What's in the full article

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

  • How the Google Cloud Gemini Enterprise Agent Platform and Check Point AI Defense Plane are connected in the runtime control flow
  • The specific agent-gateway and agent-registry functions used to discover agents and apply policy before deployment
  • Runtime examples showing how prompt injection, sensitive data exposure, and unsafe tool use are detected and blocked
  • The practical deployment context for financial services and other high-risk agent workflows

👉 Lakera's full article covers the control-point architecture, runtime decision layer, and financial-services example in more detail.

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-04-22.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org