Security guide

Secure Coding Agent Sandboxes and Ephemeral Credentials

Constrain what a coding agent can reach and change, then make every privileged action attributable, short-lived, and reviewable.

Published: Jul 14, 2026
Updated: Jul 15, 2026
Reading time: 9 min read

On this page

Coding agents execute untrusted combinations of repository content, tool output, package scripts, and model-generated commands. A sandbox is an enforcement boundary, not merely a convenient development container. It limits the consequence of a mistaken instruction, hostile repository content, dependency behavior, or unsafe agent action.

The same discipline that keeps a managed edge orchestration layer trustworthy at scale — one policy enforced consistently across providers, every decision observable rather than assumed — applies to coding agent sandboxes: authority must be scoped, enforced, and evidenced at the boundary, not requested politely in a prompt.

Overview

Outcome

ACME-1842 runs in a disposable Acme Shop checkout-api workspace that can read and patch its allowed files, use a test tax-provider stub, and submit evidence, while production identities and unapproved hosts remain unavailable.

Overview

Prerequisites

Use isolated runners, a non-root runtime, task-scoped workload identity, a policy decision point for paths and egress, an approved artifact store, and incident ownership for denied or suspected exposure events.

Model the authority, not just the prompt

For the common Acme Shop scenario, the agent fixes missing-country validation in services/checkout-api. The repository may contain a comment that suggests querying a live tax service. Treat that comment as untrusted input. The task needs a synthetic test double, not production data or broad cloud credentials.

Acme Shop sandbox boundary

Isolated workspace
Path policy
Approved registry and test stub
Short-lived PR identity
Audit event or denial

The checkout-api workspace can reach only approved development dependencies. Egress and identity decisions are enforced by the sandbox policy, not by the agent's instruction text.

A coding-agent sandbox enforces authority at each boundary

Filesystem, network, and credential authority are separately enforced and audited so an agent instruction cannot widen the task's actual permissions.

Download:PNG SVG

Task sandbox policy

task: ACME-1842
filesystem:
read_write: ["services/checkout-api/**"]
read_only: ["package.json", "bun.lock"]
deny: [".env*", "infra/**", "services/payments-api/**"]
egress:
allow: ["registry.acme.test", "tax-stub.acme.test", "artifacts.acme.test"]
default: deny
identity:
audience: "source-control.acme.test"
permissions: ["pull-request:create"]
expires_in: "15m"

The schema is an example, not a claim about a particular sandbox product. Implement equivalent controls with the isolation, identity, and network mechanisms your platform actually provides, then test their failure behavior.

Match agent execution isolation to the risk

Agent execution isolation is not one setting; coding agent sandboxes should match the mechanism to what the task executes:

Namespaced containers — cheapest, fastest; fine for read, write, and lint tasks that execute no repository code.
User-space kernel interception — re-implements syscalls in user space, shrinking what a compromised process can reach; suits test suites against a pinned dependency set.
Per-run microVMs — each run gets its own disposable kernel, so a container-escape bug cannot reach the host or a neighboring run. Reserve this for build or test scripts and unreviewed package code — the ACME-1842 case, since bun install and the tests both run code the policy did not author.

Separate guidance from enforced controls

“Do not read secrets,” “do not call production,” and “do not merge” are prompt guidance. They may help an agent choose a safe path; they cannot block a syscall, packet, token exchange, or branch update.

Enforced controls are filesystem mounts and allowlists, non-root execution, resource limits, default-deny egress, identity audience and scope checks, server-side tool validation, branch protection, and approval gates. These controls do not eliminate every risk or configuration error; they reduce available authority and make denials observable.

Use a fresh workspace, branch, and runtime identity per run. Avoid shared homes, credentials in tool caches, and mutable cross-tenant volumes. Integrity-checked dependency caches can be useful when they contain no secrets and cannot be modified by an untrusted run.

Dependency installation is its own enforced step, not agent guidance: lifecycle scripts can execute code the moment a manifest installs. Disable install-time scripts by default and resolve packages against a hash-pinned lockfile, not a version range.

Deny egress and identity safely

The agent should receive a concise, actionable denial rather than a bypass route. An attempt to reach api.tax.acme.example must fail because it is not in the egress allowlist. An attempt to request a production audience must fail because the broker accepts only the task's source-control audience and narrow permission.

Representative policy-denial output

[ACME-1842] egress denied
host=api.tax.acme.example reason=host_not_allowlisted policy=v3.4
recovery=use tax-stub.acme.test or request reviewed policy change

