Security your team can verify, not just trust
Fleet is a single Go binary with no open ports and a local-first data plane — your source code never goes to Fleet. Every claim on this page is verifiable with standard tools.
Security-first architecture
Fleet keeps the worker surface small and documents its host prerequisites, local state, dashboard sync, and outbound dependencies.
Single Go binary
Fleet itself is one compiled Go worker binary. Claude Code, 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. When you connect Fleet to the dashboard, it reports operational metadata and usage metering — agent status, run counts, and run time — for your own visibility and billing, 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 Fleet worker 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 — the Anthropic API, or Amazon Bedrock / Google Vertex inside your own cloud
- Source code is never sent to Fleet; a registered instance reports operational metadata + usage metering (agent status, run counts, run time) to the control plane, 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. Claude Code's model backend is configurable: use the Anthropic API directly, or point it at Amazon Bedrock / Google Vertex to keep model traffic in your own cloud boundary. 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
Claude Code's model backend is configurable: use the Anthropic API directly, or point agents at Amazon Bedrock / Google Vertex to keep model traffic inside your own AWS or GCP account.
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, 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.