TL;DR: Letting non-technical people share arbitrary agent-written code is a security problem nobody has solved politely. The membrane answers it at the platform boundary: every cell gets its own origin, its own egress policy, scoped secrets it never sees, hard spend caps, and an access log. Compute isolation is bought; web-layer isolation is built — and the most recent real-world breach came from the web layer, not the sandbox.
”We use Firecracker” is not a security story
Investment splits evenly between two layers, and the industry keeps proving the second one matters more:
- Writer AI “WriteOut” (Jul 2026): agent live-previews served from the same origin as the main app leaked session cookies into an attacker-controlled sandbox — cross-tenant account takeover with nothing to do with sandbox choice. Per-app origin isolation would have prevented it; no sandbox upgrade would have.
- Moltbook (Jan 2026): 1.5M API tokens and 35,000 emails exposed within 72 hours of launch — broken access control in agent-written code, at production speed.
- Georgia Tech Vibe Security Radar: 74 CVEs traced to AI-generated code, 35 in March 2026 alone — more than all of 2025 combined. Baseline studies put at least one flaw in ~38% of AI-generated code.
- SandboxEscapeBench (Oxford + UK AI Safety Institute, Mar 2026): frontier models demonstrably escaped sandboxes under realistic multi-step conditions. The agent itself is now a credible adversary in the threat model.
The five membrane controls
1. Per-cell origins, no shared cookie scope. Every cell lives on its own subdomain/origin with strict Content Security Policy. Cells never share cookie scope with each other or with the control plane. This is the Writer-AI lesson, enforced by construction — the deployer (possibly a non-engineer, possibly an agent) cannot misconfigure it because there is nothing to configure.
2. Per-cell egress allow/deny (DNS + IP). An agent-written app cannot exfiltrate to anywhere the org hasn’t permitted. Default-deny on free/public cells; org-approved internal endpoints allow-listed for team tiers. The app that only needs the warehouse DB cannot reach the open internet, whatever its code tries.
3. Secret injection at the boundary. Cells receive scoped credentials injected by the platform — never long-lived org keys pasted into source, env files, or prompts. An agent holding deploy rights (scoped tokens) cannot read secrets it wasn’t granted.
4. Resource and spend caps, per cell and per org. Hard stop plus alerts. A non-technical deployer must not be able to generate a surprise bill — the cap is a safety control, not a billing feature.
5. Access log per cell. Who opened it, when. This is what converts IT’s “ban unsanctioned tools” reflex into a sanction conversation, and it’s cheap to build on the front door we already own.
What the platform owns vs what you own
| Platform (membrane) | Builder |
|---|---|
| Origin isolation, CSP, cookie scope | Business logic correctness |
| Egress policy enforcement | Declaring which endpoints the app needs |
| Scoped secret injection | Never pasting keys into code |
| Spend caps + hard stops | Setting caps sensibly per tool |
| Access logging, takedown tooling | Reporting abuse promptly |
The collapse is the point: the agent that wrote the app needs no security knowledge, and the person sharing it needs no cloud knowledge, because the boundary — not the code — carries the guarantees.
Abuse control (launch requirement, not roadmap)
“Unlimited free deploys of arbitrary code, publicly reachable” is the most abusable product shape in hosting. Every provider that offered it retreated. Designed in from day one: verified identity before public exposure, default egress restrictions on free cells, per-account cell and CPU ceilings, outbound-domain reputation checks, rapid takedown tooling. Getting this wrong ends the company via the abuse desk, not the market.
FAQ
Is my code reviewed for vulnerabilities? No — and that’s the premise. The membrane assumes agent-written code has flaws (~38% baseline) and contains the blast radius at the boundary instead.
Which sandbox do you use? The execution layer is bought (Cloudflare primitives for v1; OpenSandbox/microsandbox as documented fallback) precisely so engineering goes into the web-layer boundary vendors don’t sell. Ask about our origins, egress, and secret handling — not our hypervisor brand.
Does this satisfy enterprise security review? It’s aimed at it: SSO/deprovisioning, per-cell logs, egress control, caps, residency-as-region-choice, SOC 2/ISO-shaped posture from day one (certified when a deal blocks on it). Regulated production workloads are still explicitly out of scope early.
Sharing agent-built code with colleagues? Make the boundary do the worrying. Deploy now.