PERMISSIONS AND ACCESS CONTROL

EXAMPLES Example 1: Least privilege worked through A team builds a documentation-writing agent whose job is to read source code and produce explanations. At first, for convenience, a developer gives it full file access, a shell, and network access. A review applies least privilege by asking what the job really requires. Reading code is needed. Writing is needed only into a single documentation output folder. A shell is not needed, since the agent can read files directly. Network access is not needed. So the final permissions are read-only on the code folder, write on the output folder, and nothing else. If someone tricks the agent through a hostile comment inside a source file, the worst it can do is write odd text into the documentation folder. That is a tiny blast radius. Example 2: An allow-list A research assistant agent is configured with an allow-list of three tools: search_web, read_file, and draft_email. Midway through a task, the model requests a tool called delete_file, perhaps because a hidden instruction suggested it. The resolver finds no match on the allow-list and refuses, regardless of how the request was phrased. Notice that the name draft_email, rather than send_email, was chosen on purpose: the agent can prepare an email for a human to look over but cannot send it. Example 3: Human approval for high-risk actions A cleanup agent is allowed to remove temporary files. The harness has a rule that deleting more than ten files at once requires human confirmation. One day the agent decides to delete 480 files, sounding highly confident that they are all temporary. The harness pauses and shows the reviewer the list. The reviewer notices that twelve of the files are actually customer exports, denies the request, and the agent is told to delete only the ones that match a safer pattern. The confidence of the agent had no influence on the rule. Example 4: Secret handling An agent needs to call a weather service that requires an API key. In the unsafe design, the key sits in the system prompt so that the model can include it in calls. A prompt injection then asks the model to print its instructions, and the key leaks. In the safe design, the agent only emits a request such as "get_weather for Paris." The harness receives it, adds the key to the outgoing network request itself, and sends it. The key never appears in the model's context, in the trace, or in any log. Even a successful injection has nothing to steal.