How agents are kept in bounds

The honest concern with any agent is short. Will it do something you did not want, read data it should not, call somewhere it should not, or spend money while you are asleep. What follows is the control that answers each of those, and where that control actually lives.

No tool is ever told which customer to read.

The usual way a platform keeps customers apart is a check: look up who is asking, then filter. That works until someone forgets the check on one path. Here the workspace identity is taken from a cryptographically verified token, never from anything the request carries, so a tool has no way to name a different workspace. There is no argument to tamper with.

The relational database enforces the same separation a second time, independently. Rows carry their workspace, row-level security is forced, and the account the application uses is created without the ability to bypass it. Even a query with a mistake in it comes back with your rows only.

An email cannot give your agent orders.

Anything written by someone outside your workspace, an email body, a web page, a support ticket, a form submission, is wrapped before the model reads it. The wrapper says plainly that this is data rather than instructions. The interesting part is what stops an attacker from closing the wrapper early and continuing as if they were you.

And we assume a successful attack is silent.

Asking the model afterwards whether it was manipulated is close to worthless, because the case you care about is the one where it complied without noticing. So the incoming content is scanned directly for text shaped like instructions aimed at an assistant, which fires whether or not the model reacted. The model's own report only ever adds confidence; it never clears a hit. When something trips, the evidence is kept and a person is told.

The answer is decided before the key is touched.

When an agent calls an outside service on your behalf, the credential is held by a broker, not by the agent and not by the model. Authorization runs first, and only a request that has already passed it causes a secret to be read at all. A refused request performs zero credential reads, so a denied call cannot leak anything, even into a log.

An agent earns the right to act, one task type at a time.

There is no global switch that makes an agent autonomous. Authority is a grid: each agent, against each kind of task, at a level you set. A new agent proposes and waits. As you approve its work in a given area it becomes eligible for promotion in that area alone, and you decide whether to promote it. Being trusted to file a report does not make it trusted to touch your CRM.

Anything an agent did on its own initiative is recorded in an undo journal and can be reversed. Every tool call, on every integration, is written to an audit trail recording who it acted as and when.

Four access levels, 22 named permissions.

Passkeys, multi-factor, and single sign-on.

You can sign in with a passkey, on a phone or a hardware key, with user verification required. Multi-factor is available by authenticator app, by emailed code, or by text message. Businesses on the larger plans can attach their own identity provider, and a domain has to be verified by DNS before it can be claimed. Removing someone revokes their access immediately rather than waiting for a session to expire.

File storage is encrypted, a web application firewall sits in front of the platform, and deleting your workspace is a real deletion: owner only, and you have to type the workspace name to confirm it, the same way GitHub and Stripe handle the same decision.

Straight answers to what people actually ask.