Files

T

didericis-claude 727eafe0f9 docs(research): clarify prompt injection framing and blast-radius risks

Collapse "trusted-channel data injection" into prompt injection
throughout — the trusted channel is a delivery vector, not a distinct
attack class. Add explicit inbound/outbound orthogonality framing.
Replace the two redundant "weaker" bullets with a single prompt
injection section and a new blast-radius breakdown covering work
product corruption, malicious commits past gitleaks, exfiltration
through allowlisted channels, and dependency-install injection.

2026-07-18 18:13:33 +00:00

16 KiB

Raw Blame History

HN discourse on agent sandbox safety — June/July 2026

A survey of community opinion and notable security disclosures on Hacker News and adjacent sources over June–July 2026. The question: what does the current discourse say about whether sandboxes are sufficient for agentic AI safety, and where does bot-bottle land against the issues being raised?

Research conducted 2026-07-18.

Summary

The past month marks a turning point in community opinion. Earlier in 2026, the debate was mostly "which sandbox tool is best?" By June–July, a cascade of critical CVEs and novel attack classes has shifted the framing to "sandboxes are not enough — what else do you need?" The attacks that drove this shift are structurally distinct: most route through legitimate, trusted channels (Sentry issues, MCP descriptions, README files) rather than exploiting the isolation boundary directly.

bot-bottle's architecture holds up well against the direct-escape class (Firecracker/Apple Container default backends, credentials never in the agent's env, harness entirely on the host). The remaining gap is prompt injection — attacker-controlled data interpreted as model instructions. Egress controls and prompt injection defenses are orthogonal: egress limits what the agent can send out; injection is about what it is told to do. The two don't substitute for each other. Inside a tightly- egressed sandbox a successful injection can't exfiltrate to unknown hosts, but it can still corrupt the work product, push malicious commits past a secret scanner, or use allowlisted channels for exfiltration. Those residual risks are addressed below.

The sandboxing boom sets the stage

The preceding months generated a wave of sandbox tooling. A March 28 Ask HN thread (#47444917) catalogued the explosion: E2B, AIO Sandbox, AgentSphere, Yolobox, Exe.dev, AgentFence, DenoSandbox, Capsule (WASM), ERA, Vibekit, Daytona, Modal, Nono, and more — all launched within roughly 12 months. A parallel March 9 thread (#47185250) surveyed what developers were actually deploying: "containers or YOLO" dominated. The honest community mood was that most teams hadn't solved this and were shipping anyway.

The June–July attack cascade

Six attack patterns broke in quick succession. Together they form the argument that the community's framing was wrong: the threat model for agents isn't just "code that escapes its container" — it's also prompt injection, where attacker-controlled data is interpreted as model instructions regardless of whether any isolation boundary was crossed. Sections 2–4 below are all the same attack class; the "trusted channel" label describes the delivery vector, not a different threat.

1. Sandbox escape CVEs (DuneSlide, CVE-2026-39861)

Cato AI Labs disclosed DuneSlide (CVE-2026-50548/50549, CVSS 9.8), a pair of flaws in Cursor 2.x. CVE-2026-50548 abuses the sandbox's working_directory parameter to point writes at system files; CVE-26-50549 exploits a symlink-resolution fallback that fails open. Both start with a prompt injection and end in sandbox escape — and Cato's framing was blunt: "each CVE defeats a different guardrail; the problem is structural, not a string of one-offs."

Claude Code's own sandbox had a similar escape this year: CVE-2026-39861 (symlink flaw). The CurXecute/MCPoison/CVE-2026-26268 chain from Cursor added a poisoned Slack message, a swap-after-approval MCP config, and a Git hook as three more entry points in the same attack class.

All patched, but the pattern holds: any application-level sandbox that takes attacker-influenced values as path parameters is reachable from a prompt injection.

2. Prompt injection via MCP data (Agentjacking)

Tenet's "Agentjacking" technique planted a fake bug report in Sentry's MCP output. When an agent queries Sentry to fix open issues, the malicious event is rendered as structured content visually indistinguishable from a real Sentry event, and the agent executes the embedded instructions with the developer's full privileges. Hit rate across Claude Code and Cursor: 85%. The route is entirely through a legitimately-authorized MCP channel — no isolation boundary is crossed; the injection arrives inbound through a channel the sandbox explicitly trusts.

The Cloud Security Alliance's summary: treat observability, bug-report, and integration data as untrusted agent input, not neutral development metadata.

3. README-embedded prompt injection

A July disclosure showed malicious instructions hidden in README.md — a file that receives no trust prompt and requires no elevated access. When asked point-blank whether the repo held hidden instructions, both Claude Sonnet 4.6 and GPT-5.5 said no. A payload written for Sonnet 4.6 transferred unchanged to Sonnet 5, Opus 4.8, and GPT-5.5. The attack surface is every repo an agent is asked to work in.

4. Prompt injection via MCP tool descriptions

Microsoft research (June 30) showed that attacker-controlled MCP tool description fields can silently redirect agent behavior. The injection is embedded in metadata the model reads during tool selection — before any sandbox enforcement or egress check runs, and entirely on the inbound path that egress controls cannot touch.

5. MCP STDIO command injection (10 CVEs)

OX Security disclosed a systemic command injection class in Anthropic's MCP protocol, covering 10 CVEs across multiple coding agents. The Windsurf case (CVE-2026-30615): processing attacker-controlled HTML causes the agent to auto-register a malicious MCP STDIO server and execute arbitrary commands with no further user interaction.

6. LiteLLM gateway compromise (CVE-2026-40217, CVE-2026-42271)

CVE-2026-40217 exposes LiteLLM's guardrail sandbox via exec() with no source filtering. CVE-2026-42271 (exploited in the wild, added to CISA's KEV catalog) lets callers spawn subprocesses through MCP preview endpoints. The threat extends to any agent routed through a compromised LiteLLM proxy: the proxy can swap model responses for forged tool calls in transit, giving the attacker a reverse shell from the developer's machine.

