Security

Effective date: October 21, 2026

What is in place today, what is not, and how to tell us when something is wrong.

No certification yet, and we will not imply one.

Estelle does not hold a SOC 2 or ISO 27001 certification today, and there is no badge on this page. When that changes it will be dated here and the report will be available under NDA, not announced as a logo.

Your code is not training data.

Estelle does not train on the content of your repositories. That commitment, what it covers and how to opt out of everything else is written in full on how Estelle improves itself.

A human merges.

The default repair path proposes a reviewable change. It does not deploy, and it does not push to your production environment.

Where we are today

Estelle is built by a small team and this page is written to match that. Here is the honest state of the things a security reviewer asks about first.

SOC 2: not certified. No audit report exists yet.
ISO 27001: not certified.
Third-party penetration test: none commissioned yet.
Paid bug bounty: none. We do accept and credit reports, below.
Transport security: the site and the API are served over HTTPS only.
Tenancy: repository data is scoped per account. The isolation model is described on data and processing.
Sub-processors: named, with what each one receives, on data and processing.

Important.If a procurement questionnaire needs one of the first four, the answer today is no. Tell us what you need and we will tell you whether and when we can get there, rather than sending a roadmap that implies it already exists.

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.

Note.We do not pay bounties yet. We would rather say that plainly than let a researcher spend a weekend on an assumption.

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.