Security
"Dangerously" stops being dangerous — and you control exactly how safe.
Every agent runs in an isolated DevBox with a security profile you choose — from open experimentation to air-gapped, read-only, no-secrets compliance.
The Security Problem
Running AI agents unattended shouldn’t mean disabling all security.
Today, the only way to run AI coding agents uninterrupted is to disable the protections that exist for a good reason.
Evidence
Don't take our word for it. Take theirs.
The all-access modes that let an agent run uninterrupted? Every maker tells you to keep them inside an isolated environment.
--dangerously-skip-permissions“Only use this mode in isolated environments like containers, VMs, or dev containers without internet access, where Claude Code cannot damage your host system.”
Permission modes docs ↗--dangerously-bypass-approvals-and-sandbox · --yolo“Run every command without approvals or sandboxing. Only use inside an externally hardened environment.”
Codex CLI reference ↗--yolo · --allow-all“It is strongly recommended that you only use these options in an isolated environment.”
Copilot CLI — allowing tools ↗And the everyday auto modes they recommend instead are still — by their own admission — not a safety guarantee.
Claude Code · auto mode
Permission modes docs ↗“Auto mode is a research preview. It reduces prompts but does not guarantee safety.”
OpenAI Codex · Auto · auto-review
Codex auto-review docs ↗“Auto-review improves the default operating point for long-running agentic work, but it is not a deterministic security guarantee. It should complement, not replace, good sandbox design, monitoring, and organization-specific policy.”
Anthropic said the same about auto mode publicly — keep it in a devbox / isolated environment. @claudeai on X ↗
A DevBox is that isolated environment — disposable, off your laptop, away from your credentials. So you can run the modes their makers reserve for a sandbox.
Honesty note: Isolation reduces risk, it doesn’t erase it — even a DevBox can leak credentials to a malicious repo. We say isolated + disposable, never safe.
Real Risks
Destructive command execution
rm -rf, git push --force, system config changes — no approval required.
Secret leakage
Env vars, API keys, and tokens accessible to prompt injection attacks.
Lateral movement
Access to VPNs, cloud services, and internal networks from a compromised agent.
Environment contamination
Unwanted dependency changes, repo state corruption affecting your whole team.
No isolation between tasks
Multiple agents share the same filesystem, credentials, and permissions.
Isolation, by default
Isolated environments where autonomy is safe.
Instead of running agents with dangerous permissions on your machine, ClusterCode spins up isolated DevBoxes where each agent works unrestricted — safely.
Runs in its own DevBox
Isolated from the host, from other agents, and from your credentials.
Bypass flags are safe
The DevBox is disposable and sandboxed — nothing escapes.
Truly uninterrupted sessions
No confirmations, no interruptions. The agent works until it’s done.
Scoped access only
Cloned repo, dependencies, and the env vars you configure. Nothing more.
Real parallelism
5, 10, 15 simultaneous DevBoxes — each on a different ticket.
Before
Full access to your machine, your secrets, your network.
With ClusterCode
Each agent isolated. Bypass flags are safe. Nothing escapes.
Security Profiles
From experimentation to air-gapped compliance — one toggle.
* Hard ceilings on RAM (every profile) plus CPU cores and process count (Standard and up), enforced by the kernel — one runaway or malicious agent can't exhaust the machine (fork bombs, memory blow-ups) or starve its neighbors.
- Network
- Full internet
- Filesystem
- Read-write
- Secrets / env vars
- Injected
- Hardening
- default
- Runaway-process protection*
- Generous4 GB RAM · CPU/PIDs uncapped
- Best for
- Trusted dev
- Network
- Dev registries only
- Filesystem
- Read-write
- Secrets / env vars
- Injected
- Hardening
- cap-drop ALL, no-new-privileges
- Runaway-process protection*
- Tuned2 CPU · 4 GB · 256 procs
- Best for
- Everyday work
- Network
- Your allowlist only
- Filesystem
- Read-only + carve-outs
- Secrets / env vars
- Injected
- Hardening
- cap-drop ALL, no-new-privileges
- Runaway-process protection*
- Lean1 CPU · 2 GB · 128 procs
- Best for
- Sensitive repos
- Network
- No internet
- Filesystem
- Read-only + carve-outs
- Secrets / env vars
- Not injected
- Hardening
- cap-drop ALL, no-new-privileges
- Runaway-process protection*
- Lean1 CPU · 2 GB · 128 procs
- Best for
- Compliance / air-gapped
* Hard ceilings on RAM (every profile) plus CPU cores and process count (Standard and up), enforced by the kernel — one runaway or malicious agent can't exhaust the machine (fork bombs, memory blow-ups) or starve its neighbors.
Network Egress Control
Allowed ✓
github.comregistry.npmjs.orgapi.anthropic.compypi.org+ your custom allowlistfilter
Blocked ✕
evil.compaste-my-secrets.iorandom-exfil.netunknown-api.xyzeverything not on the listYour AI agent can reach npm. It cannot reach the open internet.
Non-allowlisted hostnames return NXDOMAIN — code, secrets, and test data have nowhere to go.
How ClusterCode Compares
- Isolated environment
- Per-task DevBox
- Network egress control
- Configurable allowlist
- Read-only filesystem option
- Yes
- Withhold secrets entirely
- Offline profile
- Self-hosted / your hardware
- Yes
- Setup
- Out of the box — one toggle
- Isolated environment
- Yes — you build it
- Network egress control
- DIY — you wire & maintain
- Read-only filesystem option
- Manual setup
- Withhold secrets entirely
- Manual
- Self-hosted / your hardware
- Yes
- Setup
- Build & maintain it all yourself
- Isolated environment
- Vendor-hosted
- Network egress control
- Not user-configurable
- Read-only filesystem option
- Not exposed
- Withhold secrets entirely
- Not exposed
- Self-hosted / your hardware
- No
- Setup
- Vendor-controlled
- Isolated environment
- Runs on your machine
- Network egress control
- None
- Read-only filesystem option
- No
- Withhold secrets entirely
- Runs with your env
- Self-hosted / your hardware
- N/A
- Setup
- No controls to set up
Comparison reflects publicly documented capabilities as of mid-2026; offerings evolve. You can replicate much of this with your own containers — ClusterCode just ships it built-in, enforced, and one toggle per launch.
Trust & compliance
How we run the platform itself.
The controls above protect each agent run. These are the operational practices that protect the orchestrator, your account, and the limited data we do hold.
Encryption in transit and at rest
Traffic to ClusterCode is served over TLS. The account, billing, and telemetry data we store are encrypted at rest.
Least-privilege access
Scoped access controls and continuous monitoring govern who and what can reach our production systems.
Your code never reaches us
By design, your source code, agent outputs, and secrets stay on your own hardware — shrinking what is ever at risk on our side.
Incident response
If a breach affects you, we notify you without undue delay and notify the relevant supervisory authority within 72 hours where the law requires it.
Vetted sub-processors
Stripe, Clerk, and Microsoft Azure (US hosting and transactional email) — each under contract that restricts how it may use your data.
Honest compliance posture
ClusterCode is not yet SOC 2 certified, and the Service is not intended for HIPAA, PCI DSS, or other regulated-data workloads.
Found a vulnerability?
We welcome responsible disclosure. Email security@clustercode.io — our policy and contact details are also published at /.well-known/security.txt.
Every DevBox has a security profile — you choose the level.
Network egress controls prevent code and data exfiltration.
Read-only filesystem on Strict and Offline; capability hardening on Standard and up.
Offline profile injects no secrets and has zero network — for air-gapped compliance.
With ClusterCode, "Dangerously" stops being dangerous — and you control exactly how safe.