What leaves your deployment, and what does not.
Most of this page answers a question a reviewer will ask anyway. The rest states plainly what is not built, because a security page that lists only its strengths is the document a reviewer stops trusting halfway down.
If you are completing a review, ask for the data-flow document and the third-party licence scan. Both are maintained, both are more detailed than this page, and if anything here contradicts them, they win.
Data handling
Four claims, each of which changes what a reviewer has to worry about.
Source data is reduced, not stored
A registered dataset is stored as joint counts — the sufficient statistic — and the rows are dropped. The model is fitted to counts, not to records. Nothing on this site requires patient records, credentials or production data to be handed over, which is why the walkthrough form says so explicitly.
Credentials never cross the API
The connection registry stores a name and nothing else. A warehouse read is performed as a query push-down, so the deployment is given a statement to run rather than a credential to hold. A caller who already has a connection hands over rows instead — a deliberate boundary rather than a missing feature.
Nothing is sent to a model provider unless you configure one
The model transport can be pointed at a model running locally, and the pipeline can be replayed against recorded responses. The shipped benchmark was run entirely against a local model for this reason.
Usage is reported to you, not to us
Usage accounting is queryable through your own API against your own workspace. There is no telemetry endpoint and no third-party analytics on the application origin.
Retention
Bounded, stated, and different per object because the objects have different lifetimes.
- Jobs
- 90 days
- Analyses
- 730 days
- Audit events
- 400 days
These are the defaults the repository enforces with scheduled maintenance runs, not a policy statement about a hosted service. In a self-hosted deployment they are settings you own.
Tenancy
Projects are isolated. Every user and every API key is scoped to one, and the tenant is carried on the request rather than inferred from it — so "which tenant is this request for" is a question about stored facts rather than about a header the caller chose.
A search for ENABLE ROW LEVEL SECURITY returns zero matches. Tenancy today is enforced by query construction, which is exactly what our own production plan says it does not want.
Governance status
Stated as of today, not as of the roadmap. Every row is checkable in the repository, and none of them is aspirational.
| Control | Status | Note |
|---|---|---|
| Audit trail | Implemented | who did what, queryable and facetable |
| Typed errors | Implemented | 22 stable error codes, documented |
| Dependency licences | Scanned | 0 GPL or AGPL in either the Python or the JavaScript tree |
| Application-level encryption at rest | Not built | encryption at rest is whatever the host provides; the application does not encrypt rows |
| Key management | Not built | beyond a single secrets key from the environment |
| Row-level security | Not implemented | isolation is enforced by query construction, not by the database |
| Per-tenant rate limits | Not implemented | |
| SBOM | Not published yet |
This table is the page. It is more persuasive than a page of badges because every row can be checked, and because four of the eight are no. A reviewer who reads it will find nothing behind it that contradicts it — which is the only property a security page can actually offer.
Deployment
A FastAPI service and a PostgreSQL database. It runs on your hardware.
- No queue broker, no vector store, no third-party analytics on the application origin
- The console and this website are served from separate origins from the API, so a marketing deployment cannot affect the API's availability
- One API process and one database is the measured configuration; horizontal scaling has not been measured and is not claimed
- Ten dependencies, 47 packages installed including test and development extras, of which 14 carry a compiled extension — the footprint an operator has to audit
Licensing
AnantCausal is proprietary software of AnantHQ Inc. No licence is granted by its presence in a repository or on this site. Third-party components are used under their own licences, listed in full in the repository, and no GPL or AGPL dependency is present in either the Python or the JavaScript tree.
What to ask us for
If you are completing a security review, ask for the data-flow document and the third-party licence scan — both are maintained and both are more detailed than this page. If something here contradicts what you find, tell us: the repository is the source of truth and this page follows it, so a contradiction is a defect in the page rather than a matter of interpretation.
security@ananthq.com — the same mailbox handles a suspected vulnerability as handles a review, and a disclosure is welcome rather than tolerated.