Least privilege and sandboxing

Every lesson so far has pushed toward one stance: assume the agent will be compromised, and make that assumption survivable. Least privilege is that stance as an engineering rule. The agent gets the minimum tools, the minimum data, the minimum authority its task requires — so that a successful attack reaches a small blast radius rather than everything.

• Tools: give the agent only the tools its task needs. A support agent that never issues refunds should not have the refund tool available to be tricked into calling.
• Credentials: scope them — one tenant, read-only where possible, short-lived. A read credential cannot be steered into a write.
• Egress: allowlist where the agent may send. This one control defangs most exfiltration regardless of how the attack got in.
• Sandboxing: run risky capabilities — code execution, browsing — in a contained environment with no access to secrets or production systems, so a compromise there touches nothing that matters.

The framing that makes this stick is the blast radius. Security debates often get stuck on likelihood — will the agent be fooled? — which is unanswerable and model-dependent. Least privilege sidesteps it by working on impact instead: grant so little that being fooled does not matter much. A compromised agent with a broad credential is an incident; the same compromise with a scoped, read-only, allowlisted credential is a log line.

The lab reuses the attack battery, but read it for blast radius this time. Under structural defence the credential is scoped and the egress is allowlisted, so even the attacks that get the model to cooperate reach nothing worth having. Least privilege did not make the agent harder to fool — it made being fooled cheap.