Security

What happens to your code

Estelle reads your repository so it can answer about it and check changes against it. What that means for storage, retention, export and deletion is set out in the privacy policy and in more operational detail on data and processing.

Two properties are worth stating here because they are the ones people assume go the other way. Your repository content is used to answer your own account’s questions and is not used to train models. Navigation and verification answer from the index with no model call at all, so a large part of what Estelle does sends nothing to any provider.

Where it runs

Estelle runs on managed infrastructure rather than hardware we operate. The full list of sub-processors, including which ones can see repository content and which only see metadata, is on data and processing and is the single owner of that list. It is not repeated here, because a second copy drifts.

Model inference is the part customers most often want control of. You can bring your own provider key, in which case that provider bills you directly and the request is made with your credentials. You can also point the CLI at a model you host yourself, in which case the weights and the prompt never leave your machine.

Controls in the product

• Propose, do not ship. The default apply plan writes to a sandbox and opens a reviewable pull request. There is no automatic deployment step.
• Autonomy is opt-in and off by default. A team can raise it as far as auto-merge, and that unlocks only when the verification passes in a reproduction sandbox with no regressions. Any failing guard degrades it back to a pull request.
• Some surfaces stay human-gated at every level. Authentication, billing, schema, security and deployment changes are never auto-merged.
• Every autonomous action is audit-logged with an HMAC signature, and there is a global kill switch that stops the autonomous path for an account.
• The grounding gate makes no model call. It checks a proposed change against the real symbol graph, so it cannot be argued into agreeing with a hallucinated API.

Keys and access

• API keys are issued per account and can be revoked from the dashboard at any time.
• Provider keys you bring are used to make requests on your behalf and are never shown back to you in full once stored.
• Repository access is granted through the GitHub App, which you install and can uninstall yourself. Uninstalling it ends our access immediately.
• We will never ask for your password, and no one at Fate Labs will ask you to send a key over chat or email.

Reporting a vulnerability

Email security@fatelabs.ca. The same address is published at /.well-known/security.txt per RFC 9116.

What you can expect from us:

• An acknowledgement that a human has read it, within three business days.
• A plain answer about whether we think it is a real issue, and if it is, what we intend to do.
• Credit by name in the fix note, if you want it.

What we ask of you:

• Tell us before you tell anyone else, and give us a reasonable window to fix it.
• Do not access, modify or delete data belonging to anyone else while testing.
• Do not run denial-of-service tests or automated scanners against the production API.

Availability

Current and recent availability is on the status page, which reads from the live API rather than from a dashboard somebody remembers to update. We do not offer a contractual uptime SLA on self-serve plans; if you need one, it is part of an Enterprise agreement and we will write the number down.

Contact

Security reports: security@fatelabs.ca. Privacy and data questions: privacy@fatelabs.ca. Anything else, including security questionnaires, through contact.

Honour Systems Inc., doing business as Fate Labs. Ontario, Canada.