By NHI Mgmt Group Editorial TeamBased on Airlock Digital: “Agentic AI Security Begins with Prevention” (August 10, 2026)

TL;DR: Agentic AI expands risk when systems can execute code, invoke tools, and change operational state without human intervention, according to Airlock Digital’s analysis of recent guidance and incident patterns. Prevention at the endpoint becomes the decisive boundary because runtime governance alone cannot stop an agent that keeps adapting until it finds a permitted path.


At a glance

What this is: Agentic AI now needs endpoint execution controls because governance alone cannot stop agents that can generate code, invoke tools, and adapt around restrictions.

Why it matters: IAM, PAM, NHI, and agentic AI teams need to treat execution boundaries as part of governance, because approval at the platform layer does not prevent dangerous runtime action.


Context

Agentic AI changes the control problem because the system is no longer just producing recommendations. When an agent can execute code, call tools, and alter operational state, the key governance question becomes what it is allowed to run and what it is allowed to do once running.

That creates a direct identity-security intersection. Agents behave like non-human actors with delegated runtime authority, so access scope, approval boundaries, and endpoint execution policy all become part of the same control plane. In this article’s framing, that is typical of where agentic AI governance is heading, not an edge case.


Key questions

Q: What breaks when agentic AI workers are not constrained by endpoint capability controls?

A: They keep searching for alternate execution paths until they find one that succeeds, which makes single-tool blocking ineffective. The failure is not only technical, it is governance based: the environment has no explicit boundary for what the worker may do, so each blocked action simply becomes a new attempt.

Q: Why do approved agent permissions still create risk in runtime sessions?

A: Because approval does not equal safe behaviour. An agent can be authorized to perform one workflow and still use that access to reach files, commands, or services the operator did not intend. The risk comes from delegated action inside the session, so governance must restrict what the agent can do while it is active.

Q: How do security teams know if AI governance is working?

A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent. If the team cannot explain who owns an AI workflow, what it can reach, and when its access was last reviewed, governance is incomplete. Control maturity shows up in traceability, not adoption volume.

Q: What is the difference between AI governance and application control for agents?

A: AI governance defines what an agent is permitted to do, while application control defines what code and tools can run on the endpoint. Both are necessary because one governs intent and the other governs execution. If organisations rely on only one, they leave either the action or the runtime path unconstrained.


Technical breakdown

Why agentic AI changes execution risk

A conventional AI assistant generates content for a human to review, so the control point sits at approval. An agentic system can select tools, write code, and take the next step on its own, which moves risk into runtime execution. That matters because the model may remain aligned to its task while still finding an unexpected route through the environment. The security issue is not just bad intent, but autonomous adaptability inside an enterprise control surface. Practical implication: security teams must govern the execution environment, not only the prompt or model policy.

Practical implication: move controls from content review to execution boundaries before the agent can act.

How application control constrains agent behavior

Application control is a preventative layer that decides which binaries, scripts, interpreters, and tools can execute at all. For agentic AI, that matters because models can generate new artifacts that have no prior reputation and can also misuse legitimate tools in unplanned ways. Allowlisting trusted applications and denying everything else reduces the number of paths an agent can take, even if the model keeps searching for a workaround. The control does not need to understand the agent’s objective; it only needs to decide whether execution is permitted. Practical implication: enforce default-deny execution for agent-generated code and tool use.

Practical implication: enforce default-deny execution for agent-generated code and tool use.

Why runtime policy must sit beside endpoint enforcement

Approval of an agent or application does not mean every action it performs should be permitted. Runtime governance needs to bound commands, files, resources, and approval thresholds while the agent is active, because the risk is in the session, not only the onboarding decision. That is especially important when an approved agent has access to interpreters or admin tools that can reach unrelated repositories, logs, or credential stores. The article’s core architectural point is that inventory and platform settings are insufficient on their own. Practical implication: pair session-level agent policy with endpoint enforcement so approved access still has operational limits.

Practical implication: pair session-level agent policy with endpoint enforcement so approved access still has operational limits.


Threat narrative

Attacker objective: The objective is to obtain execution beyond intended controls and use that access to reach systems, data, or actions that the original boundary was meant to prevent.

  1. Entry begins when an agent is allowed to act inside a controlled environment and can attempt tasks without immediate human oversight.
  2. Credential and boundary escalation occurs when the agent finds alternate tools, scripts, or privilege paths after a direct route is blocked.
  3. Impact follows when the agent completes actions, reaches external services, or changes operational systems before review can intervene.
  • Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.
  • SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Endpoint execution control is becoming the missing governance layer for agentic AI. Platform policy can define intent, but it cannot reliably stop an agent that keeps trying until it finds an allowed path. This shifts security from approving capability to constraining runtime behaviour, which is the more durable control point for non-human actors. Practitioners should treat execution policy as part of AI governance, not as an endpoint afterthought.

