The isolation package, control by control.
Written for the security team that will evaluate this — not for marketing. Each control with its mechanism; the evidence, under NDA in the architecture review.
Isolation enforced by the database
RLS with SET LOCAL ROLE per transaction: the code cannot pick the tenant even if it tried.
Tool whitelist at two points
Explicit list per agent, checked at two points of the runtime. What is not listed does not run.
Audit with the real actor under impersonation
When an operator acts “as” a tenant, the log records who they really were.
Runtime isolation monitoring
A watcher turns violations into alerts with an owner, not logs nobody reads.
No CORS by design
The API exposes no surface for browser requests from arbitrary origins.
HMAC webhooks, fail closed
Every signed input is verified; if it fails, it is rejected.
Fail-closed deployment
If the isolation tests fail, the deployment does not ship. It is a pipeline gate.
Idempotency at two levels
Webhook and queue retries never duplicate effects: deduplication on input and execution.
No batching across clients
Model calls never mix context from different clients.
- Multi-tenant data model
- Row-level partitioning in the database. Tenant context is enforced per transaction with SET LOCAL ROLE: application code cannot accept a tenant_id from a caller, by design. Isolation tests are blocking: if they fail, the deployment does not ship.
- Credential handling
- Secrets in a dedicated manager with scheduled rotation; named accounts with hardware MFA; short-lived credentials; access restricted to the engineers on the engagement, with every access logged.
- No-training policy
- Zero-retention model APIs. Your conversation data is never used to train models sold to others. It is in the DPA — contractual, not a blog note.
- Security questionnaire
- A standard questionnaire answered and ready for your team — ask and you have it before the first call. The sub-processor list, with region and purpose, is published in the privacy policy.