Give a coding agent the permissions its task needs

A coding agent can be useful with broad freedom inside a disposable development workspace and very little authority elsewhere. The permissions policy should make that boundary understandable before work begins. It should also specify what happens when the task requires crossing it.

Claude Code’s documentation distinguishes tool permissions from instructions given to the model. Its sandbox documentation separately describes operating-system restrictions around shell commands and notes that other tools and processes can have different boundaries. That is a useful distinction for any agent deployment: a written instruction and an enforced access limit are different controls.

Define the workspace and the destination

Start with two lists: resources needed to produce the work, and destinations the work may affect. For a website change, the first list might include a repository, test fixtures, and a local preview. The second might include a staging server or a production host. A user request to edit a page does not automatically establish every destination as authorized.

Keep routine development credentials separate from production credentials. The goal is to make the ordinary path convenient while avoiding accidental access to systems unrelated to the task. A dedicated staging account is easier to reason about than a personal account with years of accumulated privileges.

Classify effects, not just command names

Our suggested policy has three categories. Work inside the agreed development boundary may proceed routinely. Actions that create external effects require the authorization defined for that workflow. Actions outside the task’s scope remain unavailable until the scope changes.

The categories should describe effects. Reading a local source file differs from uploading it to an external service. Building a site differs from publishing it. Editing a test database differs from deleting customer records. The same general-purpose tool might perform any of these operations, so the tool’s name alone is a weak policy description.

Write examples your team actually encounters. A useful entry names the resource, the effect, and the approval condition. For instance, a preview deployment may be allowed only to a designated staging project, while a public release requires review of the exact revision being published.

Make an approval concrete

An approval request should let the reviewer understand what will happen without reconstructing the entire conversation. Include the target, the proposed change, the data leaving the workspace if any, and the practical consequence. When applicable, identify how the action can be reversed.

Bind authorization to a meaningful scope. Approval to publish one reviewed revision should not silently apply to every later revision. Approval to contact one service should not become permission to send the same data to an unrelated endpoint.

OpenAI’s agent safety guidance discusses the risk of untrusted material influencing tool calls. A retrieved document, repository comment, or web page should therefore be treated as task data, not as a new authority to widen access.

Design the denied path

When a legitimate operation is denied, the agent should retain its completed work and explain the missing authority. It can often produce a patch, draft, or deployment artifact that a person can review. The system should not silently weaken a control to make the task appear finished.

Test this path deliberately in a nonproduction environment. Deny access to the intended staging destination and observe the result. A useful outcome is a clear failure state with the prepared work preserved. Repeatedly trying different destinations would not satisfy the original task.

Review the policy when the workflow changes

A new plugin, remote tool, or background process can change the access picture. Add it to the resource inventory and check which boundary actually applies. Do not assume a shell sandbox automatically covers every integration used by the agent.

Keep the policy short enough to use and specific enough to test. The aim is to remove routine uncertainty while preserving clear decisions at consequential boundaries. A successful setup gives the agent room to complete its work and gives the operator an accurate account of what that work can affect.