Prove the agent jail
Fleet is a locally installed binary. It opens no ports. Your source never goes to Fleet. Every claim on this page is something you can check with standard tools.
Prove the agent jail
On the Linux machine that launches agents, run the test below. It tries the known ways out: TCP, DNS, secrets, and the rest. Each attempt prints DENIED. If the process needs a host, the run waits until you allow that host.
- Agents cannot get out. No direct network, DNS, host filesystem, or credential escape.
- Agents can request access. An unknown destination parks
blocked_on_egresswithout holding a socket. - Agents cannot grant themselves access. Workload, MCP, and in-sandbox callers are refused.
- A human grant enables traffic to that destination for a bounded window, then the relay closes.
- Failures fail closed. Missing intercept, iptables, or an unproven grant denies outbound traffic.
Run it yourself
After install, fleet doctor checks that this host can create the jail. The public oracle is the hostile probe TestAcceptance_CompromisedAgentHasNoAlternateEgressPath plus the live OpenCode run TestAcceptance_OpenCodeAgentCannotEscape in internal/sandbox/acceptance_test.go and internal/sandbox/live_agent_test.go. The OpenCode test skips unless opencode is installed.
$ fleet doctor# agent sandbox: user+mount+pid+net namespaces available$ go test -count=1 -run TestAcceptance_CompromisedAgentHasNoAlternateEgressPath ./internal/sandbox/$ go test -count=1 -timeout 5m -run TestAcceptance_OpenCodeAgentCannotEscape ./internal/sandbox/A passing hostile transcript
TCP_DENIED UDP_DENIED IPV6_DENIED DNS_DENIED LOOPBACK_DENIED RFC1918_DENIED METADATA_DENIED RAW_DENIED BROKER_PROXY_DENIED VENDOR_DENIED SECRET_DENIED SYMLINK_DENIED HOSTUNIX_DENIED CHILD_SECRET_DENIED
A grant names a host, such as registry.npmjs.org, for a bounded window. Merge and delete stay on your review and approval steps. The jail wraps Fleet-launched Linux agents. Grok Bot, Cursor Cloud, and Codex cloud VMs run on their vendors.
Security-first architecture
Fleet keeps the worker surface small and documents its host prerequisites, local state, dashboard sync, and outbound dependencies.
Agent sandbox
Fleet-launched Linux agents run in user, mount, PID, and network namespaces with a private workspace, home, and tmp. Model traffic goes through Fleet's inference broker. A grant names a host, such as registry.npmjs.org, for a bounded window.
Locally installed binary
Fleet itself is one locally installed binary. Claude Code or OpenCode, tmux, git, and the GitHub CLI remain explicit host prerequisites checked by fleet doctor.
No container runtime
No Node.js, no Docker daemon, no container orchestration. Nothing running that you didn't explicitly start.
Embedded worker state
Local worker state lives in ~/.fleet/fleet.db. The hosted control plane separately stores dashboard, workflow, and billing data.
Local Unix-socket IPC
Local daemon coordination uses Unix domain sockets, so Fleet does not expose an inbound application port by default.
Your code stays private
Your source code is never sent to Fleet. It goes only to the model backend you choose and GitHub. A registered worker reports operational metadata such as agent status and run time, plus one billing fact for each durably authorized hosted root-workflow start, but never your code.
Local-first data plane
Your agents, code, and SQLite database run on your own infrastructure — your code never goes to Fleet. The CLI sends anonymous, opt-out usage analytics (which commands run, version, OS — never your code, paths, or repo names; disable with fleet config set telemetry off, FLEET_TELEMETRY=0, or DO_NOT_TRACK=1), and once connected the control plane receives operational metadata and usage metering only.
Your data stays in your boundary
Your code, agents, and worker database run on your infrastructure, and your source never goes to Fleet. Outbound includes your model backend, GitHub, connected Linear or Jira providers, anonymous opt-out PostHog usage analytics, and — once registered — dashboard sync and metering.
- The locally installed binary and its SQLite database run on your infrastructure; the dashboard and its control-plane storage are hosted by Fleet
- Your code is shared only with the model backend you choose — Anthropic, Bedrock, Vertex, or another provider Claude Code or OpenCode supports
- Source code is never sent to Fleet; a registered instance reports operational metadata and one billing fact per durably authorized hosted root-workflow start, never code
- SQLite database stored at ~/.fleet/fleet.db (configurable via FLEET_DB_PATH)
- Unix domain sockets carry local daemon IPC; dashboard sync and configured integrations use documented outbound HTTPS
- The CLI sends anonymous, opt-out usage analytics (command names, version, OS — never code, paths, argument values, or repo names); disable with fleet config set telemetry off, FLEET_TELEMETRY=0, or DO_NOT_TRACK=1
- Outbound connections are your model backend, GitHub, connected Linear or Jira providers, anonymous PostHog usage analytics, and — once registered — the Fleet control plane; PostHog can be disabled
Data sovereignty
Fleet runs local-first — your source code never goes to Fleet. The coding harness's model backend is configurable: Anthropic, Bedrock, Vertex, or another provider Claude Code or OpenCode supports. Outbound traffic is the model backend, GitHub, any work-item provider you connect (Linear or Jira), anonymous opt-out CLI usage analytics (disable with fleet config set telemetry off, FLEET_TELEMETRY=0, or DO_NOT_TRACK=1), and — once registered — usage metering to the control plane. All are connections you configure and can audit.
Configurable model backend
The coding harness's model backend is configurable: Anthropic, Amazon Bedrock, Google Vertex, or another provider Claude Code or OpenCode supports, so model traffic can stay inside your cloud.
Explicit dashboard registration
The binary is free to install and inspect. Starting agents, daemons, or workflows requires an active license and registration with the hosted control plane.
Verified binary distribution
The installer downloads a prebuilt binary and verifies its SHA-256. Claude Code or OpenCode, tmux, git, and the GitHub CLI are supplied separately on the host.
Operator-controlled upgrades
fleet upgrade fetches release metadata and the expected SHA-256, then replaces the binary only when you invoke it; --check and --dry-run show the change first.
Enterprise governance built in
Worker controls and hosted dashboard governance work together across saved workflow runs.
Per-agent budget enforcement
Set cumulative run-time limits per agent. Agents that exceed their time budget are stopped.
Complete audit trail
The fleet log combines recorded decisions, workflow markers, approvals, and fabric events in one chronological history.
Workflow approval gates
Saved workflows can pause for human approval. Rejected work routes back with the approver's context for remediation.
Agent quarantine
Instantly isolate misbehaving agents. Quarantined agents cannot execute, publish events, or interact with the fleet.
Org hierarchy with RBAC
Org-tier and repo-tier agents with role-based access control. CEO, CTO, department heads, and scoped developers.
6-dimension eval scoring
Agent evaluations score task output, reliability, quality, efficiency, collaboration, and cost as separate dimensions.
Logistic regression risk model
An 8-feature risk model uses operational signals to calculate risk and drive quarantine at the critical threshold.
Bounded workflow retries
Workflow retry and fix loops have explicit bounds, with approvals available before consequential actions.
Verify it yourself
Every security claim Fleet makes is independently verifiable. No trust required.
No network listeners
$ lsof -nP -iTCP -sTCP:LISTEN | grep fleet# (no output) — Fleet opens no listening portsSee exactly what leaves
$ sudo tcpdump -i any -n 'tcp port 443' # watch Fleet egress# model backend, GitHub, PostHog unless opted out, control plane when registered, and configured Linear/Jira providersInspect the Fleet binary
$ file $(which fleet)fleet: Mach-O 64-bit executable arm64$ otool -L $(which fleet)# only system librariesInspect local worker state
$ ls -la ~/.fleet/fleet.db-rw-r--r-- 1 user staff 245760 fleet.db$ sqlite3 ~/.fleet/fleet.db ".tables"agents events fabric_events pipelines ...Reporting vulnerabilities
We take security reports seriously. If you discover a vulnerability, we want to hear about it.
Report security vulnerabilities to
security@fleetctl.aiInclude a description of the vulnerability, steps to reproduce, and any relevant proof-of-concept. We will acknowledge receipt within 24 hours and provide a detailed response within 72 hours.
Ready for a security architecture review?
Our team will walk your security engineers through Fleet's architecture, data handling, and governance model.