What we don't hold
Fleet has no SOC 2 report, is not ISO 27001 or HITRUST certified, holds no FedRAMP authorization, and HIPAA has no certification program, so we claim none. No independent penetration test of the hosted service has been performed yet. If your procurement needs one of those, tell us before you invest time.
What follows is what the code does and what has been observed, each row with the kind of evidence behind it. The Fleet source is private; a reviewer under NDA can see the code and tests behind every row.
The boundary that matters most
The service that faces the internet holds neither the key that signs receipts nor the key that posts GitHub checks. Two private services with no public address hold them, and a service refuses to start with the wrong key in its environment. A compromise of the public service could therefore not forge a receipt or post a check.
Proven live
Observed on the deployed service, with the date and who observed it.
| Area | Control | State | Evidence |
|---|---|---|---|
| Transport | TLS at the edge for every public request. | Proven live | Observed on the live service, 27 Sep 2026 |
| Authentication | Every MCP call without a bearer token is answered 401; nothing is admitted anonymously. | Proven live | Observed on the live service, 27 Sep 2026 |
| Authentication | OAuth 2.0 authorization code with PKCE (S256) through Fleet's own consent page. | Proven live | Observed live: a Claude Code session signed in through the consent page, 27 Sep 2026 |
| Endpoint | Streamable HTTP, stateless: no long-lived connection state to hijack. | Proven live | Observed on the live service, 27 Sep 2026 |
| Tool surface | Eight purpose-built tools; none generates media; none takes a freeform HTTP method or path. | Proven live | Live tool list, 27 Sep 2026 |
Implemented but not yet proven live
In the code and its tests in the Fleet repository, named by file. Not yet observed on the deployed service by an independent check.
| Area | Control | State | Evidence |
|---|---|---|---|
| Tokens | Every token Fleet issues (session, invitation, download link) is 32 random bytes stored only as a SHA-256 hash. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Tokens | Identity-provider access tokens are verified against the provider's published keys with issuer, audience, expiry and not-before checked, the client on an allow-list and the email verified; they are never stored. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Tokens | Sessions last 8 hours; download links 15 minutes by default, 1 hour at most. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Tenancy | Row-level security on every operations table with no policies; all writes go through audited database functions. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Tenancy | The organization is checked on every call; another organization's jobs, validations and repositories answer not found. | Implemented | Fleet source and tests (private; reviewable under NDA); cross-tenant tests |
| Tenancy | Revocation ends an identity's sessions and cancels its queued and running jobs; a worker holding a lease is fenced out at its next renewal. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Key boundary | The internet-facing service holds neither the receipt signing key nor the GitHub App key; two private services with no public address hold them. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Key boundary | A service refuses to start with the other role's key in its environment or with a public address it should not have. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Key boundary | The consent page can embed only public values; a secret in its configuration stops the service from starting. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Execution isolation | Each validation lane runs in a freshly created VM that receives an archive of the exact commit, bound by hash, before it exists. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Execution isolation | Commands run in a sandbox as an unprivileged process with every capability dropped, a read-only root, memory, process, disk and time caps, and no network route out. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Execution isolation | A probe of the sandbox and a check of the pinned image must pass before any candidate code runs. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Execution isolation | The VM is destroyed after the run; if its destruction cannot be confirmed, the lane is incomplete, never passed. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Evidence | Receipts are signed envelopes binding repository, commit, tree, policy, each command's arguments and exit code, and output hashes; never raw output; valid at most 168 hours. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Evidence | The publisher verifies a receipt against its own pinned keys before posting, refuses a superseded receipt, and posts check-runs with counts and ids only. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Repository access | Source is fetched read-only; the GitHub App can write checks and read contents and metadata, nothing else. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Repository access | A candidate commit cannot change its own verification policy; the policy is read from the default branch. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Model calls | The hosted service calls no model. Job model calls use a per-job provider key capped at the job's budget, with provider data collection set to deny on every request. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Spend | A job's budget is reserved in the same transaction as the job; per-job and per-organization ceilings apply; the hosted cap starts at zero. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Request bounds | A 1 MiB request body cap, 30-second header and 60-second request timeouts, and bounded validator concurrency and queue. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Logging | No per-request log and no IP address in the application; unexpected errors are logged with a reference id the caller can quote; configured secrets are scrubbed from log lines. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| Supply chain | The service image pins its runtime by digest and its tools by checksum, installs from the lockfile, and checks both at start. | Implemented | Fleet source and tests (private; reviewable under NDA) |
| This website | No cookies, no third-party script; the content security policy allows only this origin and the Oracis intake API; HSTS, nosniff, referrer and permissions policies; GET and HEAD only. | Implemented | This site's server and its tests (oracis-engineering) |
Planned
Designed or briefed, with the brief or register id. Not in the code.
| Area | Control | State | Evidence |
|---|---|---|---|
| Authentication | OAuth discovery from the endpoint, so a hosted client can find the authorization server on its own. | Planned | Fleet readiness audit, 27 Sep 2026 |
| Authentication | Tokens bound to the Fleet resource rather than a project-wide audience. | Planned | Fleet readiness audit, 27 Sep 2026 |
| Authentication | A documented refresh-token rotation policy, tested against each supported client. | Planned | Fleet readiness audit, 27 Sep 2026 |
| Tool surface | Tool annotations (title, read-only and destructive hints) published by the server. | Planned | Fleet readiness audit, 27 Sep 2026 |
| Tool surface | Scopes enforced per tool. | Planned | Fleet readiness audit, 27 Sep 2026 |
| Request bounds | Request rate limiting on the hosted endpoint. | Planned | Fleet readiness audit, 27 Sep 2026 |
| Data lifecycle | A retention schedule and automated deletion for repository mirrors, receipts, job records and learning records, and a tested restore. | Planned | Fleet design milestone F4 |
| Operations | A readiness check covering the database, the delivery worker and the applied schema. | Planned | Fleet readiness audit, 27 Sep 2026 |
| Operations | Per-organization fairness and concurrency caps in the job queue. | Planned | Fleet readiness audit, 27 Sep 2026 |
| Supply chain | Dependency vulnerability scanning and code scanning in Fleet's CI. | Planned | Fleet readiness audit, 27 Sep 2026 |
| Disclosure | A dedicated security mailbox and a written safe-harbour policy for good-faith research. | Planned | Owner and counsel decision |
| Assurance | An independent penetration test of the hosted service. | Planned | None performed to date |
Encryption and where data lives
Traffic to the hosted service and to this site is encrypted in transit by the hosting provider's edge. Data is encrypted at rest by the providers' defaults; we claim nothing beyond what they document. The operations database is a Supabase project in US East. The hosting provider's region for the services is not stated on this page because we have not verified it; the subprocessors page says the same.
Reporting a vulnerability
If you believe you have found a security issue in Fleet or this site, tell us through the form below, or use the contact in security.txt. Include how to reproduce it and what you observed. Don't include credentials, private source code, patient data, confidential records or another organization's data. Safe-harbour terms for good-faith research are being finalised with counsel.
Security questionnaires
The three tables above should answer most of a vendor security questionnaire, with the honest answer where a control is planned rather than present. If yours asks something they don't, send it to support.