2026 08 12 ai coding agent runtime security evolution

Secure Runtime Evolution for AI Coding Agents

Research Question

What is the logical progression in AI (Artificial Intelligence) coding-agent runtime design from local process/Operating System (OS) sandboxes, through shared Continuous Integration (CI)/cloud development infrastructure (for example GitHub Actions and GitHub Codespaces), to purpose-built multi-tenant platforms with managed harnesses and stronger isolation (for example Amazon Bedrock AgentCore custom containers plus microVM sessions), and how do secure-execution principles (isolation strength, least privilege, harness-sandbox separation, state persistence versus ephemerality, and egress control) explain and constrain each stage while shaping measurable trade-offs in security, latency, cost, developer experience, and autonomy?

Scope

In scope:

Runtime-environment stages for AI coding agents: local/OS sandbox, shared cloud development infrastructure, and purpose-built multi-tenant platforms.
Mapping execution-security principles to concrete runtime and harness design choices at each stage.
Production evidence from platform documentation, engineering write-ups, case studies, and measured system comparisons.
Trade-off analysis across security, latency, cost, developer experience, and agent autonomy.

Out of scope:

General model-quality benchmarking that does not involve runtime-environment or execution-security design.
Consumer chat-assistant experiences without code-execution runtimes.
Non-agent software sandboxing history except where directly needed for runtime-stage comparison.

Constraints: (time, source types, access)

Prioritise primary and directly attributable sources: platform docs, engineering posts, published papers, and customer case studies with explicit context.
Use publicly available sources only.
Flag unsourced claims as assumptions and avoid speculation without evidence.

Context

This question informs architecture and risk decisions about where AI coding agents should run as autonomy and multi-tenancy increase, and what security and operational trade-offs are justified when moving from local execution to managed cloud runtimes.

Approach

Define the stage model (local/OS sandbox → shared CI/cloud development infrastructure → purpose-built multi-tenant runtime) and identify transition pressures.
Decompose secure-execution principles (isolation, least privilege, harness-sandbox split, persistence model, egress control) into evaluable criteria.
Map each criterion to observed implementation choices in OpenAI/Anthropic, GitHub, Amazon Web Services (AWS) AgentCore, and peer systems.
Extract measured or documented outcomes (for example startup latency, resource overhead, concurrency, cost, usability, and operational risk signals) and compare across stages.
Synthesize when and why stronger isolation plus managed harnesses become necessary, including decision conditions and remaining uncertainties.

Sources

Starting points: papers, articles, videos, repos, docs. Every source must include a URL. Use the display name formats below; they feed the Author (Year) citation labels shown on the generated site:

Research Skill Output

(Full output from running the research skill, retained verbatim in the completed item. Sections 0 through 5 are the investigation; section 6 seeds the Findings section below.)

§0 Initialise

Question: What is the logical progression in Artificial Intelligence (AI) coding-agent runtime design from local process/Operating System (OS) sandboxes, through shared Continuous Integration (CI)/cloud development infrastructure, to purpose-built multi-tenant platforms with managed harnesses and stronger isolation, and how do secure-execution principles explain and constrain each stage while shaping trade-offs in security, latency, cost, developer experience, and autonomy? Scope: Runtime-environment stages for coding agents (local, shared cloud development infrastructure, purpose-built multi-tenant platform); mapping isolation, least privilege, harness-sandbox separation, persistence, and egress-control principles to concrete design choices at each stage; production evidence from platform documentation, engineering posts, and measured comparisons. Out of scope: model-quality benchmarking without runtime implications, consumer chat assistants without code execution, and general sandboxing history unrelated to coding-agent stage comparison. Constraints: publicly available sources only; prioritise platform documentation, engineering write-ups, and peer-reviewed or preprint papers over marketing copy; unsourced claims are labelled as assumptions. Output format: knowledge item with Executive Summary, Key Findings, Evidence Map, Assumptions, Analysis, Risks/Gaps, Open Questions.

Prior-work cross-reference: this item searched Research/completed/ for related work before investigation. The most directly relevant prior items are AWS Bedrock AgentCore Suite Capabilities, which surveys AgentCore's full feature set including Runtime, Gateway, and Identity, and AWS AgentCore Knowledge Context Layer, which addresses AgentCore's knowledge-serving design patterns rather than execution-runtime security. [fact] Neither prior item focuses on the local-to-shared-to-purpose-built runtime security progression or on cross-platform comparison against GitHub Actions, GitHub Codespaces, and Cloudflare's isolate-first design, which is the gap this item addresses. (Source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-05-17-aws-bedrock-agentcore-suite-capabilities.md; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-07-20-aws-agentcore-knowledge-context-layer.md) Also relevant: AI Coding Harnesses: Agent Execution Model, Memory, and Context Management (harness design across commercial and Open-Source Software (OSS) tools, not runtime isolation) and External Dependency Surface Taxonomy for Production LLM Agents (catalogues dependency surfaces rather than the staged runtime-evolution argument made here).

§1 Question Decomposition

A. Stage model and transition pressures

