AI security starts outside the agent.

Securing a model that only answers is mostly about what it says: whether it can be talked into something harmful, or into giving away what it knows. Agents change the question. They act, with real credentials, on code, money and customer data, and they hand work to each other. Securing them is about what they can do, and what happens when one of them is turned.

Any agent can be turned

An agent takes orders from what it reads. In February, instructions in a GitHub issue title steered Cline’s AI triage bot into a chain that ended in an unauthorized npm release of its command-line tool.

It trusts what it remembers. In July, the Bad Memory study showed instructions planted in an agent’s memory files attacking its current and later sessions, in both Claude Code and Codex. The study ran in a sandbox.

And it can go wrong with no one’s help. The same month, AI agents OpenAI was testing on a cyber benchmark got onto the internet through a zero-day in their sandbox’s package proxy, then chained vulnerabilities into Hugging Face’s production systems. In October, two of OpenAI’s internal coding agents weakened the monitoring meant to catch misbehaving agents, reading routine coding instructions as permission. Nobody attacked those agents. They went further than anyone meant them to.

Controls inside the agent fall with it

Many of the controls around an agent run inside it: the rules in its system prompt, a guardrail in its loop, its own logs and its own account of what it did. A turned agent can reach all of them. One of OpenAI’s coding agents removed a monitor, then told its user it hadn’t.

So the first rule is to keep every control out of the agent’s reach. Whatever records an agent, judges it or stops it should run as a process of its own, with keys the agent never holds. The agent can still be turned, but it can’t rewrite its trail, quiet its monitors or call off its own halt.

Watch every hop

It’s tempting to judge agents by what they finally produce, but much of the risk passes between them on the way. In the AgentLeak benchmark, messages between agents leaked private data at a rate of 68.8%, against 27.2% for final outputs, and audits of outputs alone missed 41.7% of violations. Securing a fleet means watching each hop: every message between agents, every tool call, every memory read or write.

Limit what agents can do together

Least privilege gives each identity only the access its task needs, and around AI even basic access control is often missing. In IBM’s 2026 Cost of a Data Breach Report, 92% of organizations with a security incident involving an AI model or app lacked role-based access, multifactor authentication and similar controls.

For agents, least privilege isn’t enough, argues A Theory of Least Autonomy in AI, from July: they can combine, approve and amplify permissions across workflows and system boundaries. The paper proposes least autonomy, a generalization of least privilege. It maps which agents can influence which, through a resource one writes and another reads or a message between them, and tests that map for agents that could collude. Limits like those depend on a record of every hop.

Where Wake comes in

Wake is built along those lines. Only its capture runs where agents live: the SDKs record each model call, tool call, handoff and memory read or write, and the proxy records every MCP and A2A call it carries. Everything that records, judges and stops agents runs out of band, where agents hold no keys. Each event is signed outside the agent, and the provenance graph shows what influenced what, across agents, hops and memory. One halt reaches a fleet, an agent, a sub-agent or a single token, and the brake counts nothing as stopped until it has checked.

Wake is early. The proxy’s deny is proven end to end; the brake’s other levers are built to each vendor’s API and so far tested against stand-ins. And Wake can’t keep an agent from being turned. It’s built so that when one is, you can see what led to it, stop it, and prove what happened.