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 ingest or to search. Rotate or revoke from the console. The plaintext is shown exactly once, at creation.
Identity through WorkOS
AuthKit with sealed sessions, directory sync in both directions over webhooks, and just-in-time provisioning. Removing someone revokes their live sessions rather than waiting for expiry.
Capacity is bounded per organisation
Extraction concurrency and a model-token budget are both capped per organisation, metered in the unit the provider actually bills.
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.
This is worth stating plainly because it started as a real failure rather than a design principle: for a period, one organisation could consume roughly 70% of the platform's extraction capacity and nothing stopped it. Concurrency ceilings and a token budget — metered in the unit the model provider bills, not in an approximation of it — now cap each organisation according to its rate plan.
Orchestration runs on durable steps with per-step retries and replayable runs, so a backfill that hits a ceiling waits rather than failing, and a run that dies mid-way resumes rather than starting over.
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.