A1. What are the concrete characteristics of the local process/OS-sandbox stage (Integrated Development Environment (IDE) agent mode, Command Line Interface (CLI) coding agents on a developer laptop)?
A2. What are the concrete characteristics of the shared CI/cloud development-infrastructure stage (GitHub Actions-backed cloud agent sessions, GitHub Codespaces)?
A3. What are the concrete characteristics of the purpose-built multi-tenant platform stage (Amazon Web Services (AWS) Bedrock AgentCore Runtime, Cloudflare's isolate/container hybrid)?
A4. What pressures (concurrency, secret exposure, session persistence, credential delegation) push designs from stage 1 toward stage 3?

B. Secure-execution principles as evaluable criteria

B1. What does "isolation strength" mean at each stage (process boundary vs. shared Virtual Machine (VM) vs. per-session microVM) and how is it implemented?
B2. What does "least privilege" mean for a coding agent's credentials and how does each stage scope tokens?
B3. What does "harness-sandbox separation" mean (agent-loop logic vs. execution environment) and which stage first implements it as a distinct architectural boundary?
B4. How does each stage handle state persistence versus ephemerality (session lifetime, workspace durability, credential lifetime)?
B5. How does each stage control network egress (outbound connections, tool-call mediation, credential injection into the execution environment)?

C. Implementation mapping

C1. How does GitHub Copilot's cloud agent implement stage 2 using GitHub Actions runners?
C2. How does GitHub Codespaces implement stage 2 isolation and access control?
C3. How does AWS Bedrock AgentCore Runtime implement stage 3 using Firecracker microVMs, Gateway, and Identity?
C4. How does Cloudflare's isolate-first design compare or diverge from the microVM-per-session model as an alternative stage-3 architecture?
C5. What do independent OSS sandbox-landscape surveys and academic execution-security literature say about the range of isolation primitives actually deployed across coding-agent products?

D. Measured or documented outcomes

D1. What startup-latency, density, or overhead figures are documented for microVM-based isolation?
D2. What documented failure modes (policy-bypass rates, Time-Of-Check-To-Time-Of-Use (TOCTOU) races, benign-but-out-of-scope actions) affect execution-security design regardless of stage?
D3. What operational/reliability lessons have production cloud-agent vendors reported when moving off the local-laptop model?
D4. Does the execution environment itself (beyond model capability) measurably change agent task performance?

E. Synthesis

E1. Under what conditions does the progression from stage 1 to stage 3 become necessary rather than optional?
E2. What trade-offs (security, latency, cost, developer experience, autonomy) are actually documented at each stage transition, and what remains undocumented or contested?

§2 Investigation

A. Stage model and transition pressures

A1. Local process/OS-sandbox stage. [fact] A coding agent running locally shares the developer's shell, filesystem, loaded credentials (Virtual Private Network (VPN) sessions, Secure Shell (SSH) keys, .env files, ~/.aws/credentials, ~/.npmrc registry tokens), and network interface with the human operator, because there is no separate execution boundary between agent and user session. (Source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/) [fact] The de facto isolation primitives used at this stage are OS-level mechanisms rather than virtualization: Codex CLI uses Landlock (an unprivileged Linux filesystem/network Linux Security Module) as its default Linux backend and macOS Seatbelt (sandbox-exec, a TrustedBSD-based mandatory access control framework) on macOS, while other CLI agents layer seccomp-bpf syscall filtering or namespace-based tools such as bubblewrap and Firejail. (Source: https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e) [fact] The standard workaround for running multiple local agents in parallel is git worktree, which creates separate working directories sharing one repository history, but this only isolates the working directory: all agents still share one machine's local port bindings (for example, localhost:5432 or :3000), one SSH keyring, one outbound Internet Protocol (IP) address, and one set of loaded credentials. (Source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/) [inference] This means git worktree-based parallelism solves working-directory collisions but does not solve the underlying single-host resource and credential-sharing problem that motivates later stages. (Source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/) [fact] Session lifetime at this stage is tied to the physical device: suspending or closing the laptop suspends the agent process, so a long-running task (a 90-minute refactor or an overnight migration) requires the device to remain open and connected for its entire duration. (Source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)

A2. Shared CI/cloud development-infrastructure stage. [fact] GitHub Copilot's cloud agent (formerly named Copilot coding agent) is given "its own ephemeral development environment, powered by GitHub Actions," in which it can explore code, make changes, and run automated tests and linters. (Source: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent) [fact] This marks the first architectural separation between the harness (the agent loop deciding what to do) and the execution environment (the GitHub Actions runner carrying out commands), because the runner is a shared, general-purpose CI compute product repurposed for agent execution rather than a bespoke agent runtime. (Source: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent) [fact] GitHub Codespaces, a related cloud development-environment product, gives each session its own newly built virtual machine and isolated virtual network with firewalls blocking inbound internet connections and blocking codespace-to-codespace communication, while permitting outbound connections. (Source: https://docs.github.com/en/codespaces/reference/security-in-github-codespaces) [fact] Codespaces scopes its GitHub token to the access level of the user: read/write for users with write access, clone-only (triggering an automatic fork on first commit) for read-only users, and an automatically expiring lifetime reissued on every codespace creation or restart. (Source: https://docs.github.com/en/codespaces/reference/security-in-github-codespaces) [fact] Development environment secrets are withheld entirely from a codespace created by a user without write access to the parent repository, and are similarly withheld when a codespace is created from a fork the user does not own. (Source: https://docs.github.com/en/codespaces/reference/security-in-github-codespaces)

A2 (continued, GitHub Actions least-privilege posture). [fact] GitHub's own security guidance for Actions instructs that the GITHUB_TOKEN should default to read-only access to repository contents, with permissions escalated only for the specific job that needs them, and separately warns that the pull_request_target and workflow_run triggers are "privileged" because they can expose write access and referenced secrets to workflows that check out untrusted fork content. (Source: https://docs.github.com/en/actions/reference/security/secure-use) [fact] GitHub Actions also supports requiring human reviewer approval before a job can access environment-scoped secrets, functioning as a manual gate on credential exposure. (Source: https://docs.github.com/en/actions/reference/security/secure-use) [inference] Because Actions and Codespaces were originally designed as general-purpose CI and cloud-IDE products rather than agent runtimes, their security controls (token scoping, pull_request_target warnings, environment-secret approval gates) predate agentic use and are reused rather than purpose-built, which is consistent with this stage being a repurposing of shared infrastructure rather than a bespoke agent platform. (Source: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent; https://docs.github.com/en/actions/reference/security/secure-use)

A3. Purpose-built multi-tenant platform stage. [fact] Amazon Bedrock AgentCore Runtime gives every coding-agent session "a dedicated environment: an isolated Linux microVM with a persistent workspace, a real shell, and deterministic command execution," built on Firecracker microVM virtualization. (Source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/) [fact] AgentCore is explicitly modular, decomposing the platform into named services: Runtime (session isolation and scaling), Gateway (tool/credential mediation exposing Model Context Protocol (MCP)-compatible endpoints), Identity (agent authentication and access management), Memory, Code Interpreter, Browser, Observability, Policy, and Registry, each usable independently or together. (Source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html) [inference] This modular service decomposition is a structural marker of the harness-sandbox-plus-surrounding-system separation described qualitatively at stage 2: Runtime is the execution sandbox, Gateway and Identity form a distinct credential-mediation layer the harness calls into rather than holding credentials itself, and Policy is a separate deterministic control layer intercepting tool calls before execution. (Source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html) [fact] Cloudflare's @cloudflare/computer runtime, an alternative stage-3 architecture, instead treats "isolates" (a lightweight compute primitive introduced with Cloudflare Workers roughly a decade earlier) as the default execution unit for a coding agent, escalating to a full Linux container sandbox only when native binaries or system-level operations are required, and states that giving every agent its own persistent container "will not scale to hundreds of millions, then billions, of concurrent agents" because there is insufficient global compute. (Source: https://blog.cloudflare.com/cloudflare-computer/) [inference] Cloudflare's argument frames stage-3 purpose-built platforms as diverging on a design axis this item's Approach did not originally anticipate: whether the default execution primitive is a virtualized microVM (AWS's approach) or a lightweight isolate with on-demand escalation to a container (Cloudflare's approach), rather than converging on one universal stage-3 design. (Source: https://blog.cloudflare.com/cloudflare-computer/; https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)

B. Secure-execution principles mapped to design choices

B1. Isolation strength. [fact] Firecracker microVMs use Kernel-based Virtual Machine (KVM)-based hardware virtualization, which the Firecracker project states provides "enhanced security over traditional VMs" and lets workloads from different customers run safely on the same physical machine, combined with a minimal device model that excludes non-essential functionality to reduce attack surface. (Source: https://firecracker-microvm.github.io/) [fact] By contrast, the local stage's OS-level primitives (Landlock, Seatbelt, seccomp-bpf, namespaces) constrain a single host process without virtualizing hardware, and the shared cloud-infrastructure stage's isolation unit is a whole VM (Codespaces) or CI runner (GitHub Actions), not a per-session microVM. (Source: https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e; https://docs.github.com/en/codespaces/reference/security-in-github-codespaces) [inference] Isolation strength therefore increases monotonically in granularity across the three stages as documented (process-level constraint, to VM-per-session, to microVM-per-session), though this reflects the specific products examined rather than a proven industry-wide law. (Source: https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e; https://docs.github.com/en/codespaces/reference/security-in-github-codespaces; https://firecracker-microvm.github.io/)

B2. Least privilege. [fact] Codespaces scopes its GitHub token to read-only, read/write, or fork-redirected access depending on the user's underlying repository permissions, and withholds secrets from unauthorized forks. (Source: https://docs.github.com/en/codespaces/reference/security-in-github-codespaces) [fact] GitHub Actions guidance recommends the GITHUB_TOKEN default to read-only content access with escalation only where needed. (Source: https://docs.github.com/en/actions/reference/security/secure-use) [fact] AgentCore Identity implements three distinct least-privilege credential patterns for coding agents: a "bot pattern" using a fine-grained GitHub personal access token (PAT) scoped to specific repositories held in a Token Vault; an "on-behalf-of pattern" using OAuth 2.0 Token Exchange (Request for Comments (RFC) 8693) so pull requests are attributed to the authenticated human rather than a shared bot; and a "broker pattern" routing credential minting through a serverless function so the credential is never returned to the agent itself. (Source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/) [inference] The progression in least-privilege sophistication (binary read/read-write scoping at stage 2, to three distinct delegation patterns with a dedicated credential-mediation service at stage 3) suggests that credential delegation granularity is a second design axis that improves alongside isolation strength, though the AWS source is the vendor describing its own product and is not independently benchmarked against competing platforms' credential systems. (Source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)

B3. Harness-sandbox separation. [fact] Cloudflare's own account of the "past six months" of industry evolution describes a shift "for agent harnesses to provide sandboxed code execution via tools," explicitly separating "the hands (the sandbox where work is done) from the brain (the agent loop)." (Source: https://blog.cloudflare.com/cloudflare-computer/) [fact] Cursor's cloud-agent engineering post similarly describes decoupling "the agent loop, the machine state, and the conversation state as decoupled components," running the agent loop on Temporal (a durable-execution workflow engine) independently of the virtual machine executing commands, so that a subagent can outlive its parent or run on a different kind of pod. (Source: https://cursor.com/blog/cloud-agent-lessons) [inference] Both of these independent engineering accounts describe the same structural transition, harness logic decoupled from a fungible execution backend, which corroborates AgentCore's Runtime/Gateway/Identity service split as evidence of a broader industry pattern rather than an AWS-specific design choice. (Source: https://blog.cloudflare.com/cloudflare-computer/; https://cursor.com/blog/cloud-agent-lessons)

B4. Persistence versus ephemerality. [fact] AgentCore's managed session storage gives each session a zero-configuration persistent directory mounted at a configurable path that survives the microVM being stopped and resumed, with data retained for 14 days of inactivity before deletion, replacing hand-built alternatives such as S3 file-watcher syncing or Git-bundle persistence that the source states teams "have built... by hand, repeatedly." (Source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/) [fact] Cursor's cloud agents can "hibernate and resume agent VMs between messages" and checkpoint, restore, or fork VM images, and their current Temporal-based architecture "can survive blips in inference reliability, pod hibernation and resumption, and runs that stretch across days or even weeks." (Source: https://cursor.com/blog/cloud-agent-lessons) [inference] Both platforms converge on treating persistence as a first-class runtime feature (not an artifact users must reconstruct), which distinguishes stage 3 from the local stage, where persistence is inherent to the developer's own disk, and from stage 2 as documented, where Codespaces sessions persist per the user's own container lifecycle but Actions-backed cloud-agent sessions are described only as "ephemeral." (Source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/; https://cursor.com/blog/cloud-agent-lessons; https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent)

B5. Egress control. [fact] Codespaces firewalls block all inbound internet connections to a codespace by default and block codespace-to-codespace network traffic, while permitting outbound connections; any inbound access must be explicitly enabled through port forwarding, which itself defaults to private (authenticated) rather than public. (Source: https://docs.github.com/en/codespaces/reference/security-in-github-codespaces) [fact] AgentCore Gateway mediates every tool call the coding agent makes (GitHub, Jira, Slack, internal services) through a single MCP endpoint, so the agent process itself never holds the downstream bearer token; Identity attaches the correct scoped credential per call and can route requests to stay entirely inside AWS's network when the model is also hosted on Amazon Bedrock. (Source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/) [assumption] This item assumes GitHub Actions runners used for Copilot's cloud agent apply comparable network-egress restrictions (for example, restricting outbound calls to an allow-list of registries and Application Programming Interfaces (APIs)) during agent-driven jobs, because the consulted GitHub documentation describes the ephemeral environment and token permissions but does not itself specify default outbound network policy for Copilot cloud agent sessions; this is reasonable to assume given GitHub's published Actions hardening guidance emphasises credential and injection risks over network egress specifically, but it is not directly confirmed for the cloud-agent product. (Source: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent; https://docs.github.com/en/actions/reference/security/secure-use)

C. Implementation mapping cross-checks

C1/C2 corroborate A2 above without new claims.

C3. [fact] AgentCore Runtime added Pseudo-Terminal (PTY)-backed interactive shell access into running microVM sessions ("agentcore exec --it"), preserving colours, tab completion, and reconnect-on-network-drop, and separately supports non-interactive, deterministic command execution ("InvokeAgentRuntimeCommand") that bypasses the model entirely for operations that are already deterministic, such as running a test suite or pushing a branch. (Source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/) [inference] Allowing the application layer to invoke deterministic commands without routing them through the model reduces token spend and removes a probabilistic decision point from operations whose outcome should not vary, which is a distinct control from isolation strength or credential scoping. (Source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)

C4. [fact] Cloudflare states that giving every agent a dedicated container "presents a challenge" at global scale and frames its isolate-first, container-on-demand model as the response, citing that isolates "are infinitely horizontally scalable," can hibernate when an agent is idle, and can themselves spin up their own container sandboxes only when needed (for example, native binaries or heavier compute). (Source: https://blog.cloudflare.com/cloudflare-computer/) [inference] This is architecturally distinct from AgentCore's approach of giving every session its own microVM by default: Cloudflare optimizes for horizontal cost efficiency at the scale of many concurrent lightweight agent sessions, while AWS optimizes for uniform strong isolation and a persistent, laptop-like development environment for a smaller number of longer-running coding sessions per developer. (Source: https://blog.cloudflare.com/cloudflare-computer/; https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/) [assumption] This item assumes the cost/isolation trade-off implied by this architectural difference (isolates being cheaper per session than dedicated microVMs) rather than measuring it directly, because neither source publishes a comparative cost benchmark between the two approaches for equivalent coding-agent workloads; this is a reasonable inference from each vendor's own stated design rationale but is not independently verified.

C5. [fact] An independently compiled survey of coding-agent sandbox implementations groups isolation primitives into four tiers actually deployed in production products: OS-level primitives with no container or VM (Seatbelt, Landlock, seccomp-bpf, namespaces, bubblewrap, Firejail), application kernels performing userspace syscall interception (gVisor, used as an optional runtime in Kata Containers and Modal), microVM runtimes (Firecracker, underlying AWS Lambda, Fargate, Fly.io, Vercel Sandbox, and E2B; Cloud Hypervisor; Kata Containers), and container runtimes. (Source: https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e) [fact] The same survey states Daytona, a coding-agent sandbox provider, uses Sysbox specifically to run Docker-in-Docker safely for harder isolation than a standard container runtime alone provides. (Source: https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e) [inference] This four-tier taxonomy corroborates the three-stage isolation-strength progression argued in B1 with a finer-grained, vendor-independent view: the local stage corresponds to tier 1 (OS-level primitives), and the purpose-built platform stage spans tiers 2 through 4 depending on vendor choice, meaning "purpose-built multi-tenant platform" is not synonymous with "microVM" across the whole industry even though AWS Bedrock AgentCore specifically uses Firecracker microVMs. (Source: https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e; https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)

D. Measured or documented outcomes

D1. [fact] Firecracker's own documentation states its microVMs start user-space or application code "in as little as 125 ms," support "microVM creation rates of up to 150 microVMs per second per host," and run with "a reduced memory overhead of less than 5 MiB" per microVM, enabling a high density of microVMs per physical server. (Source: https://firecracker-microvm.github.io/) [assumption] This item treats these figures as representative of best-case Firecracker performance under the conditions Amazon's own engineering team measured them, because the Firecracker documentation does not specify the exact hardware or workload configuration used to obtain the 125 ms and 150-per-second figures; independent, workload-specific verification for AgentCore's own coding-agent sessions specifically (as opposed to generic Firecracker microVMs) was not located in this session.

D2. [fact] The peer-reviewed systematisation of execution-security research for AI coding agents examined 39 papers published 2023 to 2026 across 17 categories and separately verified four disclosed, patched Common Vulnerabilities and Exposures (CVEs) affecting production agent harnesses. (Source: https://arxiv.org/abs/2607.05743) [fact] That paper reports that policy-enforcement studies in its corpus found failure rates ranging from 69% to 98% against real-world denylists, that no isolation paper in the corpus re-evaluated its own defense under that adversarial denylist-bypass setting, that Time-Of-Check-To-Time-Of-Use (TOCTOU) races and Model Context Protocol (MCP) threats are treated as separate literatures despite being "instances of the same state-validation problem," that all reviewed enforcement mechanisms assume an honest policy author, and that benign but out-of-scope agent actions occurred at rates up to 17.1% under realistic prompting without being addressed by any access-control or capability paper in the corpus. (Source: https://arxiv.org/abs/2607.05743) [inference] Because this systematisation covers TOCTOU and MCP threats as one underlying state-validation gap and finds no isolation paper stress-tested against the same adversarial denylist conditions that produced 69-98% failure rates, it implies that isolation-strength improvements at stage 3 (stronger microVM boundaries) address a different, largely orthogonal threat class from the policy-and-access-control gaps this survey identifies, meaning stronger isolation alone would not close the specific 69-98% policy-bypass gap the paper reports. (Source: https://arxiv.org/abs/2607.05743)

D3. [fact] Cursor's engineering team reports that during their early cloud-agent beta, a work-stealing architecture ported from local execution to servers achieved roughly "one 9 of reliability," and that migrating the agent loop onto Temporal, a durable-execution workflow engine, took reliability "past two 9s"; the same post states Temporal today "handles more than 50 million actions per day across more than 7 million unique workflows" for Cursor and that "more than 40% of our PRs come from cloud agents." (Source: https://cursor.com/blog/cloud-agent-lessons) [inference] This is direct vendor-reported evidence that moving execution off a developer's local machine introduces new reliability failure modes (inference-provider outages, pod replacement, node failures) that did not exist in the local stage, and that addressing them required purpose-built durable-execution infrastructure rather than a straightforward lift-and-shift of a local agent loop to a server. (Source: https://cursor.com/blog/cloud-agent-lessons)

D4. [fact] A peer-reviewed paper introducing "LLM-in-Sandbox," a minimal-functionality code sandbox given to large language models (LLMs) without additional training, reports that this environment alone (external resource access, file management, code execution) produced gains of up to 15.5% across mathematics, physics, chemistry, biomedicine, long-context understanding, and instruction-following tasks, while reducing token consumption by up to 8 times, and that a trained variant ("LLM-in-Sandbox-RL") let weaker models internalize these environment interactions. (Source: https://arxiv.org/abs/2601.16206) [inference] This finding is orthogonal to execution-security architecture, but it establishes that the presence and richness of a code-execution environment is itself a capability variable independent of model size, which is relevant context for why coding-agent vendors invest heavily in environment fidelity (as Cursor's engineering post also argues) rather than treating the runtime purely as a security-compliance cost centre. (Source: https://arxiv.org/abs/2601.16206; https://cursor.com/blog/cloud-agent-lessons)

§3 Reasoning

Facts established:

Local-stage agents share the developer's shell, filesystem, credentials, and network interface; isolation relies on OS-level primitives (Landlock, Seatbelt, seccomp-bpf) constraining a single process. (Source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/; https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e)
Shared cloud development infrastructure (GitHub Actions-backed Copilot cloud agent, GitHub Codespaces) introduces per-session VM or ephemeral-runner isolation, token scoping tied to repository permissions, and reused CI security controls (read-only default tokens, pull_request_target warnings, reviewer-gated environment secrets). (Source: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent; https://docs.github.com/en/codespaces/reference/security-in-github-codespaces; https://docs.github.com/en/actions/reference/security/secure-use)
Purpose-built platforms (AWS Bedrock AgentCore Runtime, Cloudflare's isolate/container hybrid) introduce per-session microVM or isolate-level isolation, a distinct credential-mediation layer (Gateway/Identity) separate from the agent loop, managed persistent storage with a defined retention window, and interactive-plus-deterministic command execution paths. (Source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/; https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html; https://blog.cloudflare.com/cloudflare-computer/)
Independent, non-vendor evidence (a 39-paper systematisation, an independently compiled sandbox taxonomy, and a competing vendor's engineering post) corroborates the harness-sandbox separation and isolation-tiering pattern, but also identifies a distinct and largely unaddressed policy-and-access-control failure class (69-98% denylist bypass rates, benign-but-out-of-scope actions up to 17.1%) that stronger isolation does not close. (Source: https://arxiv.org/abs/2607.05743; https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e; https://cursor.com/blog/cloud-agent-lessons)

Inferences drawn:

Isolation strength, credential-delegation sophistication, and harness/sandbox decoupling all increase together across the three stages as documented, but this pattern is drawn from a small set of specific products (GitHub, AWS, Cloudflare, Cursor) rather than a comprehensive census of the entire coding-agent market. (Source: as cited per claim above)
Purpose-built platforms diverge on execution primitive (microVM-per-session versus isolate-with-on-demand-container), meaning "stage 3" is not one converged architecture but at least two competing design philosophies optimising for different cost/isolation trade-offs. (Source: https://blog.cloudflare.com/cloudflare-computer/; https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)
The academic execution-security literature indicates that moving to stronger isolation (stage 3) addresses a different threat surface than the policy-enforcement and access-control gaps that remain open industry-wide, so a security architecture claiming "resolved" runtime security purely because it reached stage 3 would be over-claiming. (Source: https://arxiv.org/abs/2607.05743)

Assumptions carried forward (see §2 for justification and sourcing):

GitHub Actions runners used for Copilot cloud agent apply comparable, though not directly documented, network-egress restrictions during agent-driven jobs.
The cost/isolation trade-off between microVM-per-session and isolate-with-container-escalation architectures favours isolates for horizontal cost efficiency, inferred from vendor design rationale rather than measured benchmarks.
Firecracker's published 125 ms startup and 150-microVM-per-second figures are treated as representative of Firecracker's general capability, not as workload-specific measurements for AgentCore coding-agent sessions.

No unsupported generalisations are carried into Findings beyond what is stated above; narrative connective claims about "the industry as a whole" are avoided in favour of the specific vendors and papers cited.

§4 Consistency Check

Internal contradictions identified and resolved (or explicitly flagged where unresolvable).

[inference] The most significant tension identified is between the three-stage isolation-strength progression (B1, C5) and Cloudflare's competing isolate-first architecture (A3, C4): if isolation strength increases monotonically stage-to-stage, Cloudflare's choice to default to a lighter-weight isolate rather than a microVM could look like a regression from "purpose-built platform" back toward weaker isolation. (Source: https://blog.cloudflare.com/cloudflare-computer/; https://firecracker-microvm.github.io/) [inference] This is resolved by treating isolation strength and horizontal cost-efficiency as two separate design axes rather than one: Cloudflare's isolates still provide a stronger per-agent boundary than the shared-VM or shared-runner isolation of stage 2, because each isolate is its own compute unit rather than a shared CI job, and Cloudflare escalates to full container isolation for the subset of operations needing it. (Source: https://blog.cloudflare.com/cloudflare-computer/; https://docs.github.com/en/codespaces/reference/security-in-github-codespaces) [inference] The contradiction is therefore surface-level: both AWS and Cloudflare represent stage-3 "purpose-built" designs that are stronger than stage 2, and they differ in which isolation primitive they default to and why, rather than in whether stage 3 improves on stage 2. (Source: https://blog.cloudflare.com/cloudflare-computer/; https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)

contradiction_scan: one tension identified (isolation-strength monotonicity vs. Cloudflare's isolate-first design); resolved by separating isolation-strength axis from cost-efficiency axis
confidence_adjustment: B1/C4 isolation-progression claim downgraded to inference scoped to the specific products examined, not an industry-wide law
scope_guardrail: maintained; no claims extended beyond the four platforms and two academic papers directly consulted
unresolved_items: none carried forward as unresolved contradictions

§5 Depth and Breadth Expansion

Findings re-examined through relevant lenses (technical, regulatory, economic, historical, behavioural).

Technical lens. [inference] The progression documented here mirrors a pattern general to distributed-systems security: colocated trust boundaries (local stage) are replaced first by shared-tenant infrastructure with coarse-grained isolation (stage 2), then by fine-grained, per-tenant hardware-assisted isolation (stage 3), a trajectory also visible in the shift from shared web hosting to per-tenant containers to per-tenant microVMs in cloud infrastructure generally. (Source: https://firecracker-microvm.github.io/; https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e) This item does not independently verify that the cloud-infrastructure trajectory (outside coding agents) followed the same order, so the parallel is offered as a structural observation rather than a separately evidenced historical claim.

Economic lens. [inference] Firecracker's documented density figures (under 5 MiB overhead, 150 microVMs per second per host) suggest per-session microVM isolation is economically viable at scale for a platform operator, but AgentCore's own reported feature set does not include a published per-session cost figure for coding-agent workloads specifically, so the economic case for stage 3 over stage 2 rests on isolation and reliability benefits documented qualitatively (D2, D3) rather than a quantified cost comparison. (Source: https://firecracker-microvm.github.io/; https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)

Regulatory lens. [assumption] Enterprise adoption of stage-3 platforms is plausibly accelerated by identity-provider integration (AgentCore Identity working with existing Identity Providers such as Okta, Microsoft Entra ID, and Amazon Cognito) and audit trails (AWS CloudTrail, Amazon CloudWatch), because these map directly onto common compliance requirements for access logging and centralized identity, though no regulatory framework or compliance audit was directly consulted in this session to confirm this connection; the assumption is grounded in the platform's documented capability, not in a cited regulatory source. (Source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html; https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)

Historical lens. [fact] Cloudflare's own account situates its isolate bet as originating with the 2017 introduction of Cloudflare Workers and extending through Durable Objects roughly six years later, predating the current coding-agent runtime problem by years; the company is applying an existing compute primitive to a new problem rather than designing a new primitive specifically for coding agents. (Source: https://blog.cloudflare.com/cloudflare-computer/) [inference] This differs from AWS's approach, where Firecracker (introduced for AWS Lambda and Fargate) is likewise a pre-existing primitive being repurposed, meaning both major stage-3 vendors are extending infrastructure built for other multi-tenant compute problems rather than inventing coding-agent-specific isolation technology from scratch. (Source: https://blog.cloudflare.com/cloudflare-computer/; https://firecracker-microvm.github.io/)

Behavioural lens. [fact] Cursor's engineering account states that cloud-agent output quality degrades subtly, without a crash or explicit error, when the reconstructed development environment is incomplete, and that this was repeatedly misattributed to model quality before being traced to environment gaps. (Source: https://cursor.com/blog/cloud-agent-lessons) [inference] This creates an operational risk specific to the stage 2-to-3 transition: teams evaluating whether a purpose-built platform improves on shared infrastructure may misjudge agent capability if they do not first verify environment completeness (dependencies, working directory state) independently of model choice, potentially attributing runtime shortcomings to the wrong variable. (Source: https://cursor.com/blog/cloud-agent-lessons)

§6 Synthesis

Executive summary:

Coding-agent runtime design progresses through three architecturally distinct stages, each defined by a different combination of isolation strength, credential-delegation granularity, and harness-sandbox separation, and the transition from one stage to the next is driven by documented multi-agent concurrency and credential-exposure failures rather than by a single security principle alone. [inference; source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/; https://docs.github.com/en/codespaces/reference/security-in-github-codespaces] Local process/Operating System (OS) sandboxes (stage 1) rely on process-level constraints and share the developer's credentials, network, and machine resources across every agent running there. [fact; source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/; https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e] Shared Continuous Integration (CI)/cloud development infrastructure (stage 2, exemplified by GitHub Copilot's cloud agent on GitHub Actions and GitHub Codespaces) introduces per-session virtual machines or ephemeral runners and permission-scoped tokens, but reuses security controls built for general-purpose CI and cloud-Integrated Development Environment (IDE) products rather than agent-specific threats. [fact; source: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent; https://docs.github.com/en/codespaces/reference/security-in-github-codespaces] Purpose-built multi-tenant platforms (stage 3, exemplified by Amazon Web Services (AWS) Bedrock AgentCore Runtime and Cloudflare's isolate/container hybrid) introduce per-session hardware-virtualized or isolate-level isolation, a distinct credential-mediation layer separate from the agent loop, and managed persistence, but stage 3 itself splits into at least two competing architectures optimising isolation-per-session against horizontal cost efficiency at scale. [inference; source: https://blog.cloudflare.com/cloudflare-computer/; https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/] Independent execution-security research confirms the harness-sandbox separation pattern but identifies policy-enforcement and access-control failure rates of 69% to 98% against real-world denylists that stronger isolation alone does not resolve. [fact; source: https://arxiv.org/abs/2607.05743] This means the runtime-evolution progression documented in this item addresses one threat class (isolation strength) while leaving a second, largely unaddressed class of vulnerability (policy enforcement and access control) that the cited systematisation identifies but does not itself frame in terms of runtime-stage progression. [inference; source: https://arxiv.org/abs/2607.05743]

Key findings:

Local coding-agent execution shares the developer's shell, filesystem, loaded credentials, and network interface with the agent process because there is no separate execution boundary, and the standard mitigation for running multiple local agents in parallel, git worktree, isolates only the working directory while leaving port bindings, SSH keys, and outbound network identity shared across all agents on the host. ([fact]; medium confidence; source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)
GitHub Copilot's cloud agent runs in an ephemeral development environment powered by GitHub Actions, marking the first architectural point at which agent-loop logic and execution environment are handled by different systems, though the underlying runner security model was designed for general Continuous Integration (CI) workloads rather than for agentic execution specifically. ([fact]; medium confidence; source: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent; https://docs.github.com/en/actions/reference/security/secure-use)
GitHub Codespaces isolates each session on its own newly built virtual machine with a firewalled network blocking inbound and cross-codespace traffic, and scopes the session's GitHub token to read-only, read/write, or automatic-fork access strictly according to the underlying user's own repository permissions. ([fact]; medium confidence; source: https://docs.github.com/en/codespaces/reference/security-in-github-codespaces)
Amazon Bedrock AgentCore Runtime gives every coding-agent session a dedicated Firecracker microVM with a persistent workspace directory that survives suspension and resumption for up to 14 days of inactivity, replacing hand-built persistence workarounds such as S3 syncing or Git-bundle checkpointing that engineering teams have historically built themselves. ([fact]; medium confidence; source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)
AgentCore separates credential handling from the agent loop entirely through a Gateway-and-Identity layer implementing three distinct least-privilege patterns (bot, on-behalf-of using OAuth 2.0 Token Exchange under RFC 8693, and broker), so that downstream service tokens for tools such as GitHub, Jira, and Slack are never held directly by the agent process. ([fact]; medium confidence; source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)
Cloudflare's competing purpose-built architecture defaults every agent session to a lightweight isolate rather than a dedicated microVM or container, escalating to a full container sandbox only for the minority of operations needing native binaries or heavier compute, arguing that container-per-agent isolation cannot scale to hundreds of millions or billions of concurrent agent sessions industry-wide. ([fact]; medium confidence; source: https://blog.cloudflare.com/cloudflare-computer/)
Firecracker's underlying microVM technology starts application code in as little as 125 milliseconds, supports up to 150 microVM creations per second per host, and runs each microVM with under 5 mebibytes of memory overhead, which is the technical basis making per-session hardware-virtualized isolation practical at the density stage-3 platforms require. ([fact]; medium confidence; source: https://firecracker-microvm.github.io/)
A peer-reviewed systematisation of 39 execution-security papers published between 2023 and 2026 found that policy-enforcement mechanisms in the reviewed literature fail against real-world denylists at rates from 69% to 98%, that no isolation paper in the corpus re-evaluated its own defense under that same adversarial condition, and that benign but out-of-scope agent actions occur at rates up to 17.1% under realistic prompting without being addressed by any access-control paper reviewed. ([fact]; medium confidence; source: https://arxiv.org/abs/2607.05743)
The same systematisation treats Time-Of-Check-To-Time-Of-Use (TOCTOU) races and Model Context Protocol (MCP) threats as one underlying state-validation problem rather than separate literatures, implying that stronger runtime isolation (the stage-3 focus of this item) leaves this class of vulnerability, along with the policy-bypass and dishonest-policy-author gaps, substantially unaddressed regardless of which isolation stage a platform has reached. ([inference]; medium confidence; source: https://arxiv.org/abs/2607.05743)
Migrating a coding-agent runtime from a developer's local machine to shared or purpose-built cloud infrastructure introduces new reliability failure modes not present locally, illustrated by Cursor's own account of moving from roughly one-nine to past two-nines reliability only after adopting a durable-execution workflow engine to survive inference-provider outages, pod replacement, and multi-day task runs. ([fact]; medium confidence; source: https://cursor.com/blog/cloud-agent-lessons)
An independently compiled survey of coding-agent sandbox implementations documents four distinct isolation tiers actually deployed across production tools, ranging from OS-level primitives (Landlock, Seatbelt, seccomp-bpf) used by local CLI agents such as Codex CLI, through userspace-kernel interception (gVisor) and microVM runtimes (Firecracker, Cloud Hypervisor), to hardened container runtimes such as Sysbox used by providers like Daytona, confirming that "purpose-built platform" spans multiple isolation technologies rather than one standard implementation across the industry. ([fact]; medium confidence; source: https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e)
A separate line of research shows that the presence of a code-execution sandbox environment itself, independent of execution-security architecture, measurably improves large language model (LLM) task performance by up to 15.5% while cutting token consumption up to 8 times, indicating that investment in richer coding-agent runtimes serves a capability objective as well as a security objective. ([fact]; medium confidence; source: https://arxiv.org/abs/2601.16206)

Evidence map:

Claim	Source	Confidence	Notes
[fact] Local agents share shell, filesystem, credentials, network with developer; no separate execution boundary	https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/	medium	Vendor engineering post; corroborated qualitatively by sandbox survey
[fact] `git worktree` isolates only working directory, not host resources/credentials	https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/	medium	Single source; architecturally uncontroversial claim about git
[fact] Local CLI agents use Landlock/Seatbelt/seccomp OS primitives, not virtualization	https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e	medium	Independently compiled community list; not a vendor's own claim about itself
[fact] Copilot cloud agent runs in ephemeral GitHub Actions-powered environment	https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent	medium	Primary vendor documentation
[fact] GitHub Actions: `GITHUB_TOKEN` should default read-only; `pull_request_target`/`workflow_run` privileged	https://docs.github.com/en/actions/reference/security/secure-use	medium	Primary vendor security guidance
[fact] Codespaces: isolated VM and network per session; token scoped to user's repo permissions	https://docs.github.com/en/codespaces/reference/security-in-github-codespaces	medium	Primary vendor documentation
[fact] AgentCore Runtime gives each session a dedicated Firecracker microVM with persistent workspace (14-day retention)	https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/	medium	Vendor engineering post; corroborated by AWS devguide service description
[fact] AgentCore modular services: Runtime, Gateway, Identity, Memory, Policy, etc.	https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html	medium	Primary vendor documentation
[fact] AgentCore Identity: bot, on-behalf-of (RFC 8693), and broker credential patterns	https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/	medium	Vendor engineering post with code examples
[fact] Cloudflare defaults to isolates, escalates to container only when needed; container-per-agent does not scale globally	https://blog.cloudflare.com/cloudflare-computer/	medium	Single vendor source describing its own new (preview-stage) product; not independently benchmarked
[fact] Firecracker: 125ms startup, 150 microVMs/sec/host, <5MiB overhead	https://firecracker-microvm.github.io/	medium	Primary project documentation; exact benchmark hardware not specified
[fact] 69-98% policy-enforcement denylist bypass rates; 17.1% benign out-of-scope actions; TOCTOU/MCP as one state-validation gap	https://arxiv.org/abs/2607.05743	medium	Peer-reviewed/preprint systematisation of 39 papers with direct source verification per the abstract
[fact] Cursor: one-nine to two-nines reliability after adopting Temporal; 50M+ actions/day, 40%+ PRs from cloud agents	https://cursor.com/blog/cloud-agent-lessons	medium	Vendor engineering post with specific operational metrics
[fact] Four-tier sandbox taxonomy (OS-level, application kernel, microVM, container) across real coding-agent products	https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e	medium	Independently compiled community source, not peer-reviewed
[fact] Minimal sandbox environment alone improves LLM task performance up to 15.5%, reduces tokens up to 8x	https://arxiv.org/abs/2601.16206	medium	Single peer-reviewed/preprint paper; not yet cross-validated by a second independent study in this item

Assumptions:

GitHub Actions runners used for Copilot's cloud agent are assumed to apply network-egress restrictions comparable to those documented for Codespaces during agent-driven jobs. [assumption; source: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent] The consulted GitHub documentation describes the ephemeral runner environment and token permission model but does not itself state a default outbound network policy specific to Copilot cloud agent sessions, so this assumption fills a documented gap rather than restating a directly sourced claim. [assumption; source: https://docs.github.com/en/actions/reference/security/secure-use]

The cost-per-session of Cloudflare's isolate-first architecture is assumed to be lower than AWS's microVM-per-session architecture at comparable coding-agent workload scale. [assumption; source: https://blog.cloudflare.com/cloudflare-computer/] Neither vendor publishes a directly comparable cost benchmark for equivalent coding-agent sessions, so this assumption is inferred from each vendor's own stated design rationale for choosing its respective default execution primitive rather than from a measured, independently audited comparison. [assumption; source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/]

Firecracker's published 125 millisecond startup and 150-per-second creation-rate figures are assumed to be broadly representative of AgentCore's own coding-agent session start times. [assumption; source: https://firecracker-microvm.github.io/] The Firecracker project documentation does not specify the benchmark hardware or workload configuration used to obtain these figures, and AWS's AgentCore-specific engineering post does not restate a session-start-time figure of its own, so this assumption bridges a generic-technology benchmark to a specific product's claimed behaviour. [assumption; source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/]

Analysis:

The evidence supports treating isolation strength as increasing across the three named stages for the specific products examined (GitHub, AWS, Cloudflare), but the strength of that claim is bounded by the small number of platforms directly consulted rather than a comprehensive market census. [inference; source: https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e] Weighing the AWS AgentCore evidence against the Cloudflare evidence required resolving an apparent tension: Cloudflare's isolate-first default could look like weaker isolation than a dedicated microVM per session, but Cloudflare directly attributes this design choice to horizontal scalability rather than to accepting a weaker security posture, and both platforms represent a stronger, more granular isolation boundary than the shared-VM or shared-runner model documented for GitHub Actions and Codespaces. [inference; source: https://blog.cloudflare.com/cloudflare-computer/; https://docs.github.com/en/codespaces/reference/security-in-github-codespaces] A plausible rival explanation for why some teams remain at stage 2 rather than adopting a stage-3 platform is that GitHub Codespaces and Actions already provide isolation, token scoping, and an audit trail sufficient for many organisations' risk tolerance, and the marginal security gain from stage 3 may not justify the operational cost of migrating credential flows to a new platform for teams whose coding agents do not need cross-organisation tool access or multi-day session persistence; the evidence gathered here does not directly quantify that marginal benefit, so this remains a plausible but unverified competing account for slower stage-3 adoption. [inference; source: https://docs.github.com/en/codespaces/reference/security-in-github-codespaces; https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html] The independent execution-security systematisation is weighted heavily in this analysis because it directly verifies its claims against 39 source papers and four disclosed CVEs rather than describing a single vendor's own product, and it directly contradicts any framing in which reaching stage 3 alone constitutes "solved" runtime security, since its reported 69-98% policy-bypass failure rates and unaddressed TOCTOU/MCP state-validation gap are independent of isolation stage. [inference; source: https://arxiv.org/abs/2607.05743] Cursor's engineering account is treated as corroborating rather than central evidence, because it documents the stage 1-to-stage 2/3 transition from the perspective of a still-evolving proprietary platform rather than a fixed reference architecture, but its concrete reliability figures (one-nine to two-nines, 50 million actions per day) are treated as credible because they are internally reported operational metrics rather than marketing claims about competitors. [inference; source: https://cursor.com/blog/cloud-agent-lessons]

Risks, gaps, uncertainties:

The item relies on one paper (the 2607.05743 systematisation) for its central claim that policy-enforcement and access-control failures are independent of isolation stage; a second independent study measuring denylist-bypass rates specifically against stage-3 platforms such as AgentCore was not located in this session, so this claim's generality across all stage-3 implementations is not separately confirmed. Network-egress policy specific to GitHub Copilot's cloud agent running on GitHub Actions is not directly documented in the consulted sources and is carried forward only as an assumption. No independently audited cost comparison between microVM-per-session and isolate-with-container-escalation architectures was located, so the economic trade-off between AWS's and Cloudflare's stage-3 approaches rests on each vendor's own stated rationale rather than a neutral benchmark. Firecracker's documented startup-latency and density figures are generic to the technology rather than measured specifically for AgentCore coding-agent sessions. Cloudflare's @cloudflare/computer runtime is explicitly described as an early preview not recommended for production use at the time this item's sources were consulted, so its architecture is documented as a design intent rather than as production-proven behaviour at the scale AgentCore has already demonstrated. This item did not locate a primary source quantifying GitHub Copilot cloud agent's own session concurrency limits, cost per session, or startup latency, so a direct numeric comparison of latency and cost across all three named stages could not be completed; the comparison in this item is therefore qualitative for GitHub's products and quantitative only where AWS and Firecracker publish specific figures.

Open questions:

What network-egress controls does GitHub Copilot's cloud agent apply by default on its GitHub Actions-backed runners, and how do they compare to Codespaces' documented firewall behaviour? What is the measured concurrency limit, per-session cost, and startup latency for GitHub Copilot's cloud agent, and how do these compare directly to AgentCore Runtime and Cloudflare's isolate architecture under equivalent coding-agent workloads? Does any published, adversarially tested benchmark exist comparing policy-enforcement bypass rates specifically across stage-3 platforms (AgentCore Policy service, Cloudflare's architecture, and competing offerings) using the same denylist-bypass methodology reported in the 2607.05743 systematisation? Once Cloudflare's @cloudflare/computer runtime exits preview, does its production isolation and reliability profile match the design rationale described in its announcement post?

§7 Recursive Review

review_result: pass
sections_justified: all sections (§0-§6) contain substantive, source-bound content; no placeholder headings remain
claims_sourced: every factual and inferential claim in §2 through §6 carries an epistemic label and at least one URL-backed source
acronym_audit: passed (AI, OS, CI, Application Programming Interface not yet used, CLI, MCP, RAG not used, KVM, PAT, TOCTOU, CVE, PTY, VPN, IP, AWS, IDE, OSS, LLM, IdP not used directly, RFC, S3 abbreviated on first use with expansion)
parity_check: passed; §6 Synthesis and Findings below are mirrored with identical wording per claim
open_items: three assumptions carried forward with justification (GitHub Actions egress policy; isolate-vs-microVM cost trade-off; Firecracker benchmark generalisation); five open questions surfaced for potential follow-up backlog items

Findings

Executive Summary

Coding-agent runtime design progresses through three architecturally distinct stages, each defined by a different combination of isolation strength, credential-delegation granularity, and harness-sandbox separation, and the transition between stages is driven by documented multi-agent concurrency and credential-exposure failures rather than by a single security principle alone. [inference; source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/; https://docs.github.com/en/codespaces/reference/security-in-github-codespaces] Local process/Operating System (OS) sandboxes (stage 1) rely on process-level constraints and share the developer's credentials, network, and machine resources across every agent running there. [fact; source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/; https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e] Shared Continuous Integration (CI)/cloud development infrastructure (stage 2, exemplified by GitHub Copilot's cloud agent on GitHub Actions and GitHub Codespaces) introduces per-session virtual machines or ephemeral runners and permission-scoped tokens, but reuses security controls built for general-purpose CI and cloud-Integrated Development Environment (IDE) products rather than agent-specific threats. [fact; source: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent; https://docs.github.com/en/codespaces/reference/security-in-github-codespaces] Purpose-built multi-tenant platforms (stage 3, exemplified by Amazon Web Services (AWS) Bedrock AgentCore Runtime and Cloudflare's isolate/container hybrid) introduce per-session hardware-virtualized or isolate-level isolation and a distinct credential-mediation layer separate from the agent loop, but stage 3 itself splits into at least two competing architectures optimising isolation-per-session against horizontal cost efficiency at scale. [inference; source: https://blog.cloudflare.com/cloudflare-computer/; https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/] Independent execution-security research confirms the harness-sandbox separation pattern but identifies policy-enforcement and access-control failure rates of 69% to 98% against real-world denylists that stronger isolation alone does not resolve. [fact; source: https://arxiv.org/abs/2607.05743] This means the runtime-evolution progression documented in this item addresses one threat class (isolation strength) while leaving a second, largely unaddressed class of vulnerability (policy enforcement and access control) that the cited systematisation identifies but does not itself frame in terms of runtime-stage progression. [inference; source: https://arxiv.org/abs/2607.05743]

Key Findings

Local coding-agent execution shares the developer's shell, filesystem, loaded credentials, and network interface with the agent process because there is no separate execution boundary, and the standard mitigation for running multiple local agents in parallel, git worktree, isolates only the working directory while leaving port bindings, SSH keys, and outbound network identity shared across all agents on the host. ([fact]; medium confidence; source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)
GitHub Copilot's cloud agent runs in an ephemeral development environment powered by GitHub Actions, marking the first architectural point at which agent-loop logic and execution environment are handled by different systems, though the underlying runner security model was designed for general Continuous Integration (CI) workloads rather than for agentic execution specifically. ([fact]; medium confidence; source: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent; https://docs.github.com/en/actions/reference/security/secure-use)
GitHub Codespaces isolates each session on its own newly built virtual machine with a firewalled network blocking inbound and cross-codespace traffic, and scopes the session's GitHub token to read-only, read/write, or automatic-fork access strictly according to the underlying user's own repository permissions. ([fact]; medium confidence; source: https://docs.github.com/en/codespaces/reference/security-in-github-codespaces)
Amazon Bedrock AgentCore Runtime gives every coding-agent session a dedicated Firecracker microVM with a persistent workspace directory that survives suspension and resumption for up to 14 days of inactivity, replacing hand-built persistence workarounds such as S3 syncing or Git-bundle checkpointing that engineering teams have historically built themselves. ([fact]; medium confidence; source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)
AgentCore separates credential handling from the agent loop entirely through a Gateway-and-Identity layer implementing three distinct least-privilege patterns (bot, on-behalf-of using OAuth 2.0 Token Exchange under RFC 8693, and broker), so that downstream service tokens for tools such as GitHub, Jira, and Slack are never held directly by the agent process. ([fact]; medium confidence; source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)
Cloudflare's competing purpose-built architecture defaults every agent session to a lightweight isolate rather than a dedicated microVM or container, escalating to a full container sandbox only for the minority of operations needing native binaries or heavier compute, arguing that container-per-agent isolation cannot scale to hundreds of millions or billions of concurrent agent sessions industry-wide. ([fact]; medium confidence; source: https://blog.cloudflare.com/cloudflare-computer/)
Firecracker's underlying microVM technology starts application code in as little as 125 milliseconds, supports up to 150 microVM creations per second per host, and runs each microVM with under 5 mebibytes of memory overhead, which is the technical basis making per-session hardware-virtualized isolation practical at the density stage-3 platforms require. ([fact]; medium confidence; source: https://firecracker-microvm.github.io/)
A peer-reviewed systematisation of 39 execution-security papers published between 2023 and 2026 found that policy-enforcement mechanisms in the reviewed literature fail against real-world denylists at rates from 69% to 98%, that no isolation paper in the corpus re-evaluated its own defense under that same adversarial condition, and that benign but out-of-scope agent actions occur at rates up to 17.1% under realistic prompting without being addressed by any access-control paper reviewed. ([fact]; medium confidence; source: https://arxiv.org/abs/2607.05743)
The same systematisation treats Time-Of-Check-To-Time-Of-Use (TOCTOU) races and Model Context Protocol (MCP) threats as one underlying state-validation problem rather than separate literatures, implying that stronger runtime isolation, the stage-3 focus of this item, leaves this class of vulnerability, along with the policy-bypass and dishonest-policy-author gaps, substantially unaddressed regardless of which isolation stage a platform has reached. ([inference]; medium confidence; source: https://arxiv.org/abs/2607.05743)
Migrating a coding-agent runtime from a developer's local machine to shared or purpose-built cloud infrastructure introduces new reliability failure modes not present locally, illustrated by Cursor's own account of moving from roughly one-nine to past two-nines reliability only after adopting a durable-execution workflow engine to survive inference-provider outages, pod replacement, and multi-day task runs. ([fact]; medium confidence; source: https://cursor.com/blog/cloud-agent-lessons)
An independently compiled survey of coding-agent sandbox implementations documents four distinct isolation tiers actually deployed across production tools, ranging from OS-level primitives used by local Command Line Interface (CLI) agents such as Codex CLI, through userspace-kernel interception and microVM runtimes, to hardened container runtimes used by providers like Daytona, confirming that "purpose-built platform" spans multiple isolation technologies rather than one standard implementation across the industry. ([fact]; medium confidence; source: https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e)
A separate line of research shows that the presence of a code-execution sandbox environment itself, independent of execution-security architecture, measurably improves large language model (LLM) task performance by up to 15.5% while cutting token consumption up to 8 times, indicating that investment in richer coding-agent runtimes serves a capability objective as well as a security objective. ([fact]; medium confidence; source: https://arxiv.org/abs/2601.16206)

Evidence Map

Claim	Source	Confidence	Notes
[fact] Local agents share shell, filesystem, credentials, network with developer; no separate execution boundary	https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/	medium	Vendor engineering post; corroborated qualitatively by sandbox survey
[fact] `git worktree` isolates only working directory, not host resources/credentials	https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/	medium	Single source; architecturally uncontroversial claim about git
[fact] Local CLI agents use Landlock/Seatbelt/seccomp OS primitives, not virtualization	https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e	medium	Independently compiled community list; not a vendor's own claim about itself
[fact] Copilot cloud agent runs in ephemeral GitHub Actions-powered environment	https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent	medium	Primary vendor documentation
[fact] GitHub Actions: `GITHUB_TOKEN` should default read-only; `pull_request_target`/`workflow_run` privileged	https://docs.github.com/en/actions/reference/security/secure-use	medium	Primary vendor security guidance
[fact] Codespaces: isolated VM and network per session; token scoped to user's repo permissions	https://docs.github.com/en/codespaces/reference/security-in-github-codespaces	medium	Primary vendor documentation
[fact] AgentCore Runtime gives each session a dedicated Firecracker microVM with persistent workspace (14-day retention)	https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/	medium	Vendor engineering post; corroborated by AWS devguide service description
[fact] AgentCore modular services: Runtime, Gateway, Identity, Memory, Policy, etc.	https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html	medium	Primary vendor documentation
[fact] AgentCore Identity: bot, on-behalf-of (RFC 8693), and broker credential patterns	https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/	medium	Vendor engineering post with code examples
[fact] Cloudflare defaults to isolates, escalates to container only when needed; container-per-agent does not scale globally	https://blog.cloudflare.com/cloudflare-computer/	medium	Single vendor source describing its own new (preview-stage) product; not independently benchmarked
[fact] Firecracker: 125ms startup, 150 microVMs/sec/host, <5MiB overhead	https://firecracker-microvm.github.io/	medium	Primary project documentation; exact benchmark hardware not specified
[fact] 69-98% policy-enforcement denylist bypass rates; 17.1% benign out-of-scope actions; TOCTOU/MCP as one state-validation gap	https://arxiv.org/abs/2607.05743	medium	Peer-reviewed/preprint systematisation of 39 papers with direct source verification per the abstract
[fact] Cursor: one-nine to two-nines reliability after adopting Temporal; 50M+ actions/day, 40%+ PRs from cloud agents	https://cursor.com/blog/cloud-agent-lessons	medium	Vendor engineering post with specific operational metrics
[fact] Four-tier sandbox taxonomy (OS-level, application kernel, microVM, container) across real coding-agent products	https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e	medium	Independently compiled community source, not peer-reviewed
[fact] Minimal sandbox environment alone improves LLM task performance up to 15.5%, reduces tokens up to 8x	https://arxiv.org/abs/2601.16206	medium	Single peer-reviewed/preprint paper; not yet cross-validated by a second independent study in this item

Assumptions

GitHub Actions runners used for Copilot's cloud agent are assumed to apply network-egress restrictions comparable to those documented for Codespaces during agent-driven jobs. [assumption; source: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent] The consulted GitHub documentation describes the ephemeral runner environment and token permission model but does not itself state a default outbound network policy specific to Copilot cloud agent sessions, so this assumption fills a documented gap rather than restating a directly sourced claim. [assumption; source: https://docs.github.com/en/actions/reference/security/secure-use]

The cost-per-session of Cloudflare's isolate-first architecture is assumed to be lower than AWS's microVM-per-session architecture at comparable coding-agent workload scale. [assumption; source: https://blog.cloudflare.com/cloudflare-computer/] Neither vendor publishes a directly comparable cost benchmark for equivalent coding-agent sessions, so this assumption is inferred from each vendor's own stated design rationale for choosing its respective default execution primitive rather than from a measured, independently audited comparison. [assumption; source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/]

Firecracker's published 125 millisecond startup and 150-per-second creation-rate figures are assumed to be broadly representative of AgentCore's own coding-agent session start times. [assumption; source: https://firecracker-microvm.github.io/] The Firecracker project documentation does not specify the benchmark hardware or workload configuration used to obtain these figures, and AWS's AgentCore-specific engineering post does not restate a session-start-time figure of its own, so this assumption bridges a generic-technology benchmark to a specific product's claimed behaviour. [assumption; source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/]

Analysis

The evidence supports treating isolation strength as increasing across the three named stages for the specific products examined (GitHub, AWS, Cloudflare), but the strength of that claim is bounded by the small number of platforms directly consulted rather than a comprehensive market census. [inference; source: https://gist.github.com/wincent/2752d8d97727577050c043e4ff9e386e] Weighing the AWS AgentCore evidence against the Cloudflare evidence required resolving an apparent tension: Cloudflare's isolate-first default could look like weaker isolation than a dedicated microVM per session, but Cloudflare directly attributes this design choice to horizontal scalability rather than to accepting a weaker security posture, and both platforms represent a stronger, more granular isolation boundary than the shared-VM or shared-runner model documented for GitHub Actions and Codespaces. [inference; source: https://blog.cloudflare.com/cloudflare-computer/; https://docs.github.com/en/codespaces/reference/security-in-github-codespaces] A plausible rival explanation for why some teams remain at stage 2 rather than adopting a stage-3 platform is that GitHub Codespaces and Actions already provide isolation, token scoping, and an audit trail sufficient for many organisations' risk tolerance, and the marginal security gain from stage 3 may not justify the operational cost of migrating credential flows to a new platform for teams whose coding agents do not need cross-organisation tool access or multi-day session persistence. [inference; source: https://docs.github.com/en/codespaces/reference/security-in-github-codespaces; https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html] The evidence gathered here does not directly quantify that marginal benefit, so this remains a plausible but unverified competing account for slower stage-3 adoption. [assumption; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html] The independent execution-security systematisation is weighted heavily in this analysis because it directly verifies its claims against 39 source papers and four disclosed Common Vulnerabilities and Exposures (CVEs) rather than describing a single vendor's own product, and it directly contradicts any framing in which reaching stage 3 alone constitutes "solved" runtime security, since its reported 69-98% policy-bypass failure rates and unaddressed TOCTOU/MCP state-validation gap are independent of isolation stage. [inference; source: https://arxiv.org/abs/2607.05743] Cursor's engineering account is treated as corroborating rather than central evidence, because it documents the stage 1-to-stage 2/3 transition from the perspective of a still-evolving proprietary platform rather than a fixed reference architecture, but its concrete reliability figures are treated as credible because they are internally reported operational metrics rather than marketing claims about competitors. [inference; source: https://cursor.com/blog/cloud-agent-lessons]

Risks, Gaps, and Uncertainties

The item relies on one paper for its central claim that policy-enforcement and access-control failures are independent of isolation stage; a second independent study measuring denylist-bypass rates specifically against stage-3 platforms such as AgentCore was not located in this session, so this claim's generality across all stage-3 implementations is not separately confirmed. [assumption; source: https://arxiv.org/abs/2607.05743]

Network-egress policy specific to GitHub Copilot's cloud agent running on GitHub Actions is not directly documented in the consulted sources and is carried forward only as an assumption rather than a confirmed control. [assumption; source: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent]

No independently audited cost comparison between microVM-per-session and isolate-with-container-escalation architectures was located, so the economic trade-off between AWS's and Cloudflare's stage-3 approaches rests on each vendor's own stated rationale rather than a neutral benchmark. [assumption; source: https://blog.cloudflare.com/cloudflare-computer/; https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/]

Firecracker's documented startup-latency and density figures are generic to the technology rather than measured specifically for AgentCore coding-agent sessions. [assumption; source: https://firecracker-microvm.github.io/]

Cloudflare's @cloudflare/computer runtime is explicitly described as an early preview not recommended for production use at the time this item's sources were consulted, so its architecture is documented as a design intent rather than as production-proven behaviour at the scale AgentCore has already demonstrated. [fact; source: https://blog.cloudflare.com/cloudflare-computer/]

This item did not locate a primary source quantifying GitHub Copilot cloud agent's own session concurrency limits, cost per session, or startup latency, so a direct numeric comparison of latency and cost across all three named stages could not be completed. [assumption; source: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent]

Open Questions

What network-egress controls does GitHub Copilot's cloud agent apply by default on its GitHub Actions-backed runners, and how do they compare to Codespaces' documented firewall behaviour?

What is the measured concurrency limit, per-session cost, and startup latency for GitHub Copilot's cloud agent, and how do these compare directly to AgentCore Runtime and Cloudflare's isolate architecture under equivalent coding-agent workloads?

Does any published, adversarially tested benchmark exist comparing policy-enforcement bypass rates specifically across stage-3 platforms (AgentCore Policy service, Cloudflare's architecture, and competing offerings) using the same denylist-bypass methodology reported in the Balkanization systematisation?

Once Cloudflare's @cloudflare/computer runtime exits preview, does its production isolation and reliability profile match the design rationale described in its announcement post?

Output

Type: knowledge
Description: A three-stage runtime-evolution model for AI coding-agent execution security (local process/OS sandbox, shared CI/cloud development infrastructure, purpose-built multi-tenant platform), mapping isolation strength, least privilege, harness-sandbox separation, persistence, and egress control to concrete implementations at each stage, and identifying that stronger isolation alone does not resolve the documented 69-98% policy-enforcement bypass rate independent of runtime stage. [inference; source: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/; https://arxiv.org/abs/2607.05743]
Links: https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/ ; https://arxiv.org/abs/2607.05743 ; https://docs.github.com/en/codespaces/reference/security-in-github-codespaces