Sandboxing, network permissions, and secrets for coding agents
Sandboxing, network permissions, and secrets for coding agents
Section titled “Sandboxing, network permissions, and secrets for coding agents”Coding-agent risk rarely starts with the model. It starts with execution scope. Once an agent can read broad directories, install packages, call the network, or access credentials, the question is no longer “can it write code?” It becomes “what system boundary is this agent now part of?”
Quick answer
Section titled “Quick answer”Most engineering teams should start with this default:
- narrow repository or workspace access;
- read permissions broader than write permissions;
- network access off unless the task truly needs it;
- secrets unavailable by default;
- any escalation to broader access tied to an explicit approval step.
That starting point is usually much safer than giving the agent a developer-shaped environment on day one.
The boundary model that actually matters
Section titled “The boundary model that actually matters”There are three separate control planes:
| Control plane | Core question |
|---|---|
| Filesystem | What code and artifacts can the agent see or change? |
| Network | Can the agent fetch dependencies, call APIs, or reach internal systems? |
| Secrets | Can the agent use credentials or tokens to act on behalf of people or systems? |
Teams often discuss these as if they are one permission set. They are not. Each should be reviewed separately.
A safe default rollout
Section titled “A safe default rollout”The safest practical rollout usually looks like this:
- Read-only local analysis
- Restricted write access inside a named workspace
- Task-specific network access with logging
- Short-lived or scoped credentials only after explicit approval
When network access is actually justified
Section titled “When network access is actually justified”Network access should be treated as a business capability, not a default convenience. It is justified when the task truly requires package install or dependency retrieval, API contract checks against a live service, current reference docs, or interaction with remote systems that are already part of the engineering workflow.
It is not justified just because the agent “might need to look something up.”
Secrets should never be the default path
Section titled “Secrets should never be the default path”Secrets become dangerous because they collapse identity, authority, and intent into one hidden step. The safer pattern is no secrets by default, scoped credentials only for the smallest needed action, clear logging of when credentialed actions happen, and user or service identity chosen explicitly, not implicitly.
If a coding agent can silently use broad credentials, approval systems lose most of their value.
What strong governance looks like
Section titled “What strong governance looks like”Strong governance does not mean freezing the agent. It means making these boundaries observable:
- what scope was granted;
- what scope was actually used;
- what step triggered escalation;
- and what human approved the higher-risk path.
If the system cannot answer those questions later, it is too permissive for serious engineering use.