Secure Coding-Agent Sandboxes and Ephemeral Credentials

Coding agents execute untrusted combinations of repository content, tool output, package scripts, and model-generated commands. A sandbox is not merely a convenient development container. It is the enforcement boundary that limits the impact of a mistaken instruction, prompt injection in a repository artifact, malicious dependency behavior, or an agent that takes an unsafe path.

This guide addresses the execution environment for software-delivery agents. It does not replace application threat modeling or production LLM security controls. OpenAI's February 2026 harness engineering discussion and Anthropic's agent-harness work both make the surrounding environment consequential; for security-sensitive delivery work, that environment needs enforceable isolation.

Start with a threat model

List the assets an agent could affect: source repositories, CI runners, package registries, signing keys, cloud control planes, staging data, production data, internal APIs, and customer information. Then consider the paths to those assets. The agent may follow untrusted text from an issue, README, web page, code comment, test fixture, tool response, or generated error message.

Map controls to realistic risks:

• Prompt injection and hostile repository content: do not grant tools the authority implied by content they read.
• Sensitive-information disclosure: prevent secrets from entering the filesystem, context, logs, traces, prompts, and pull requests.
• Excessive agency: require explicit approval for destructive actions, external writes, privilege changes, or deployments.
• Supply-chain compromise: constrain package installation, verify provenance where available, and isolate build execution.
• Resource exhaustion: cap CPU, memory, disk, process count, wall time, network transfer, and model/tool retries.

The OWASP Top 10 for LLM and GenAI is a useful risk catalogue, but apply it to the actual authority of your agent rather than treating a checklist as proof of safety.

Provision an isolated workspace per run

Create a new workspace, branch, and runtime identity for each task. Mount only the repository paths the task needs, use a non-root user, and use a read-only base image where practical. Dispose of the workspace at the end of the run after preserving approved artifacts such as the diff, test report, and trace metadata.

Avoid shared home directories, shared tool caches containing credentials, and long-lived volumes across tenants or trust boundaries. Shared state can leak data and make an evaluation pass for the wrong reason. A cache can be acceptable when it is integrity-checked, contains no secrets, and cannot be modified by an untrusted run.

Sandbox isolation should cover more than a container boundary. Set filesystem allowlists, process and resource limits, and a default-deny network policy. Permit only the package registry, source control endpoint, test service, or artifact store that the task requires, using explicit hostnames and paths where your platform supports them.

Use ephemeral credentials with narrow scope

Never inject a broad, long-lived personal access token or cloud key into an agent environment. Mint a short-lived workload identity just before the action that requires it. Bind it to the task, repository, branch or pull request, audience, operation, and expiry. Revoke or let it expire when the run ends.

Examples of appropriate scopes include read-only access to a single repository, permission to upload one test artifact, or authority to open a pull request from a designated branch. Credentials for production data, organization-wide administration, signing, or unrestricted package publishing should not be available to a general coding agent.

Use an identity broker or CI-issued workload identity rather than storing a token in a secret manager and copying it into every sandbox. Log issuance and use without recording the credential value. If a task needs elevated access, require a separate approval step, show the precise scope and duration, and record the approving identity.

Separate read, write, execute, and network authority

Do not collapse all capabilities into a shell with broad credentials. Model tools as distinct permissions:

• Repository read access for investigation.
• Workspace write access limited to a task branch.
• Command execution with CPU, memory, process, time, and filesystem limits.
• Package or source-control network access limited by egress policy.
• External side effects, such as posting to an issue tracker or creating a release, behind an approval boundary.

Validate tool parameters on the server side. A path allowlist, branch rule, command template, or typed API protects more reliably than asking a model to remember a policy. Treat shell commands and model-controlled URLs as untrusted input to the control plane.

Handle dependencies and test data safely

Package installation and test execution are code execution. Lock dependencies, use internal mirrors or provenance verification where warranted, and run install scripts inside the same constrained environment. Do not make production service credentials available simply because an integration test is convenient.

Prefer synthetic or de-identified test data. When controlled staging access is unavoidable, use a dedicated tenant, minimized data set, rate limits, and short-lived identity. Block test output from sending records, access tokens, or personal data into agent transcripts and telemetry. Redaction is a backstop, not a reason to overexpose data.

Preserve audit evidence without retaining secrets

Record the task identifier, harness version, base commit, image digest, policy decisions, tool requests, approved scopes, commands, exit codes, changed paths, and validation outcomes. Correlate those records with CI and pull-request evidence. Set retention and access controls that match the sensitivity of code and operational metadata.

Capture model prompts, source code, command output, and tool parameters only under a documented privacy policy. Prefer hashes, identifiers, classifications, and bounded excerpts where full capture would expose customer data or secrets. Test redaction with deliberate canary values and include trace storage in incident-response planning.

Respond to policy failures safely

A denied egress request, expired credential, blocked path, or budget breach is an expected outcome, not a signal to bypass the control. Return a concise reason and the approved escalation path. Stop the run if it cannot proceed safely, and preserve enough evidence for an operator to decide whether the task, policy, or repository setup needs to change.

Rotate any credential suspected of exposure, invalidate the affected sandbox image or cache, investigate the trace, and assess downstream actions. Rehearse this flow before granting agents access to valuable repositories or staging systems.

Sandbox checklist

• Create isolated workspaces, branches, and identities for every run.
• Default-deny filesystem access, network egress, and external side effects.
• Use short-lived, task-bound credentials with narrowly defined audiences and operations.
• Keep production secrets, signing authority, and broad cloud administration outside general agent environments.
• Limit resources and retries to contain both malicious and accidental consumption.
• Treat dependencies, fixtures, and test scripts as untrusted execution inputs.
• Audit policy decisions and outcomes while minimizing sensitive trace capture.

Authoritative references

• OpenAI: Harness engineering: leveraging Codex in an agent-first world, February 11, 2026
• Anthropic: Building Effective AI Agents
• OWASP Top 10 for LLM and GenAI
• OWASP Secrets Management Cheat Sheet
• NIST SP 800-207: Zero Trust Architecture