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?

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. 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. 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. 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. 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. 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.

Key Findings

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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.
10. 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.
11. 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.
12. 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.

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. 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.

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. 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.

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. 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.

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. 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. 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. 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. 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.

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.

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.

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.

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?

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:

• [Smith et al. (YYYY) Title of paper](Organisation Title, for papers with named authors

• [Organisation Title](Organisation Title, for documentation, standards, or pages without a named author

• [x] Shao et al. (2026) The Balkanization of Execution-Security Research for AI Coding Agents: taxonomy and threat framing for coding-agent execution security. Note: arXiv metadata lists the author as Mohammadreza Rashidi, not "Shao et al." as in the original seed entry; the paper is the same one referenced by the seeded arXiv identifier.

• [x] Cheng et al. (2026) Computer Environments Elicit General Agentic Intelligence in LLMs: environment design as a capability and evaluation variable.

• [x] Cloudflare: Your agent needs a computer, not a container: argument and design framing for execution environments. Note: original seeded URL slug (your-agent-needs-a-computer-not-a-container) 404s; the live post is at the cloudflare-computer slug.

• [x] GitHub Docs: About GitHub Copilot cloud agent: cloud-agent execution model context and controls. Note: GitHub renamed "Copilot coding agent" to "Copilot cloud agent"; the seeded URL redirects here.

• [x] GitHub Docs: Secure use reference for GitHub Actions: shared-infrastructure security controls and constraints. Note: seeded URL (security-hardening-for-github-actions) redirects here under GitHub's reorganised Actions documentation.

• [x] GitHub Docs: Security in GitHub Codespaces: cloud development-environment isolation and access controls.

• [x] AWS Bedrock AgentCore product page: platform positioning and component overview.

• [x] AWS Docs: What is Amazon Bedrock AgentCore?: managed harness/runtime capability reference.

• [x] AWS Machine Learning (ML) Blog: It's safe to close your laptop now: Hosting coding agents on Amazon Bedrock AgentCore: production runtime narrative and architecture details.

• [x] Amazon Bedrock AgentCore Samples (GitHub): concrete runtime/harness implementation examples. Note: original seeded URL (amazon-bedrock-agentcore-samples) redirects to this renamed repository.

• [x] Coding Agent Sandboxes: Comprehensive List (GitHub Gist, compiled 2026): comparative landscape of coding-agent sandbox providers and isolation primitives. Replacement source: the originally seeded uknighted/awesome-ai-coding-sandboxes repository returns Hypertext Transfer Protocol (HTTP) status 404 (deleted or renamed); this gist compiles the same category of source lists (restyler/awesome-sandbox, webcoyote/awesome-AI-sandbox, bureado/awesome-agent-runtime-security) and was verified accessible in this session.

• [x] Firecracker Documentation: microVM isolation and performance primitives used in agent-runtime discussions.

• [x] Cursor: What we've learned building cloud agents: public engineering notes on cloud coding-agent environment, reliability, and orchestration design. Note: original seeded URL (cursor.com/blog) is the blog index page, not a specific article; this is the directly relevant post found via search.