Give coding agents a workbench, not a workstation

A coding agent should not begin life on a developer’s workstation.

It should begin in a workbench:

Boundary	Workbench default	Workstation failure mode
Filesystem	One repository checkout, scoped writable paths	Home directory, adjacent repos, personal files
Network	Off or allowlisted until the task needs otherwise	Public internet and internal services by habit
Secrets	No ambient credentials; inject only task-bound ones	Shell inherits cloud, package, Git, and SaaS tokens
Commands	Routine commands run inside policy; escapes require approval	Every shell action has the operator’s full authority
Durable output	Branch, patch, pull request, evidence log	Local edits, hidden generated files, unclear provenance

That table is the infrastructure decision. The model choice matters, but it is downstream of the question that decides whether a coding agent is governable: where can it run code, what can that code touch, and what evidence does it leave behind?

Coding agents are different from autocomplete. They can read a codebase, edit files, run tests, install packages, inspect failures, and sometimes open pull requests. OpenAI’s Codex web documentation describes cloud tasks running in their own environment and producing repository work such as pull requests Codex web. Its sandbox documentation is more direct about the local trust boundary: spawned commands inherit sandbox limits, and sandboxing and approvals are separate controls that work together Codex sandbox.

That distinction is worth keeping. A sandbox is not a prompt. It is the boundary around command execution. An approval policy is the rule for crossing that boundary. Teams that blur the two end up asking a language model to politely avoid the same mistakes that infrastructure should prevent.

The first design object is the execution boundary

Treat the coding agent environment as a small production system, even when it is used for draft work.

The environment should answer five questions before the agent touches a real repository:

1. Which files can it read and write?
2. Which commands can run without asking?
3. Which networks can those commands reach?
4. Which secrets are present, if any?
5. Where does the reviewable output land?

This is for teams that are moving coding agents from individual experiments into shared engineering work: bug fixes, dependency updates, tests, migrations, documentation, refactors, release preparation, or issue-to-PR workflows. It is especially relevant when the agent can run package managers, build tools, browsers, database clients, cloud CLIs, or repository automation.

It is too much process for a disposable toy repo with no secrets and no connection to company systems. It is not enough for production incident response, regulated software, safety-critical systems, or high-impact security automation. Those workflows need stricter identity, approval, audit, change-management, and rollback controls than a general article can prescribe.

The practical goal is smaller: do not let the first successful demo become the default security model.

A branch is safer than a session transcript

The first durable output should be a branch or pull request, not a chat transcript.

A transcript can explain intent. A diff shows what changed. A branch lets normal engineering controls do their job: code review, tests, static analysis, dependency review, security scanning, ownership rules, and CI history. It also gives reviewers a place to reject the work without negotiating with the agent.

NIST’s Secure Software Development Framework is not about coding agents, but its vocabulary still fits. SSDF frames secure development as a set of practices that reduce vulnerabilities, mitigate impact, and address root causes across the software lifecycle NIST SP 800-218. A coding agent should enter that lifecycle through the same gates as a human change. It should not become a parallel development path because it produced the patch faster.

For most teams, the right first workflow is:

• clone or mount only the target repository
• run the project setup needed for that repo
• make changes on a dedicated branch
• run local checks inside the workbench
• open a pull request with task context, tests run, and known limits
• let CI and human review decide what happens next

That workflow is not glamorous. It is useful because it gives the agent a narrow path from request to reviewable artifact.

Avoid designs where the agent edits a shared checkout, pushes directly to protected branches, writes into a developer’s home directory, or stores generated artifacts in untracked local paths. Those designs make speed look high while moving review later, where it is harder to see what happened.

Network access should be earned by the task

Package installation is the moment many agent environments quietly become too broad.

The task starts as “fix this failing test.” The agent runs a package manager, the package manager reaches the public registry, install scripts execute, postinstall hooks run, caches fill, and a toolchain with its own trust chain now participates in the task. That may be acceptable. It should not be invisible.

NIST’s container security guidance describes containers as portable, reusable, automatable packaging and execution environments, while also emphasizing that containerized systems introduce security concerns that must be addressed NIST SP 800-190. A coding-agent workbench has similar appeal and similar traps. It makes execution repeatable, but it can still have vulnerable base images, stale packages, broad network egress, mounted secrets, unsafe build scripts, and weak isolation from the host.

Start with a network posture, not a shrug:

Task type	Reasonable network default
Read code, edit docs, inspect tests	No public or internal network
Run existing test suite	No network unless the test contract requires it
Install dependencies	Registry allowlist, lockfile preference, cache logs
Research a library or API	Browser or fetch access with source capture
Call internal services	Separate approval and task-bound credentials

The point is not to ban network access. The point is to make it intentional. If the agent needs the internet to fetch documentation, say so. If it needs a package registry, log that. If it needs an internal staging API, the task has crossed into a different risk class.

Do not solve this with a line in the prompt that says “be careful with the network.” Put the rule in the environment, proxy, registry policy, or approval flow.

Secrets do not belong in the ambient shell

The easiest way to over-authorize a coding agent is to run it where a human already works.

