Enterprise
The questions your security review will ask, answered before you ask them.
Including the ones where the answer is no. There is a list further down of what we do not have, and it is there because finding out in week six is worse for both of us.
Start here
We cannot reach anything you did not send us.
There is no crawler, no connector that pulls, and no credential of yours anywhere in our systems. You push content to an endpoint. That makes the integration auditable entirely from your side, and it bounds the worst case to exactly what you handed over.
Isolation
Four boundaries, all of them enforced.
The workspace is the boundary
It scopes all data and all keys: documents, chunks, entities, assertions, provenance, the ontology. There is no cross-workspace read path, because there is no cross-workspace query.
Keys are scoped and rotatable
Issue as many as you need, each scoped to what it needs: ingest, search, reading or changing the ontology, reading the workspace. Rotate or revoke from the console. The plaintext is shown exactly once, at creation.
Identity through WorkOS
Single sign-on, directory sync in both directions, and just-in-time provisioning. Removing someone revokes their live sessions rather than waiting for expiry.
Capacity is bounded per organisation
Each organisation has its own ceiling on extraction, set by its rate plan, so one tenant’s backfill cannot slow another’s ingest.
Tenancy model
Organisation, workspace, source.
An organisation is the billing entity and owns any number of workspaces. A workspace is the isolation boundary. Within it, every document belongs to exactly one source.
Console URLs carry the organisation and workspace, so a link always lands where it points — a shared URL never resolves to whichever tenant the recipient last had open.
organization ← billing entity
│ graph entitlement lives here
└── workspace ← isolation boundary
│ tier · rate plan · language
│ scopes ALL data and keys
├── sources ← integration connections
├── ontology ← v1 live + custom versions
├── api keys ← scoped: ingest | search
└── documents
entities
assertions
provenanceWho can do what
Five kinds of actor, and the ceiling on each.
| Actor | What it can do |
|---|---|
| Main Admin | One per organisation. Can reassign the role, and is the last account that cannot be removed. |
| Member | Console access scoped to the workspaces they are added to. |
| API key — ingest scope | Can push and delete documents. Cannot search. |
| API key — search scope | Can search. Cannot write anything. |
| MCP client | Acts for one person, in one workspace, with no more access than that person agreed to. |
Capacity
Nobody gets to be the noisy neighbour.
Extraction is the expensive path, and it is bounded per organisation rather than shared first-come-first-served.
Every organisation has its own extraction ceiling, set by its rate plan. The practical guarantee is the one you would ask for: what your neighbour does to their corpus cannot show up as latency on yours.
A backfill that reaches a ceiling waits rather than failing, and work interrupted part-way through resumes rather than starting over — so a large load completes on its own without anyone re-sending anything.
Deployment
One managed cloud. That's the whole list.
Competitors in this category advertise three deployment models. We have one, and pretending otherwise would waste your evaluation.
- Available today: a single managed deployment, single region, our infrastructure and our model providers.
- Not available: your VPC, your cloud account, your own encryption keys, or an EU-resident region.
- Not available: choosing the model. Extraction, embedding and synthesis run on models we select.
FAQ
Frequently asked
The questions a security review asks, answered without hedging.
Bring us your security questionnaire.
We would rather answer it honestly now than discover a blocker in week six.