Evidence-linked trend hypothesis
Agent security moves to runtime boundaries
Agent security is moving beyond prompt policy into execution isolation, scoped identity, tool controls, memory hygiene, approval gates, and auditable runtime behavior.
Current thesis
The durable security boundary for an agent is the runtime that constrains what it can read, remember, execute, and authorize, not the prompt that asks it to behave. Confidence: high. Supported by 26 normalized raw signals. This New Runtime record is an evidence-linked retrieval unit.
Source ledger
Publishable sources attached to this record.
| # | Source | Role | Public status |
|---|---|---|---|
| 1 | openai.comsource | primary receipt | source_urls |
| 2 | manus.imsource | supporting receipt | source_urls |
| 3 | blog.lukaszolejnik.comarticle | supporting receipt | source_urls |
| 4 | blog.palantir.comarticle | supporting receipt | source_urls |
| 5 | openai.comsource | supporting receipt | source_urls |
Showing 5 of 10; the complete set is exposed in the JSON route.
Current state, as of Oct 13, 2026
Where this stands now
strengthening The runtime-boundary view is reinforced by recent examples: on October 5, GitHub described local sandboxing for Copilot commands, and Microsoft outlined controls in a Windows execution layer. These show runtime controls becoming concrete, though their effectiveness still needs testing.
Agent security is being addressed through execution environments and interfaces: GitHub describes local sandboxing for Copilot commands, while Microsoft outlines agent controls and on-device model support in a controlled Windows execution layer. Recent examples also include access-control APIs and layered runtime defenses.
This reinforces the view that prompts alone cannot enforce what an agent may read, execute, or authorize. Builders should still test whether controls such as nearby proxies can be bypassed, scope credentials, and keep evidence of completion and accountable review outside the executor.
What changed since the original text
- GitHub and Microsoft described runtime controls for agent execution, including local sandboxing for Copilot commands and a controlled Windows execution layer. 1
- Modal Sidecars put a trust boundary beside sandboxed workloads, but the update explicitly leaves bypass resistance to testing. 2
- Mem0, Google, and AWS releases place access controls on runtime interfaces; OpenAI and Anthropic examples also describe execution-environment defenses. 3
- Archive guidance emphasizes keeping completion evidence and accountable review outside the agent executor. 4
Open questions
- Can agents bypass nearby proxies or other runtime controls in practice?
- How consistently do these controls constrain credentials, network access, and actions across products?
- What independent evidence demonstrates that completion checks and review remain outside the executor in deployed systems?
Watch next: Watch for independent testing showing whether deployed runtime controls prevent agents from bypassing proxies or exceeding their granted authority.
- Weekly update: GitHub and Microsoft detail runtime controls for agent execution update, Oct 5, 2026
- Weekly update: Modal Sidecars put a trust boundary beside sandboxed workloads update, Sep 28, 2026
- Weekly update: New runtime controls and tool‑access APIs reinforce agents’ security boundary at the runtime level update, Sep 21, 2026
- When Proof Leaves the Executor archive
Rewritten automatically by the New Runtime knowledge desk from this record's weekly updates, releases and archive. The original text below is kept as written (Oct 21, 2025); where the two disagree, this section is newer.
Weekly knowledge desk
Weekly updates
3 reviewed updates to this pattern, newest first. Every update is checked against its evidence before it changes the record.
GitHub and Microsoft detail runtime controls for agent execution
GitHub describes local sandboxing that restricts the execution context for Copilot commands. Microsoft outlines agent controls and on-device model support as part of a controlled Windows execution layer. These independent examples support the record’s emphasis on runtime boundaries rather than prompt behavior.
Modal Sidecars put a trust boundary beside sandboxed workloads
Modal’s Sidecars place a trust boundary next to the workload, and the analysis cautions that builders must test whether agents can bypass a nearby proxy. Cloudflare OS is also described as offering isolated, user-specific apps and service-level controls, though its public release is not evidence of production security. These items provide concrete examples of runtime controls while leaving their effectiveness conditional.
- Sidecars: A low-latency trust boundary for Sandboxes post, Oct 2, 2026
- A nearby proxy is useful only if agents cannot route around it analysis, Oct 2, 2026
- Cloudflare OS treats agent permissions as a product problem analysis, Oct 4, 2026
New runtime controls and tool‑access APIs reinforce agents’ security boundary at the runtime level
Recent releases such as Mem0’s Gateway, Google’s Files and Credentials APIs, and AWS’s Bedrock Guardrails extension all place access controls on the runtime interfaces that agents use, rather than relying on prompt‑only policies. OpenAI’s shutdown of a compromised training container and Anthropic’s layered runtime defenses further illustrate that durable security is being enforced through the execution environment. These developments provide concrete instances that the security boundary for agents is defined by the runtime that governs what they can read, execute, and authorize.
- Mem0 launches Gateway to give agents scoped keys for tools signal, Sep 24, 2026
- Google upgrades Gemini managed agents with Files and Credentials APIs post, Sep 24, 2026
- Extend Amazon Bedrock Guardrails to Tool Interactions Using the Strands Agents SDK external, Sep 28, 2026
- Research acceleration: The view inside OpenAI external, Sep 28, 2026
- Improving our alignment and security practices external, Sep 28, 2026
What is changing
Agents are gaining browsers, shells, files, credentials, memory, and the ability to call external services. The resulting risk is not confined to malicious input. It also appears in poisoned skills, stale memory, over-broad credentials, unsafe command composition, and an approval flow that hides the real effect of an action.
The response is increasingly architectural. Sandboxes isolate execution. Lockdown modes reduce available capabilities for high-risk sessions. Hooks and policy engines inspect commands at the point of use. Scoped identity and audit records make the runtime responsible for proving what happened.
What the archive adds
- Aardvark, ClawKeeper, and related security work treat agent-produced code and infrastructure as a continuously inspected attack surface.
- Manus Sandbox, CubeSandbox, and sandboxed migration examples move isolation into the normal execution path rather than reserving it for exceptional jobs.
- Skill-worm research shows why portable capability packages need provenance, review, and containment before execution.
- Production guidance from Palantir and OpenAI connects permissions, elevated risk states, and auditability to the runtime boundary.
Operational consequence
An agent runtime should start from least privilege, separate read and write capabilities, isolate untrusted code, make network and credential access explicit, and return an audit identifier for every material action. Prompts remain part of defense in depth, but they cannot be the enforcement layer.
September 2026 update
What changed
Governed computer-use work treats credentials and sandboxing as execution concerns. A reported DNS egress bypass makes the complementary point: one network filter is not a complete control plane. New enterprise-control announcements further center runtime governance.
Operational consequence
Start with least privilege; separate read, write, and credential access; isolate untrusted execution; require visible approval for material effects; and retain an auditable trace. Prompts remain defense in depth, never the enforcement layer.