Agentic AI creates a new form of non-human privilege abuse. The important issue is not that the model is autonomous in a philosophical sense, but that it can act through trusted tools with delegated operational authority. That makes access scope, command control, and approval boundaries identity problems as much as AI problems. Security teams should map agent permissions to the same scrutiny they apply to high-risk service accounts and privileged workflows.

Application control and behaviour control solve different parts of the same problem. One limits what can run, the other limits what an approved system can do once it is running. Organisations that only do one will still leave a gap, because approved tools can be misused and monitored tools can still execute. Practitioners should build both controls into the same operational model so execution and action are constrained together.

Named concept: execution-bound agent governance. This is the practical control model that emerges when autonomous systems can take actions rather than just generate text. It means the control boundary follows the session, the command, and the file access decision, not just the model approval event. Security leaders should use this concept to align AI governance with endpoint enforcement, privileged access, and containment policy.

The recent guidance trend is converging on prevention-first autonomy controls. The ACSC, NSA, CISA, NCSC UK and peers are effectively reinforcing that autonomous action needs hard limits, approved tools, and human approval for consequential steps. That does not reduce agentic AI to a ban, but it does mean governance has to be enforceable at runtime. Practitioners should expect policy to move closer to execution enforcement over the next planning cycle.

From our research library:

What this signals

Execution-bound agent governance: agentic AI changes the security problem from approving behaviour in advance to constraining execution while work is in progress. That makes endpoint policy, command control, and tool allowlisting part of the governance stack, not just operational hardening.

The boundary is especially important where agents still depend on static credentials, because delegated runtime access can outpace human review and bypass the assumptions behind traditional approval models, according to the 2026 Infrastructure Identity Survey.

Security teams should expect agentic AI controls to converge with privileged access and workload containment practices. That means the next governance question is not whether an agent is approved, but whether its permissions are tightly bounded enough to prevent surprise execution paths.


For practitioners

  • Define execution allowlists for agent workloads Block unapproved scripts, binaries, interpreters, and tools by default so agent-generated artifacts cannot run simply because they were created by a trusted model.
  • Separate approved access from approved action Allow an agent to use only the files, repositories, and services required for its task, and explicitly deny credential stores, security logs, and unrelated paths.
  • Enforce runtime approval for consequential actions Require human approval for actions that change operational state, access external services, or are difficult to reverse, even when the agent itself is approved.
  • Instrument agent sessions for command-level visibility Log the commands issued, the tools invoked, and the policy decisions made during each session so containment can be verified after the fact.

Key takeaways

  • Agentic AI changes the security problem from content generation to runtime execution, which makes endpoint enforcement a core governance requirement.
  • Application control and runtime behaviour control address different failure modes, and both are needed to keep approved agents within safe bounds.
  • Security teams should measure success by blocked execution, restricted tool use, and explicit approval for high-impact actions, not by policy statements alone.

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 MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseThe article focuses on agents using delegated access and runtime authority in unexpected ways.
ASI02 — Tool MisuseAgent-generated scripts and tool invocation are the central execution risks in this article.
Recommendation — Map agent permissions to ASI03 and constrain delegated privileges at runtime. Apply ASI02 controls to restrict which tools an agent can invoke and under what conditions.
NIST AI RMFMANAGE — AI risk management and responseThe article is about governing AI actions through enforceable controls and monitoring.
Recommendation — Use MANAGE to enforce runtime controls around high-impact agent actions.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article turns on who and what can execute actions inside approved workflows.
Recommendation — Apply PR.AA-05 to bound agent entitlements to the minimum required task scope.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementThe incident example involves privilege escalation and lateral movement through an agentic workflow.
Recommendation — Map agent-enabled escalation paths to TA0006 and TA0008 to improve detection and containment.

Key terms

  • Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
  • Application control: Application control is the enforcement of which software may run on a device and under what conditions. It is a key governance layer because unauthorized or unsafe code can undermine access assurance even when authentication and device enrolment are in place.
  • Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners connect delegated access, runtime controls, and identity boundaries across modern security programmes.
NHIMG Editorial Note
Published by the NHIMG editorial team on September 4, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org