Security
The short version: an agent calls only tools that were approved, only on behalf of people you named, only up to a budget you set, and every one of those calls leaves a record you can export. The rest of this page says how each of those is enforced and where it stops.
What an agent can reach
Every tool call passes through a gateway before it happens. The gateway holds a registry of servers and the specific tools on each that have been approved, and each agent version carries its own list drawn from that registry. The check happens outside the prompt, so nothing written into a document or a request can widen it. Every call is checked against the list and recorded, allowed or not. Whether a call outside the list is refused or only recorded is a setting on the deployment; ask us which this one is running, and we will tell you. Each call also carries a short-lived assertion naming the person it is acting for, which the server verifies.
What an agent can spend
Every model call goes through one gateway holding a per-organization key with its own monthly cap, and every call is reserved against the agent's budget before it is made. When the budget tightens the run steps down to a cheaper model rather than failing, and each step-down is recorded. The reservation and the choice of model happen in the same step, so two runs at once cannot both take the expensive option and pass the cap between them. Anthropic models carry production traffic today; OpenAI and Google models are routable through the same gateway and have not yet done so.
How your data is separated
Every record carries the organization it belongs to, and the database itself refuses to return a row belonging to anyone else. That rule is enforced by PostgreSQL rather than by our application code, so a mistake in a query returns nothing rather than returning someone else's data. Our tests check it on every change, connecting as an unprivileged database user, because a privileged one would skip the rule entirely and the tests would pass while proving nothing. Our own operators read across organizations through a separate read-only role that cannot see stored credentials, and each of those reads is logged.
Where your data lives
In our tenant, in the United States: the database and the API run on Railway in a US region and the web app on Vercel. There is no choice of region yet. Directory tokens, connector credentials and channel secrets are encrypted at the application layer before they are stored, with a key we hold and can rotate. Everything moves over TLS. The record of what happened stays with us for as long as your organization exists and, if you leave, is archived rather than deleted, because an approval trail that can be deleted on request is not an approval trail.
What we ask for in your directory
Enough to show you a list of people and groups, to add someone to a group when a request has been approved, and to remove them when the period ends. Microsoft does not offer a permission limited to a single group, so the one we request covers group membership generally. We use it only after a decision, and every write carries the reference that will appear in your own Microsoft or Google logs, so you can reconcile ours against yours. The Microsoft 365 and Google Workspace pages list each permission and why.
You can disconnect at any time, from your own admin console or from ours. Disconnecting stops us reading and writing. It does not remove access that people already have, because taking access away is not what the word disconnect should mean.
How people sign in, and who does what
Sign-in is with a Microsoft or Google work account, or through your own identity provider if you configure its issuer, keys and audience. Enforcing that everyone uses it is not built yet. Inside an organization there are three roles: member, reviewer and administrator, plus separate permissions for connecting a directory or a connector and for billing. A reviewer cannot approve their own request. A reviewer deciding from an emailed link is checked again at the moment of deciding, so someone who has since left cannot decide from an old email.
What the language model sees
The text of the request, so it can work out what is being asked for. Email addresses, card numbers, API tokens and similar identifiers are removed before that text is stored or sent anywhere. The decision is not made by the model: it is made by the rules you set, which is why the same request always gets the same answer and why we can show you the reason. Past approvals and policy excerpts are retrieved and shown to whoever is deciding, but the gate itself ignores them; a document cannot argue an agent into a yes.
The record you can take away
The audit log as CSV, the whole organization as JSON, the posture report and every other report as CSV, and the list of who holds what and when it ends. The export covers every table that belongs to your organization or says why a table is left out. Nothing in the log can be edited or deleted, by you or by us; the database refuses the statement.
Who else is involved
- Anthropic, to read the request text, after identifiers are removed from it
- Microsoft or Google, only for the directory you choose to connect
- Clerk, for sign-in
- Stripe, which holds a customer record with your organization name and billing email for when paid plans exist; no card is taken in the beta
- Resend, to send notification emails
- Railway and Vercel, to run the service
Deleting your data
Ask, or do it yourself from the settings. Your data is exported first, then purged after thirty days, during which you can change your mind. Records of who approved what are archived rather than deleted. Run details older than your retention period are pruned; during the beta that period is set per organization by us on request rather than from a screen.
If something goes wrong
Use the address on the contact page for anything you believe is a vulnerability or a breach. It reaches the people who build the product, and you will hear back from a person. If we find that your data was affected by an incident on our side, we tell the administrators of your organization by email with what we know, when we knew it, and what we did. There is no status page yet; outages are announced by email to administrators.
What we have not done yet
We are not SOC 2 certified. We are in beta, there is no service level agreement, and single sign-on enforcement and automated user provisioning are not built. There is one region and no choice of it. Everything an agent does leaves our infrastructure as an outbound call we make, so anything on a private network or behind your firewall is out of reach; that is a boundary we chose, not a bug we are fixing this quarter. The terms, privacy notice and data processing agreement are drafts we send on request rather than pages you can read here. If any of those are requirements for you, this is not ready for you yet, and we would rather say so now.