Allowlisted Tools and Approval

Give capabilities, not a raw shell

The single most important safety decision in agent design is what the model is actually allowed to do, and the safest answer is almost always narrower than it first seems necessary. An allowlist is an explicit, closed list naming exactly which actions are permitted - nothing outside that list is even possible for the agent to attempt, regardless of what the model proposes. Give the model narrow, purpose-built functions like read_file(path) or search_logs(pattern), each of which independently validates its own arguments (rejecting a path that tries to escape outside the intended workspace directory, for instance) rather than one broad, general-purpose shell(command) tool that can run literally anything. Just as important is clearly separating read-only actions, which only observe state, from mutations - actions that actually change data or systems in some way and therefore carry real consequences if something goes wrong.

For any mutation with real consequences - deleting something, deploying a change, rotating or changing a credential, making a network call to an external system, or executing a command the agent itself generated - require an explicit human approval step before it happens. That approval prompt should clearly display the exact proposed action and its target, not a vague paraphrase, so the human reviewing it actually knows what they're agreeing to.

Warning: Prompt injection - covered as a full module in the security phase later in this track - can arrive through any content the agent reads during its loop: a log file, a README, a support ticket, or a retrieved document, not just direct user input. A tool-permission policy enforced correctly in code holds firm even in the worst case, where the model itself has been successfully persuaded by injected text to ignore its own instructions - because the enforcement doesn't depend on the model behaving correctly in the first place.