A developer workstation often has Git credentials, cloud tokens, package registry access, database connection strings, SSH keys, password-manager helpers, browser cookies, and internal CLI state. Some of those credentials are invisible until a command discovers them. An agent that can run shell commands in that environment may inherit more authority than anyone intended to delegate.

The safer default is no ambient secrets. Inject a credential only when the task requires it, scope it to the task, and prefer credentials that cannot mutate production. If the agent only needs to read a private repository, do not hand it cloud deploy access. If it only needs to open a pull request, do not give it package publishing rights. If it needs a staging database, use a constrained test identity and record the dataset class.

This is where the workbench model pays off. A purpose-built environment can make the absence of secrets normal. The workstation model makes secret sprawl normal and asks the operator to notice every exception.

OWASP’s agentic AI threat guidance frames agent systems as autonomous systems with expanded capabilities and associated risks OWASP Agentic AI. The OWASP Top 10 for Agentic Applications also gives builders and defenders a risk starting point for agents that plan and act across workflows OWASP Top 10 for Agentic Applications. In coding workflows, credentials are where those abstract capabilities become concrete authority.

One test is simple: if the agent went wrong, what could it reach before a human noticed? If the answer includes production credentials, customer data, cloud admin roles, deployment commands, or package publishing, the workbench is too permissive for routine coding work.

Approval belongs at boundary crossings

Approval fatigue is real. Asking for confirmation before every harmless command teaches people to approve mechanically.

The answer is not to remove approval. It is to put approval where the boundary changes:

• reading outside the target repository
• writing outside approved paths
• enabling network access
• installing or updating dependencies
• executing generated scripts
• using secrets or delegated credentials
• calling internal services
• pushing a branch
• opening, updating, or merging a pull request
• deleting data, caches, branches, or artifacts

Routine commands inside the approved boundary can run without interruption. A test runner, formatter, type checker, local build, or repository search does not need the same approval posture as a command that reaches the internet or changes a remote system.

This is the same separation OpenAI’s Codex sandbox documentation makes: the sandbox defines technical limits, while the approval policy decides when the agent must stop and ask before crossing them Codex sandbox. The more teams encode that split in their own platform, the less they need to rely on operator vigilance.

The approval UI should show the command, target, reason, and expected effect. “Run command” is not enough. “Install dependencies from npm using the existing lockfile” is better. “Use staging token to query account 1842” is a different class and should be treated that way.

Sometimes the right answer is a narrower tool

Not every software task needs a shell-capable agent.

For deterministic updates, a script or codemod may be safer. For dependency updates, a dependency bot plus human review may be more predictable. For documentation cleanup, a read-only assistant that proposes patches may be enough. For production migrations, a conventional change process should own execution, with the agent limited to drafting the plan or tests.

Coding agents are strongest where the work is messy enough to need inspection and iteration but bounded enough that a reviewer can understand the diff. They are weaker when the task requires broad operational authority, undocumented local context, fragile credentials, or live production judgment.

The cost side is real. A good workbench needs environment images, dependency caches, repository setup, network policy, log retention, approval UX, CI integration, and incident handling. A weak workbench is cheap until it quietly becomes an unmanaged workstation in the cloud.

Use the agent when the reviewable artifact is worth that infrastructure. Avoid it when a small script, queue worker, form, or existing CI job would do the job with less authority and less ambiguity.

The review should inspect the boundary, not just the diff

A pull request tells reviewers what changed. It does not always tell them how the change was produced.

For agent-authored work, add enough evidence for a reviewer to inspect the boundary:

Evidence	What it answers
Environment name	Which workbench image or runtime produced the change
Repository scope	Which checkout and writable paths were available
Network mode	Whether internet or internal egress was enabled
Secrets used	Whether task-bound credentials were injected
Commands run	Setup, tests, formatters, generated scripts
Approvals granted	Boundary crossings a human approved
CI result	Independent checks after the agent’s local run
Known limits	What the agent could not verify

This does not need to become a compliance novella. A concise PR section can carry enough evidence for normal engineering review. For sensitive repositories, store richer logs in the platform and link to the reviewed record.

The important habit is to review the environment as part of the change. If an agent needed public network access, say why. If it installed new dependencies, show the lockfile diff and registry source. If it used a secret, explain the scope. If it skipped tests, make that visible before merge.

The default posture

Start with this posture for shared coding-agent work:

one repo, one branch, no ambient secrets, network off by default, explicit approval for boundary crossings, local checks inside the workbench, CI outside the workbench, pull request as the durable output.

Relax those defaults only when the workflow earns it. A dependency-maintenance agent may need registry access. A browser-test agent may need a local dev server. A release-prep agent may need read access to issue and pull-request metadata. Each exception should be attached to a workflow, not granted to every agent session because it was convenient once.

Review the boundary again when the agent platform changes its sandbox model, when a workflow adds a new tool or credential, when package-install behavior changes, or when security guidance for agentic systems moves. The workbench is an operating control, not a one-time setup screen.

The workstation is optimized for a trusted human with broad context and durable responsibility. A coding-agent workbench is optimized for a bounded task with reviewable output. Confusing those two environments is how small experiments turn into large, quiet permissions.

Give the agent a good place to work. Do not give it your whole desk.