HN community opinion clusters

"Move enforcement to the kernel, not the app" — the Nono Show HN (#46849615) and a kernel-sandbox thread (#47066574) both argued that application-layer sandboxes are inherently bypassable by the code they're sandboxing. The academic framing, from Red-Teaming the Agentic Red-Team (arXiv 2606.24496): "enforcement should occur at the OS level via the kernel refusing system calls that violate policy at runtime — not pre-execution argument validation in tool calls."

"The harness belongs outside the sandbox" — a May thread (#47990675) converged on clean architectural separation: harness in one VM, tool execution in another. Top comment: "having the harness in one VM, and tool use applied to user data in another, is about as safe as you can be at present." Several replies described a hypervisor-like policy layer — sitting outside both VMs — as the right long-term model.

"Sandboxes are too coarse-grained" — a Feb thread (#47006445) argued that VMs don't answer the real question: knowing whether an agent should be sending an email or making a transaction. "Everything's just in the same big box." This framing picked up traction through June–July as the trusted-channel attacks dominated.

"MCP's trust model is the real problem" — the month's recurring theme. MCP by design gives agents access to authorized external services. Once a trusted channel delivers a malicious payload, filesystem sandboxing is irrelevant. The community call: treat all MCP tool metadata and return values as untrusted input subject to policy validation before ingestion, and disable automatic MCP server loading from untrusted repositories.

How bot-bottle addresses these issues

What it covers well

Direct sandbox escape (CVEs, container breakout)

bot-bottle's default backends are Firecracker microVM (KVM Linux) and Apple Container (macOS). Both run the agent in a separate VM with a dedicated kernel — the container-escape CVE class (Dirty Pipe, runc escapes, DuneSlide's path-parameter abuse) requires escaping a real hypervisor boundary, not just a namespace. On the legacy Docker backend, gVisor auto-detection provides a userspace syscall barrier for hosts where neither KVM nor Apple Container is available.

The bot-bottle process itself runs entirely on the host, outside the VM. This is the "harness outside the sandbox" architecture the HN thread converged on as best practice. The bottle manifest, egress rules, and secrets never enter the agent VM.

Credential theft on sandbox escape

Even on a successful VM/container escape, the agent has nothing useful to steal. Credentials are injected in-flight by the gateway proxy (auth.scheme / auth.token_ref in the egress route config) — printenv inside the agent shows proxy URLs only. The git-gate similarly holds the upstream SSH credential on the host; the agent pushes through a gitleaks-scanned daemon that forwards clean refs upstream. An escaped agent gets the host filesystem, not the keys.

Orphaned-agent credential risk

bot-bottle is explicitly ephemeral: when the agent exits, cli.py tears down every gateway and both networks — nothing persists between runs. The agent never holds credentials, so there is nothing to orphan.

MCP config redirection / STDIO auto-registration

The trust boundary at $HOME means bottles live only under ~/.bot-bottle/bottles/ — a cloned repo cannot add egress routes or redirect env vars to attacker hosts (the design rationale is in docs/prds/0011-per-file-md-manifest.md). Auto-registering a malicious MCP STDIO server from within the agent is still sandboxed by the VM, and any outbound calls from that server must pass the egress allowlist and outbound DLP scanner.

Outbound exfiltration (any injection class)

Whatever triggers the agent — README injection, Agentjacking, MCP description poisoning — the final step in most attacks is exfiltration. bot-bottle's egress allowlist is default-deny with a per-bottle host allowlist; unknown hosts get a hard 403. Outbound DLP scanning (outbound_detectors: [token_patterns, known_secrets]) catches tokens and secrets in outbound bodies; the supervise policy (default for manifest routes) holds the request for operator approval rather than silently blocking it. Together these limit what a successful injection can do even if it succeeds at the model layer.

LiteLLM / compromised-proxy attacks

bot-bottle does not use LiteLLM. The model API route (e.g. api.anthropic.com) is an auto-injected provider route on the egress allowlist; the agent dials the gateway, not the model API directly. A compromised third-party proxy is not in the architecture.

Where it is weaker

Prompt injection

Egress controls and prompt injection defenses are orthogonal. Egress limits what the agent can send out (outbound leg); prompt injection is about what attacker-controlled data tells the agent to do (inbound leg). The two don't substitute for each other and must be treated separately.

The inbound DLP scanner (inbound_detectors: [naive_injection_detection]) is the only runtime defense against injection arriving through allowlisted channels — Sentry MCP responses, MCP tool descriptions, README content. It is explicitly pattern-matching and will not catch a sufficiently crafted payload. There is no semantic / intent-level gate between what the model decides and what the agent executes.

Blast radius within the permitted scope

Inside a tightly-egressed sandbox a successful injection can't exfiltrate to unknown hosts, but it still has real options:

Work product corruption. The agent can modify, delete, or backdoor files in the working directory. This is within its permitted scope; egress controls have nothing to say about it.
Malicious commits past the git-gate. The git-gate scans outbound refs for secrets (gitleaks), not for semantic code intent. A prompt- injected agent can commit subtly malicious code — logic bombs, backdoored auth paths, code that exfiltrates data through the application's own HTTP clients at runtime — that looks clean to a secret scanner.
Exfiltration through allowlisted channels. If an attacker knows or can predict what hosts are in the egress allowlist, those channels are available for exfiltration. A GitHub remote being allowlisted means "push to an attacker-controlled fork" is viable. A logging endpoint being allowlisted means structured data can leave through it. The outbound DLP scanner catches credential tokens and known secrets but not arbitrary business data.
Dependency installation within the sandbox. An agent that runs npm install or pip install on attacker-specified packages executes code inside the sandbox with the same capabilities the agent has: filesystem access, tool calls, calls to allowlisted hosts. Supply chain injection via package names is in the same injection family, triggered by the same prompt-injection path.

What would close the remaining gaps

The blast-radius risks above point at two distinct mitigations that don't yet exist in bot-bottle:

Outbound intent classification. The egress addon today scans outbound request content for token patterns. What it lacks is awareness of context — it can't distinguish "agent is pushing a legitimate commit" from "agent was injected and is pushing a backdoor." The supervise policy is already the right shape for human-in-the-loop review on sensitive outbound actions; extending it with context from the agent's recent tool calls (what files were touched, what was the triggering task) would narrow the gap.
Semantic code review on git push. gitleaks is the wrong tool for catching injected logic. A review step on outbound commits — even a simple diff summary surfaced in cli.py supervise before the push is forwarded — would close the malicious-commit path without requiring the agent to be fully trusted.

16 KiB Raw Blame History Unescape Escape