[ACME-1842] identity denied
audience=production-control-plane reason=audience_not_permitted
recovery=stop; task requires a separately approved production workflow

Do not respond to either result by adding a broad allowlist entry, exporting a long-lived personal token, or disabling the policy. Preserve the task ID, policy version, request classification, and trace ID. An owner can decide whether the fixture is wrong, the task needs a different approved workflow, or the request was unsafe.

A denial that is really a legitimate gap still goes through the same reviewed change process as any policy edit, not a live grant widened to unblock a stuck run.

Issue ephemeral credentials for agents through a broker

Ephemeral credentials for agents follow the pattern of the task sandbox policy above: a broker exchanges the run's short-lived workload identity — attested from the image digest and task metadata, never baked into the image — for a credential scoped to exactly the permitted operation, issued right before it is needed and expired soon after.

Scope and expiry limit what a stolen credential can do, but not what an agent can be tricked into doing with a valid one. Content that cannot reach api.tax.acme.example directly can instead get the agent to paste the credential into a commit message — an allowed channel carrying a payload the policy never inspected. Defend at the enforcement layer: keep raw credentials out of the model's context, redact token shapes before egress, and bind the credential to the run so a captured value cannot replay elsewhere.

Scope drift is invisible until someone aggregates it

One sandbox's denial log looks fine alone. The pattern that matters — a pull-request:create identity writing token-shaped strings into PR bodies, or the same host silently allowlisted by three agent platforms — only shows up once audit events from every sandbox and broker land in one place. That is the fleet-wide visibility Optimi's MYO layer is built to surface; it does not replace any broker's own scope decisions, it makes them observable across providers.

Validate and recover

Positive validation: the checkout test writes only under its workspace, reaches tax-stub.acme.test, uploads one test artifact, and can create a pull request with its short-lived identity.
Negative validation: a process attempts to read .env.production, edit infra/, or call the live tax hostname. The policy denies each operation and records a classification without logging a secret.
Failure validation: simulate an expired PR identity during upload. The run stops, keeps the local diff and test report, and reports identity_expired; it must not retry with a different identity or write to an external system.
Exfiltration validation: plant a fixture that copies a canary credential-shaped string into a commit message; confirm redaction strips it pre-egress and logs a distinct event.

Recovery is scoped: renew only the same task-bound permission through the broker when the task remains valid, or discard the workspace and start again — including when an identity expires mid-write, rather than resuming against partial output. If exposure is suspected, revoke the identity, invalidate affected cache or image material, investigate access-controlled traces, and assess downstream actions under the incident process.

Protect audit evidence and test data

Record task ID, base commit, image digest, policy version and decision, issued scope metadata, changed paths, commands, exit codes, and validation result. Do not record the credential value. Prompts, source, and command output can contain sensitive information; prefer hashes, classifications, bounded excerpts, retention limits, and access control. Redaction is a backstop, not permission to expose production records to a test.

One run's audit event rarely proves a problem alone; a scope requested constantly, or once against an unexpected host, is a pattern visible only in aggregate. Retain structured metadata, never the credential, and flag runs that do not match.

Troubleshooting

Symptom	Likely cause	Evidence to collect	Safe recovery
Package install is blocked	Registry host is missing from allowlist	Denied host and dependency name	Add only the approved registry after supply-chain review.
PR upload returns identity expired	Run outlived its short-lived grant	Task ID, expiry, requested operation	Renew the same narrow grant or rerun; never substitute a personal token.
Test cannot reach tax stub	Fixture hostname or DNS setup is wrong	Resolved host and policy decision	Repair the test environment; do not allow live tax egress.
Policy denies an expected checkout file	Allowlist does not match task contract	Path, contract version, policy version	Review and narrowly amend the contract and policy.
Trace contains a canary value	Redaction or capture policy failed	Trace ID and data class	Restrict access, remediate pipeline, rotate if it was a real secret, then retest.
Install step runs code before any agent instruction	Lifecycle script executed on install	Package, script name, lockfile hash	Disable install-time scripts by default; re-enable only for one reviewed package.
Token-shaped string shows up in a PR body or commit	Agent was steered into copying credential material into an allowed channel	Redaction match, task ID, destination	Revoke the identity immediately and open the incident process.

Authoritative references

Run one isolation and identity standard across every agent

Talk to Optimi about extending consistent sandbox isolation, ephemeral credentials, and MYO visibility across every coding agent and CI pipeline your teams run.

Discuss agent sandbox security