Security model
Three controls, and they are not interchangeable. Knowing which one is doing the work is what lets you loosen one safely.
| Control | What it is | Lesson |
|---|---|---|
| The sandbox | Enforced by the operating system. What is possible at all | 3 and 4 |
| The approval policy | When the agent must stop and ask before crossing the boundary | 5 |
| Rules | Named exceptions, with the most restrictive decision winning | 7 |
By default the agent runs with network access turned off, and locally the sandbox limits what it can touch, typically to the current workspace. Everything else is a decision to widen that on purpose.
The recommendation, by folder
- A version-controlled folder you own: workspace write, approvals on request. The docs call this Auto.
- Unfamiliar code: read-only, approvals on request.
- Anything unattended: both settings written down explicitly, because nobody is there to answer a prompt.
Prompt injection, in one paragraph
An agent that reads a file, a page or a ticket can read instructions written to be found. The documentation is direct about it: prompt injection can cause the agent to fetch and follow untrusted instructions. The defence is not cleverness, it is the boundary. An agent with no network cannot send anything; an agent that cannot write outside the workspace cannot touch your keys.
That is why lesson 4 spent so long running the sandbox. The profile you choose is the thing standing between a sentence in a README and a command on your machine.
Web search without the network
There is a middle setting worth knowing: the web search tool can be controlled separately, so an agent can look something up without being granted full network access for every command it spawns.
codex sandbox first. Nine times out of ten it needs one directory or one host, not everything.- Set your default to read-only for a day and notice what actually breaks.
- Take one repository and write down which of the three controls you are relying on.
Little by little, you're building something great.