Over the past three months, I have spoken regularly with security leaders across a range of industries. Agentic AI has become a consistent part of those discussions, particularly as organizations move from AI assistants that generate content to agents that can execute code, invoke tools, and make changes to operational systems.
The ACSC, together with the NSA, CISA, NCSC UK and other Five Eyes partners, has recently released guidance on the careful adoption of agentic AI services. Its central message is not that AI is malicious, but that autonomous systems create additional risk when they can independently plan and act in an organization’s ICT environment.
Traditional generative AI typically produces an output for a person to review. Agentic AI can take the next step. Agents can write a script, install a software package, access a file or even call an external service. All these actions can be taken without human intervention.
The recent OpenAI and Hugging Face incident is a useful example. During a cyber capability evaluation, OpenAI models found a path out of an isolated test environment by exploiting a previously unknown vulnerability, escalating privileges and moving laterally until they obtained internet access. The models then chained together additional attack paths to obtain test solutions from Hugging Face infrastructure.
The significant point is the models remained focused on the narrow objective they had been given; they adapted their approach because the direct route was unavailable. In our research at Airlock Digital, we have seen similar behavior — agents we have tested will exhaust every avenue to achieve their objective and often the pathway they take can be unexpected.
This behavior is not limited to security testing. An agent attempting to complete an administrative, development or operational task may similarly generate new code, change tools or find an alternative path when it encounters a restriction. That means security cannot depend entirely on the agent interpreting instructions as intended.
The first question organizations should ask is what the agent can execute on the endpoint.
Agents may generate scripts, binaries and other artifacts that have never previously existed and therefore have no established reputation. They may also use trusted interpreters, administrative tools and other legitimate applications in ways their operators did not anticipate.
Detection tools remain important, but they are often evaluating activity after execution has begun. A preventative application control model establishes a more reliable boundary by allowing trusted applications, code, and tools to run while preventing unapproved execution by default.
This reduces the number of pathways available to an agent regardless of how persistent, adaptive, or capable the underlying model becomes. The control does not need to predict why the agent generated a particular binary or selected a particular tool; it determines whether that execution is permitted.
The ACSC guidance supports this approach by recommending approved tool allowlists, secure defaults, hard constraints and containment mechanisms that limit the impact of unexpected behavior.
Application control addresses an important part of the problem, but an approved agent may still use legitimate tools to perform an inappropriate action.
For example, an agent may be authorized to use PowerShell as part of an IT workflow. That does not mean every PowerShell command it produces should be allowed. Similarly, an approved coding agent may require access to a project directory without needing access to credential stores, security logs or unrelated repositories.
This creates a second control requirement: governing agent behavior at runtime.
Organizations need to define operating boundaries around the commands an agent can issue, the files it can access, the resources it can interact with, and the actions that require human approval. These decisions need to be evaluated as the agent acts, not only when the application is initially approved. Agents operate at much faster speed and scale than any human actor. By the time a human reviews agent actions the damage is already done, as demonstrated in the Open AI/Hugging Face incident. Governing what an agent can do at runtime expands on the prevention-first security model and explicitly controls agent behavior.
In line with this concept, the ACSC recommends centralized policy decisions for autonomous actions, explicit control flows, constraints agents cannot override, and human approval for consequential or difficult-to-reverse activities.
Agentic AI governance must extend beyond inventory and high-level platform settings. Security teams require visibility into actual sessions, commands, files and policy decisions, together with independent enforcement where those actions occur: on the endpoint.
A practical security model for Agentic AI therefore needs two connected control planes:
Neither control is sufficient in isolation. Blocking unapproved AI applications does not govern the behavior of agents the organization has chosen to trust. Monitoring agent behavior does not prevent those agents from generating or invoking unapproved code. However, when used together, these controls constrain both the available execution paths and the agent’s behavior within approved workflows.
Agentic AI can deliver meaningful productivity and operational benefits, but the security model needs to keep pace with its increasing ability to act. Governance should not end at the AI platform, and preventative endpoint security should not end once an application has been approved.
As agents gain greater autonomy, security must move from solely observing their actions after the fact to constraining what they can execute before impact occurs. For Agentic AI, prevention is not simply another layer of defense; it is the critical foundation of effective governance.