Product

Decide what the agent may send

Permission levels, an approval queue bound to the exact draft, recipient rules, and one switch that stops everything.

The interesting failure mode is not an agent that cannot send email. It is an agent that sends the wrong email to the wrong person, confidently, at three in the morning. These are the controls that exist in the application code to make that a decision rather than an accident.

Three levels of access

A grant covers named inboxes, not a workspace. Authority is re-derived on every request and intersected with the authorising human's current permissions, so a grant can only ever shrink.

01

Read only

The agent can list inboxes and threads and read message bodies. It has no tool that can produce mail — the send tool is not even listed to it.

02

Read and draft

The agent composes, and a person releases. A draft cannot transmit mail; the send scope is stripped from the credential the draft path runs under.

03

Read and send

The agent can transmit — but still through the inbox policy. A send-capable credential does not override a rule that says hold this one.

Approval is bound to the exact draft

Approving is not granting. It authorises one message, with that body, to those recipients.

  • You see what you are approving. Recipients, the full content, the reason the message was held, and the exact draft version.

  • Edits invalidate the approval. The decision is tied to a hash of the payload. If the content changes after you approve, the send fails with a version conflict rather than going out as something you never read.

  • Requests expire. An approval request that nobody answers within 7 days lapses instead of sitting there indefinitely.

  • Rejecting is a first-class outcome. Reject with an optional note; the agent gets an event, not silence.

Why a message gets held

Each inbox has its own Sending controls. When a send is intercepted, the API and the console return the reason code, so an agent can act on it rather than guess.

send_disabled
Outgoing mail is paused for the whole project.
blocked_recipient
The recipient is on the inbox's block list.
recipient_not_allowed
An allow list is set and this recipient is not on it.
always
The inbox holds every outgoing message for review.
new_recipient_domain
First message to this domain from this inbox.
attachments
The message carries one or more attachments.

Owners and administrators can also set a daily cap on live recipients, and pause outgoing email for an entire project in one action. Direct sending stays the default for a send-capable credential until a policy asks for review.

Taking access back

Revocation is a normal operation, not an incident procedure.

Agent grants

Revoke a connection under Connections. Grants also expire on their own after 30 days, so an abandoned integration stops working rather than lingering.

Replaying a refresh token revokes the whole grant, on the assumption it was stolen.

API keys

Revoke a key under Developers. Secrets are digested and shown once, so a leaked key is replaced rather than recovered.

Requests presenting a revoked credential lose access on the next call.

The whole project

Pause outgoing email for the project. Mail keeps arriving and stays readable; nothing leaves.

Every send attempt during a pause comes back as send_disabled.

What these controls are not

These are application permissions, not a guarantee that an agent will make good decisions. Nothing written in an inbound message can widen a grant — scopes are re-derived from the database on every request — but an agent can still be argued into a bad draft, and we make no claim to be prompt-injection proof. Choose the client you authorise and the recipients you allow with that in mind, and keep review switched on where a wrong message is expensive. What the code enforces, in full.

Guides about permissions and approvals

Try it with a test inbox first — nothing can reach a real person.

Create an inbox See the recipes