Why prompt-level guardrails are not enough, and how a two-plane architecture, least-privilege tools, and audit trails make agents safe to give real permissions.
An AI agent that can only talk is low-risk. An agent that can call tools — read files, send messages, move money — is a different thing entirely. The moment an agent takes actions in the real world, "just prompt it not to" stops being a security model.
The core problem is that the model reads untrusted input (web pages, user content, tool results) in the same context where it decides what to do next. A well-crafted piece of that untrusted input can redirect the agent. So the design question is not "how do we phrase the instructions" but "what can this agent actually do, and to what."
Two planes, not one
The approach we favor separates a trusted control plane — which holds permissions and makes the real decisions — from the untrusted plane where model output and external content live. Untrusted content can inform, but it cannot silently escalate what the agent is allowed to do. That separation is the spine of how we do AI agent architecture and safety work.
Least privilege and audit
Every tool an agent can call should be scoped to the minimum it needs, with explicit boundaries, and every action should be logged so behavior can be reviewed after the fact. Guardrails at runtime contain the blast radius when something does go wrong — and at real scale, something eventually will.
Designed this way, an agent becomes something you can hand real permissions to, because the damage a bad instruction can do is bounded by architecture, not by hope.