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.
Product
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.
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.
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.
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.
The agent can transmit — but still through the inbox policy. A send-capable credential does not override a rule that says hold this one.
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.
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_disabledblocked_recipientrecipient_not_allowedalwaysnew_recipient_domainattachmentsOwners 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.
Revocation is a normal operation, not an incident procedure.
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.
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.
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.
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.
Give an agent the smallest useful email permission: project and inbox scoping, one-time secrets, draft-only grants, rotation, and revocation you can verify.
When to require review, why approval binds to one exact draft version, how recipient rules and daily caps work, and what editing a draft does to its approval.
Any stranger can email your agent. What an email-borne injection looks like, why message text must never grant permission, and the controls that limit damage.