AISI Security Incident Analysis: Agentic AI Sandbox Escapes and Zero Trust Controls

Context

The UK AI Security Institute (AISI) reported a security incident during a cyber evaluation it performed using frontier models such as Mythos 5 and GPT-5.6 Sol (without cyber classifiers).

The incident highlights the risk of unguarded execution of AI agents, especially when used in the context of cyber evaluation.

Responsible and Secure AI Agent Deployment

This is a wake-up call for security organizations/vendors to ensure their AI-assisted red-teaming and pen testing agents are executed securely and in a tightly sandboxed environment.

An AI agent that can autonomously discover and exploit vulnerabilities is, functionally, an autonomous attacker; treat it like one. If it runs with broad network access, real credentials, or write access to production, a single hallucinated action, prompt injection, or scope misread can turn a sanctioned pen test into an actual breach or outage. The fix isn’t “trust the model more”; it’s architectural: isolated/ephemeral execution environments, approval gates before any state-changing action, full action logging for audit, and kill-switches that can halt the agent mid-run. Sandboxing isn’t a nice-to-have for AI red-teaming tooling; it’s the control that determines whether the exercise stays a controlled test or becomes the incident it was meant to prevent.

AISI’s Forward-Looking Response Analysis

As part of AISI’s forward-looking response, the following actions stood out:

• Use of synchronous LLM-based monitoring of agent actions. In practice, this converts into a prompt firewall with LLM-as-a-judge to understand agents’ intent.
• Harden agents’ evaluation sandboxes.
• Use of fine-grained network controls. Fine-grained network and domain access controls are critically important.

▌ Recommended Architecture for Agents Performing Red Team or Pentesting Tasks

Mapping of Security Events to Possible Security Controls

• Isolation of that kind answers the question “whose resources are these?”, not “what is this workload permitted to do?” With agentic workloads the gap becomes untenable, because the agent rarely needs to escape the boundary to cause harm. It causes harm through the channels it was legitimately granted inside the boundary: outbound network calls to an attacker-chosen destination, credentials read from a mounted secret, a tool or API invocation chained from a poisoned instruction, a file written to a shared volume. Every one of these actions leaves the container boundary perfectly intact. A meaningful sandbox therefore has to operate at the level of the action itself: a policy-enforced, least-privilege envelope over syscalls, file paths, process execution, network destinations, and tool/model invocations, derived from what the workload is supposed to do rather than from what the runtime happens to allow by default.
• Critically, this enforcement must be pre-emptive; the control must deny the action inline, at the point of attempt, before the syscall completes or the request leaves the pod, rather than reconstructing what happened from logs after the fact. Detection tells you the sandbox failed; a sandbox is what makes the failure impossible in the first place.
• Under that definition, the container is where the agent runs, and the sandbox is the set of inline mitigation controls wrapped around it.

How AccuKnox Helps

Secure the models and agents you already run

AI-SPM builds a live, agentless inventory of every model, agent, dataset, and pipeline across cloud and on-prem, including the shadow AI nobody registered. Around each running workload it puts the inline controls this incident calls for: network and domain allowlists, process and file policy, and a stateful prompt firewall with an independent judge in the request path. Every event in the table above maps to a control you can turn on without rebuilding the agent.

Build the agent inside the sandbox from day one

AgentZ is a zero trust platform for building, running, and governing production agents, where default deny is the starting posture rather than a hardening step. Policy resolves at the edge and gets checked at the kernel, and every skill, tool call, and workflow step lands in a replayable audit trace. It runs on-prem or air-gapped, so the sandbox is the runtime itself instead of a wrapper bolted on after the first incident.

FAQs