Who we are
Fleet by Oracis is operated by Oracis AI LLC, a United States company, which also operates Oracis Engineering at oracis.ai. Oracis AI LLC is the controller of the data this policy describes. Draft pending counsel review; effective date to be set.
Scope
This policy covers the hosted Fleet service you connect an MCP client to, and this website, fleet.oracis.ai. The oracis.ai website has its own policy. The Fleet software that runs on an engineer's own machine is out of scope: nothing it processes reaches us.
What we collect and why
Every row below was traced in the code and configuration on 27 September 2026 before it was written. Where no code enforces a retention period, the row says so.
| Category | What | Why | How long |
|---|---|---|---|
| Account | Email address, the identity provider's user id, your role, the organizations you belong to, and when you joined. | To sign you in, decide what you may do, and show you your organizations. | While the account exists. Deletion on request; no automated deletion yet. |
| Sign-in and authorizations | The client you authorized, the scopes, a SHA-256 hash of each Fleet session token and its expiry, and revocation records. Your identity provider's access tokens are verified and not stored. | To authorize each call and to end access when it is revoked. | Sessions expire after 8 hours; the hashed records persist. Not yet defined. |
| Invitations | The invited email, the role, who issued it, an expiry and a hash of the single-use token; the acceptance is audited. | To admit only the person who was invited. | Not yet defined. |
| Repository connections | The repository name (github.com/owner/name), the member who attested control of it, and when. | To know which repositories your organization may have verified. | While the connection exists. Not yet defined. |
| Source code | A read-only fetch of a connected repository into a mirror on the validator service, and an archive of the exact commit copied into a single-use VM for the run. | To run your verification policy against the exact commit. | The VM is destroyed after the run. The mirror persists on the validator's disk; retention not yet defined. |
| Validation inputs and receipts | Repository, commit, tree, policy, each command's arguments and exit code, SHA-256 hashes of its output, timing, and the VM's identity facts. Raw command output is not part of a receipt. | To produce evidence an independent party can check, and to publish a check. | Receipts are valid at most 168 hours and are kept as files on the validator. Retention not yet defined. |
| Jobs | The task text you submit, the repository, the budget, the job's state and its event log. | To run the job after you disconnect and to report on it. | Not yet defined. |
| Model requests | The task text and the repository content a job needs, sent to model providers through OpenRouter under a per-job key, with data collection set to deny on every request. The API itself sends nothing to a model. | To do the engineering work a job asks for. | Providers' own retention is not verified by us; see Subprocessors. |
| Learning records | Which lessons were shown to which organization and client, with a 16-character fragment of the session token's hash, the lesson ids, the repository and the kind of work; and whether you confirmed a lesson. The task text is matched, not stored, and no lesson text is kept in the warehouse. | To rank lessons better next time, and to measure whether they helped. | Not yet defined. |
| Usage and spend | Budgets, reservations and settled amounts per job, and hashes of the per-job provider keys. | To enforce the ceilings you set and to account for cost. | Not yet defined. |
| Logs | The application keeps no per-request log and records no IP address. Unexpected errors are logged with a reference id and a stack trace. The private services log one line per call with the organization and actor. The hosting provider keeps its own platform logs, which may include IP addresses. | To diagnose failures you report by their reference id. | Application logs: the hosting provider's log retention, not verified by us. |
| Acknowledgement emails | When you request access or write to support on this site, we queue one acknowledgement email to the address you gave, and record whether our email provider accepted it and later reported it delivered, bounced or marked as spam. An address that bounces or complains gets nothing further. A request never subscribes you to marketing, and it never creates an account, connects a repository, issues credentials or starts work. | To confirm we received your message, and to stop sending to addresses that cannot receive mail. | Delivery records: not yet defined. |
| This website | No cookies and no analytics. If you send a form, the fields you typed and a SHA-256 hash of your IP address reach the Oracis intake API and are stored there. | To answer your access request, support message or security report. | Intake records: as the oracis.ai privacy policy states. |
What we don't do
- We don't sell or rent personal data, and we don't use it for advertising.
- We don't run analytics, advertising pixels or session replay on the service or this site, and this site sets no cookies.
- We don't put your repository content or task text into model requests without data collection set to deny, and the API itself never calls a model.
- We don't read your conversation with your AI client. Fleet receives only the tool calls that client sends it.
- We don't store your identity provider's access tokens, and every token Fleet issues is stored only as a hash.
Who receives it
The processors that receive data, what each receives and where, are on the subprocessors page. In short: the identity provider and database, the hosting provider and its VMs, GitHub, the model gateway and the providers behind it, the CDN that serves the consent page's script, and the email service behind this site's forms. We disclose data to others only when the law requires it, and we would tell you unless the law forbids that too.
Where it is processed
The identity provider and operations database run in a Supabase project in US East. The hosting provider's region for the services and the VMs has not been verified by us and is stated as unknown until it is. Model providers may process requests wherever they operate.
How long we keep it
Honestly: there is no automated retention or deletion in the service yet. The pieces with a fixed lifetime are sessions (8 hours), download links (15 minutes by default, 1 hour at most) and receipts (valid at most 168 hours). Everything else persists until it is deleted by hand. A retention schedule with tombstones is a design milestone and will be published here before general availability. Until then, you can ask for deletion at any time through support.
Your rights and how to exercise them
You can ask what we hold about you or your organization, ask for it to be corrected or deleted, object to a use, or ask for a copy. Write to support from the email on your account; we verify identity before we act, and an organization owner's request covers the organization's records. Depending on where you live you may also have the right to complain to a supervisory authority.
Security
The controls that protect this data, each with its state, are on the security page. Encryption in transit and at rest follows our providers' defaults, and we claim nothing beyond what they document.
Children
Fleet is for organizations and their engineers. It is not directed at anyone under 18, and we don't knowingly collect their data.
Changes
We will post changes here with a new revision in the footer index, and tell pilot organizations by email before a material change takes effect.
Contact
Privacy questions and requests go to support. A dedicated privacy contact will be listed here once it exists.