Cloud Runtime for Agents
Run agents like you run prod.
Launch Claude Code, Codex, or your own agent on an isolated cloud machine with one command. Give it real work without giving it your credentials.
# install once $ curl -fsSL https://droneship.run/install | sh # then, in any repo $ droneship run claude repo acme/api @ 3f2a1c8 egress deny by default, 7 hosts allowed idle suspends after 30m
Bring the agent you already use
- Claude Codedroneship run claude
- OpenAI Codexdroneship run codex
- GitHub Copilotdroneship run copilot
- Geminidroneship run gemini
- Cursordroneship run cursor
- Your Agentdroneship run ./agent
A micro VM per agent.
Each run gets its own micro VM, booted in seconds from a pinned image with the common toolchain already in place, so the agent’s first command is real work rather than installing a language runtime.
built in
- hardware isolated, own linux kernel
- credentials outside the sandbox
- tool access under policy
- every action logged
default image
languages python · node · go · rust
tooling git · gh · npm · pip · cargo · docker
quality test runners · linters · formatters
agent agent skills
Why agents need enforced boundaries
Research and real-world incidents show how agents can act beyond their intended scope. These findings highlight the need for containment enforced outside the agent.
An agent will use whatever it can reach.
In Anthropic’s security tests, models including Mythos 5 attacked real systems after a setup error enabled internet access—despite being told they were in a simulation.
Enforcement has to sit outside the agent’s process, not in its instructions.
Read Anthropic’s assessmentWhatever an agent writes, something will run it.
Pillar Security found that agents could cross sandbox boundaries by writing files that trusted tools outside the sandbox would then load or run.
The machine that consumes what an agent writes must not be your own.
Read Pillar’s researchAgents find any channel you leave open.
METR found that roughly 1,200 agents used a shared package repository to communicate and coordinate, despite being intended to run in isolation.
Shared services have to be reachable only through an allowlist.
Read METR’s investigationAccess enforced outside the sandbox.
The CLI runs on your machine. Each agent run gets its own sandbox and identity in Droneship Cloud, with access only to the repos you grant. An integrated Agent Gateway routes calls, enforces policy, and automatically injects credentials into approved requests—so your agent can use connected services without receiving the raw keys.
Agent containment, explained
your machine
droneship CLI launch and manage runs
droneship cloud
sandbox · micro VM
agent repos you grant · persisted filesystem
run identity only — none of your connected credentials
agent gateway
identity → policy → decision
credentials
per run, injected on the way out
denied
never leaves the gateway
logged
every action → collector
allowed
models · mcp servers · endpoints
held
awaiting your approval
Identity and enforcement detail
- run identity
- a per-run SPIFFE SVID, issued and rotated by Droneship. The gateway verifies it before policy is evaluated.
- policy
- matched on host, method and path, so an approved service does not imply every action it exposes.
- credentials
- held per run outside the sandbox and injected into approved requests, so the agent uses a service without receiving the key.
Connect your tools.
Connect your MCP servers and choose which calls run automatically, require approval, or are blocked. The integrated Agent Gateway enforces your policy on every MCP and model call, checking the host, method, and path.
# policy
[tools]
default = "deny"
allow = ["github", "postgres.readonly", "anthropic"]
github = { methods = ["GET", "POST", "PUT"], paths = ["/repos/*"] }
approve = ["github.merge_pr"]github.create_pr ok anthropic.messages ok 1.2k tok postgres.query ok github.merge_pr hold awaiting approval stripe.create_charge denied not in allow
See what your agent did.
Every file touched, command run and tool called is logged while the agent works, with nothing to instrument and no SDK to import. Read it back with one command, or ship it straight to a collector.
$ droneship logs k3f9a2 acme/api · migrate auth to v2 · claude · 4m 12s spiffe://acme/run/k3f9a2 · creds rotated 3x 14:02:11 read src/auth/session.ts 14:02:18 tool github.list_prs ok 14:02:31 write src/auth/session.ts +84 -12 14:03:04 tool stripe.create_charge denied 14:05:52 cmd npm test 24 passed egress 7 allowed · 2 blocked export otel -> collector
Your work survives the sandbox.
Sync your repo—including uncommitted changes—from your laptop to the sandbox. Your files persist even if the sandbox fails, so you can recover your workspace in a new one. Take atomic snapshots to save and restore your repos, installed dependencies, and work at any point.
$ droneship snapshot k3f9a2 snap_7c1a · atomic · 2.4 GB · 4s $ droneship resume snap_7c1a filesystem restored acme/api @ 3f2a1c8 · node_modules intact agent ready
Run tasks in parallel.
Give each agent its own sandbox, identity, and access policy. Increase compute for demanding tasks, or spin up more sandboxes to run agents in parallel. Sandboxes suspend automatically after 30 minutes of inactivity.
deny by default · 7 hosts allowedidle suspends after 30m
Start your first run.
$ curl -fsSL https://droneship.run/install | sh $ droneship run claude