A coding agent's ordinary job requires capabilities that look dangerous in isolation: reading source, editing files, launching commands, and installing dependencies. Blocking every command makes the tool ineffective. Giving it the developer's entire workstation and production credentials makes a prompt-injection mistake far too expensive.
The useful design question is the size of the environment in which the agent can act freely. A disposable checkout with scoped network access and no production secrets supports meaningful autonomy. A privileged host with cloud administrator credentials turns the same shell command into a different risk.
Draw the execution boundary first
Place each task in an isolated workspace with a defined filesystem, process, and network boundary. Decide which directories are writable, which services are reachable, and which credentials exist in the environment. A separate worktree organizes edits; it is not an operating-system security boundary by itself.
Anthropic describes filesystem and network restrictions as complementary parts of coding-agent sandboxing [1]. That is a useful architectural distinction: restricting writes while allowing unrestricted outbound traffic can still permit disclosure of files the process may read. Restricting network access while exposing powerful local credentials still leaves significant authority available.
Test the chosen isolation technology against the actual development workflow. Dependency installation, browser tests, Docker access, and local database sockets can open paths outside the intended boundary. A container with a privileged host socket should not be treated as equivalent to a tightly restricted container.
Keep repository content below policy
Repository instructions, comments, issues, test fixtures, and dependency output can influence a coding agent. Some of that content is controlled by contributors or external packages. Treat it as task input, not as authority to disable safeguards, expand network access, or read credentials outside the project.
Preserve the origin of instructions in review and telemetry. A request that began in a trusted user task should remain distinguishable from a command suggested by an issue comment. An agent-generated explanation that a security exception is necessary is a claim to evaluate, not a permission grant.
Protect the configuration that controls the agent. If the workload can edit its own hook, sandbox policy, or managed settings, the enforcement assumption may fail. Prefer centrally managed controls where the host supports them. Verify actual activation and trust state; the presence of a configuration file alone does not prove a hook runs.
Separate development actions from release actions
Allow ordinary edits and tests within the approved environment. Put protected branch updates, production deployments, secret changes, package publication, and infrastructure administration behind distinct authority. The same tool name can perform both routine and consequential work, so inspect arguments and targets.
A git push to a personal feature branch differs from a forced update to the production branch. A test command that executes a project script may inherit arbitrary behavior from that script. A migration targeting an ephemeral database differs from a migration targeting the live account. Resolve these differences from the execution context and the actual destination.
Branch protection and deployment approvals remain valuable because they operate downstream of the model. Ensure the agent's credential cannot bypass the protections intended to constrain it. A release rule is ineffective when the same workload can edit the workflow, approve the environment, and publish with an administrator token.
| Boundary | Primary control | Failure to test |
|---|---|---|
| Local execution | Sandbox and minimal host access | Privileged socket or parent directory escape |
| Tool authority | Managed permission hooks | Disabled hook or nested ungoverned agent |
| Secrets | Scoped injection outside model context | Environment dump or log disclosure |
| Release | Protected CI and provider permissions | Bypass token or editable approval workflow |
Treat CI as another agent environment
Untrusted pull requests can affect scripts that CI executes. An agent that opens a pull request may not directly possess a release credential, yet a careless workflow can introduce that credential when it runs the change. Review trigger behavior, checkout strategy, permissions, and secret availability for each workflow.
Use minimal job permissions and isolate privileged release stages from untrusted builds. Keep third-party actions and dependency sources under a versioning and review policy. A reproducible build is useful, but it does not establish that the source or build script is authorized to access production credentials.
Record the artifact that was reviewed and the artifact that was deployed. If the agent can modify the artifact after approval, the release boundary has a check-to-use gap. Bind approvals to immutable revisions or digests and verify that binding in the publishing step.
Keep approval requests intelligible
When an agent needs additional authority, show the exact command, target, reason, and expected effect. Do not collapse a multi-command script into a harmless-looking label. A reviewer should understand whether the request adds a network destination, reads a sensitive path, or changes a protected resource.
Scope remembered approvals narrowly. Permission to run the test suite should not cover every future shell command merely because the agent invokes the same interpreter. Where static command analysis cannot determine the effect, rely on the environment boundary and resource permissions as additional controls.
Retries deserve attention. A deployment timeout does not prove that deployment failed. Require reconciliation before repeating an operation with external effects. A coding agent should not decide on its own that repeating a publish or migration is safe because it did not receive a success message.
Verify useful autonomy and resistance together
Build a small evaluation set from real engineering tasks. Include successful edits, tests, dependency changes, and feature-branch pushes. Pair them with attempts to access production credentials, alter managed controls, introduce a new external destination, and invoke a nested agent outside the governed path.
Check downstream effects. Verify that the protected branch stayed unchanged, the provider rejected the forbidden credential use, and the network destination was unreachable. A refusal in the transcript is weaker evidence than an enforced boundary at the resource.
Expand the agent's scope only when the team understands which layer constrains each new capability. The aim is a productive development environment with explicit exits into higher authority. That structure lets the agent work quickly while keeping the release decision and production blast radius under deliberate control.