AI Coding Agents Need a Runtime Boundary: Sandboxes, Secrets, and Review

AI coding agents are safer to operate when the agent that plans a change is separated from the worker that executes commands. Put repositories, build caches, and narrowly scoped secrets inside an isolated worker; let the agent request work through a controlled connection; and require reproducible checks and human approval before merging. Recent platform updates make this boundary practical, but they do not remove the need to design it deliberately.

On September 2, 2026, Cloudflare announced support for running Cursor Cloud Agents on Cloudflare Sandboxes, describing a model in which Cursor hosts the agent loop while a customer-controlled worker executes terminal, filesystem, and browser actions [1]. Its accompanying tutorial describes one isolated container per assigned session, with an outbound connection to Cursor and no inbound port or public IP required [2]. On September 3, GitHub’s Agentic Workflows project shared an example that periodically triages issues and hands selected work to a coding agent using a deliberately narrow set of allowed actions [3].

What the runtime boundary separates

An AI coding agent usually has at least two different responsibilities. The control side interprets a task, plans steps, chooses tools, and reports progress. The execution side checks out code, runs commands, reads files, starts tests, and may access credentials or internal services. Treating both sides as one trusted process makes it difficult to answer a basic security question: which component was actually allowed to touch the repository or secret?

A runtime boundary gives each side a narrower job. The control plane can coordinate a session, while a worker inside a sandbox performs the filesystem and process operations. Cloudflare’s documentation explicitly describes this split: Cursor remains responsible for the agent loop, inference, and planning, while the sandbox runs commands in an isolated container [2]. That separation is useful even when the worker is on a developer laptop rather than a cloud platform.

A simple boundary map

Task request
    |
    v
Agent control plane: plan, choose tools, report results
    |
    | controlled session connection
    v
Execution worker: checkout, terminal, tests, browser, artifacts
    |
    +-- repository and build cache
    +-- short-lived, least-privilege credentials
    +-- explicit network and time limits

The diagram is not a promise that a sandbox is automatically secure. It is a design prompt. The worker still needs operating-system isolation, dependency controls, logging, expiration rules, and a review gate. The goal is to make the blast radius visible and bounded rather than to imply that an agent can be trusted because it runs in a container.

How self-hosted execution changes the network model

In the Cloudflare and Cursor model documented this week, the worker opens an outbound connection to Cursor. The container does not require an inbound port or public IP [1] [2]. This is a meaningful operational constraint: a platform team can avoid exposing a new public service merely to let the agent receive work.

Outbound-only does not mean unrestricted. The worker can still send source fragments, logs, screenshots, or other artifacts to the control service, and it can still reach any internal or external destination permitted by its network policy. Before enabling a worker, write down which destinations it needs and deny the rest. A useful default is to allow the source-control host, package registries required by the build, and explicitly approved test services—then review exceptions as part of the pull request.

Network questions worth answering

Ask whether the worker can reach production endpoints, whether dependency installation can execute lifecycle scripts, whether browser actions can access internal applications, and whether uploaded artifacts can contain secrets. Record the answers in the worker configuration or repository handoff. If the answer is unknown, treat it as an unresolved risk rather than as a harmless implementation detail.

Keep secrets outside the agent’s default authority

A coding agent often needs credentials to clone a private repository or run an integration test, but it rarely needs every credential available to the developer. Use a dedicated identity for the worker, scope it to the smallest repository and action set, and prefer short-lived tokens or credentials issued for one session. Do not place long-lived production keys in a general-purpose environment variable file that an agent can read while debugging.

The practical rule is simple: if a task can be completed without a secret, do not mount the secret. If a secret is required, make its purpose explicit, redact it from logs, and destroy or rotate it when the worker expires. Cloudflare’s announcement says that repositories, build caches, and secrets remain on the customer’s machines during self-hosted operation, while model-read file chunks and agent artifacts may be uploaded for pull requests and dashboards [1]. That distinction should inform a data-flow review: local storage is not the same as “nothing leaves the worker.”

Make autonomous work easy to review

GitHub’s Issue Monster example is instructive because it limits the workflow to three output actions: assign work to an agent, add a comment, or do nothing [3]. Narrow actions reduce accidental side effects, but the more important pattern is the explicit handoff. The workflow evaluates whether candidates overlap, chooses distinct issues, and leaves a consistent explanation of the assignment [3].

Apply the same discipline to code changes. Before an agent starts, define the goal, non-goals, allowed files, checks, and approval owner. At the end, require a handoff that states what changed, which commands ran, what passed, what was not run, and what remains uncertain. TOOlover’s AI coding-agent pull-request review guide expands this into a behavior-focused review workflow, and the review-gates guide covers explicit approval before a change crosses the pre-PR boundary.

A reviewable worker handoff

Goal: update the retry behavior for transient API failures.
Boundary: src/retry.ts and its tests only; no dependency or auth changes.
Checks: pnpm test --filter retry; pnpm build.
Results: both passed.
Not run: integration tests requiring staging credentials.
Risk: retry delay was not measured under production traffic.
Approval needed: maintainer review of error handling and timeout behavior.

A worker that cannot produce this evidence should not be granted more authority. For a quick mechanical comparison of generated configuration or text, TOOlover’s Text Diff can surface changes, while the JSON Validator can check structured data syntax. Those tools support review; they do not replace a maintainer’s decision about behavior or access.

A practical rollout sequence

Start with a disposable repository or a low-risk maintenance task. Run one session in an isolated worker with no production credentials and a restrictive egress policy. Inspect the files the agent reads, the commands it runs, and the artifacts it uploads. Then add one capability at a time—private dependencies, browser testing, or a staging service—only when a real task requires it.

For recurring triage, copy the bounded-action pattern from GitHub’s example: prefetch the issue view, choose from a defined set of actions, make “no operation” a valid result, and leave an auditable comment [3]. For interactive coding sessions, follow the worker-lifecycle pattern in Cloudflare’s tutorial: assign a unique worker, isolate the session in a container, enforce idle and maximum lifetimes, and stop the container when the session ends [2].

The current direction is clear without requiring a grand autonomous engineering system. AI coding agents can plan in one place and execute in another, but the boundary must be treated as part of the product: define what crosses it, constrain what the worker can do, and keep a human accountable for the final change. That is how a faster coding loop becomes a reviewable engineering workflow instead of an opaque privileged process.