Building block 1: least privilege
The single most effective protection is mundane: a tool or agent should never have more rights than its specific task requires. An agent that can only read can, at worst, output wrong information through a successful injection or a poisoned tool – but it can't delete a file, transfer money, or leak credentials it never had. This rule sounds obvious, but it's regularly violated in practice, because it's more convenient to give an agent broad rights from the start rather than expanding them gradually as needed.
Building block 2: real, not claimed, isolation
In July 2026, security researchers found a flaw in the local sandbox of a widely-used AI coding tool: an agent could escape its supposedly isolated Linux environment and access the entire host machine's filesystem – including SSH keys and cloud credentials, without a user noticing anything. The attack used a chain of several design decisions: the entire host filesystem was reachable through a network filesystem mount inside the VM, combined with an exploitable kernel privilege-escalation flaw. The vendor initially classified the report as purely informational – not an official vulnerability – and ultimately resolved the risk not through a targeted patch, but by quietly switching the default execution to a cloud environment where the local escape path simply no longer existed.
The lesson: isolation is a technical property, not a marketing claim
The decisive point isn't which specific tool was affected, but the pattern behind it: a sandbox marketed as isolated is only as isolated as its actual technical implementation allows. Anyone relying solely on a vendor's assurance instead of checking their own architecture – what data is actually reachable for an agent, regardless of its intent – transfers that risk unchecked into their own operations.
Practice section: building block 3 – approval gates for irreversible actions
The third pillar adds a behavioural rule on top of privilege minimisation and isolation: actions that can't be undone – a payment, a deletion, a message sent to a customer, wiping data – get a real approval gate that requires a deliberate human confirmation before the action actually executes. Reversible actions (reading something, drafting a document) don't need that brake – it would only create friction without offering real protection. The art lies in drawing that line cleanly into an agent's architecture from the start, not as an afterthought once the agent is already running in production.