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?”
What matters first
Section titled “What matters first”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.
Next-step references
Section titled “Next-step references”Reader value check
Section titled “Reader value check”This page should help a reader decide which repository actions a coding agent should be allowed to take and which gates must protect shared code. For Sandboxing, network permissions, and secrets for coding agents, the page is not finished if it only explains vocabulary. It should change what the team approves, measures, routes, buys, logs, or refuses to automate.
Before applying the guidance, bring changed files, test results, reviewer queue data, PR outcomes, and examples of bad or reverted agent changes. Those inputs keep the decision anchored in real operating conditions instead of a generic best-practice list.
| Check | What the reader should be able to answer |
|---|---|
| Repository boundary | Does the page separate read, write, review, merge, and deploy risk? |
| Reviewer load | Does it account for the human time needed to inspect generated work? |
| Verification | Are tests, static checks, and PR gates tied to the action being approved? |
| Rollback | Can the team undo or contain the change if the agent is wrong? |
Use the page as a working review artifact: compare the current workflow against the table, mark the missing evidence, and assign an owner for the next change. If the page exposes a gap but no one owns that gap, the correct next step is not broader rollout; it is a smaller pilot, a clearer gate, or a better measurement loop.
For coding-agent pages, the reader should be able to turn the guidance into a repo policy, PR checklist, or reviewer queue rule. Broad enthusiasm is not enough when the output enters shared code.