OpenAssistantAPI
→

Guardrails

The limits that hold no matter how you set Autonomy and Supervision, and which of them are enforced in code.

Autonomy decides what your assistant does on its own. Supervision decides how much you see while it does it.

This page is about what holds regardless of either — the limits that stay in place whether you run Supervised or Unsupervised. Where a limit is enforced in code, it says so. Where something is policy or still being built, it says that too.

Nothing consequential leaves without passing the cart

Outbound actions are staged in the dispatch cart rather than fired as they are composed. You see the actual message, with real recipients, before it goes.

The important part is structural: your assistant has no way to send directly. It is not that sending without review is discouraged; the capability does not exist in its toolset. Everything outbound travels the same path, and that path is where your Autonomy settings decide whether it goes straight out or waits for you.

That applies per resource — Email as Me, Email as Assistant, Text Messages, Phone calls and Calendar are set independently, so you can let routine calendar work run while keeping email as yourself on manual. Writes to connected file storage go through the same approval path.

Setting Autonomy to Unsupervised does not remove the cart. It changes what the cart does without you.

Your words are not rewritten after you approve

For messages, no AI model runs between your approval and the send. What you read is what goes out.

Some things are still added on the way, and it is better to know which: your signature if it is missing, threading so the message lands on the right conversation, and — if your Supervision setting puts you on outbound mail — you as a CC or BCC recipient. None of that touches the words you wrote.

Phone calls are different. A call is generated live from the objective you approved, not read from a script. If that distinction matters for a particular call, send a message instead.

Your assistant cannot widen its own remit

Three limits, all enforced in code:

  • It cannot approve its own work. Anything it creates that would need your approval still needs it. There is no self-sign-off path.
  • It cannot loosen its own Autonomy or Supervision settings. No instruction — however it is worded, and wherever it arrives from — can talk your assistant into supervising itself less. Tightening is allowed; loosening is blocked at the platform level, on every path we have.
  • It cannot install new capabilities by itself. Adding a skill or workflow is something you approve.

The second matters more than it sounds. Most attacks on an assistant are attempts to talk it into something, and the usual target is its own oversight.

Requests that look unusual are held, not acted on

Inbound email must prove it is genuinely from who it claims before your assistant sees it; forgeries are rejected before they reach the assistant at all.

Past that, a request that looks unusual for the person making it is held and referred to you rather than carried out — regardless of your Autonomy setting. Your assistant will tell you it is checking with you rather than going quiet.

We will not tell you the assistant cannot be manipulated — nobody honest will. We will tell you what is checked and what happens when a check fires.

One switch stops everything

If something looks wrong, an account-wide stop halts every pending and in-flight action immediately. Releasing it is something only you can do from your own account — your assistant cannot lift it, and neither can anyone talking to it.

What is not enforced yet

Being straight about the edges, because a limit you believe in and do not have is worse than no limit:

  • Command-line and browser use are not covered by the Autonomy settings. Where your assistant can run commands or drive a browser, those actions are guided by instruction rather than restricted by a setting. See security controls if that matters for your organization.
  • Third-party tool calls do not appear in the cart. Connection policies decide whether a service is connected, which is a real control. Individual calls to an already-connected service are not staged for approval the way an email is.
  • Automatic flagging of unusually large actions is designed but not built. Bulk operations are bounded by your Autonomy settings today, not by a separate size check.

Related