Skip to content

Approvals and the safety model

The promise underneath everything else is short: Bartimaeus asks before it acts. This page explains what that means in practice — and what it does not promise.

The gates live in the service, not in the model

Most "AI safety" is a request to the model to behave. Ours is not. Every tool call your agent makes passes through a policy check in Bartimaeus itself before it runs. The model can propose an action; it cannot approve one, skip the check, or talk its way past a gate. If the policy says a step needs your permission, the run stops and waits no matter what the model "thinks".

Read-only by default

Where a service allows it, Bartimaeus connects with read-only access. The strictest example is the one that matters most: Gmail is read-and-draft only. A draft stays a draft until you tap send. Reading is the one class of step that can run without interrupting you — it changes nothing. Anything that writes, sends, shares or posts is gated.

How an approval works

  1. Your agent reaches a step that needs you. The run pauses — it does not proceed and then tell you.
  2. You get a notification when the app is closed or in the background. If you are in the app already, the conversation holding the card is marked in your chat list — open it to decide.
  3. The card tells you what it plans to do — which service, which action, the details that matter — so you can decide with the facts in front of you.
  4. You approve or deny with one tap. The decision is recorded once; if you have the same account open on another device, a decision made on one device is honoured everywhere.
  5. If you deny, the action does not run. Your agent is told plainly that it does not have that access, and it carries on with the rest of the task without it — a denial is a redirection, not a dead end.
  6. Cards wait for you. An undecided card does not time out and quietly expire; it stays decidable until you act, or until you stop the run.

Sends are their own class

Anything that sends, shares or posts to another person — an email, a message, a public reply — gets a fresh card of its own, every time. These are never automatic, never bundled together, and never pre-approved once and forgotten. You see exactly what will go out, and you approve it.

Stopping things

  • The stop button. While a run is working, the send button becomes a stop button. It ends the run immediately — including cancelling any approval card that run was waiting on. Nothing happens after a stop.
  • Kill switches. Every connected app has its own switch. Turning one off disconnects that service; your agent can no longer reach it, even inside a running request.
  • No always-on process. Sessions exist only while work is happening and stop when it is done — there is no background loop doing anything at 3am.

What the agent cannot do

  • Arbitrary code. Your agent can only use the tools it has been given — a curated set that grows deliberately. It cannot run scripts, install software, or execute code of its own making.
  • Anything on your computer. Bartimaeus runs in the cloud. It never installs or runs software on your machine.
  • Touch your money. Bartimaeus has no access to payments at all — no card numbers, no bank connections, no purchase powers.
  • Wander outside your apps. It sees only what you have connected, and what it is allowed to read there.

Fetched content is data, never instructions

The web is full of text that tries to boss AI agents around ("ignore your instructions and…"). Bartimaeus treats every fetched page, email and document as data — something to read and reason about — never as a command. Instructions only ever come from you.

Your key and your approvals stay yours

Your AI key is stored encrypted, under a key that belongs to your account only, and it is never shown to the model. Approvals are recorded against your account and are decided by you alone. You are in charge of what you approve — the final word is always yours, which is exactly why the cards are designed to be read before they are tapped.

Honest scope

Three things this page does not claim:

  • Not every action is reversible. Undo exists where the underlying service supports it; a sent email cannot be un-sent. That is why sends get their own card. Receipts and undo covers what the record shows.
  • Approval design is deliberate about fatigue. Cards only appear for steps that need a decision, and the details on them are chosen to help you decide quickly rather than to train you into tapping without reading.
  • You remain responsible for what you approve. The rails make sure nothing happens without you; they do not make decisions for you.

If a notification never arrived or a card seems missing, the Troubleshooting page has the fixes.