How governance works
What the agent is allowed to do — and how that limit is enforced.
This is the page a compliance or security reviewer reads end to end. It sets out exactly how Mailbuttons governs what an AI agent can do with email: who grants its permissions, where the limits are enforced, what happens to a message before the model reads it, and what record survives afterwards. No marketing shorthand — the mechanisms, in the order they apply.
See it working
Each clip is the recorded output of an automated end-to-end test that runs against the real product. Nothing is staged: if a journey broke, its test would fail and the video would come down.
The shadow-mode assessment
Point real inbox traffic at the agent and watch what it would do — every reply it drafts is held back, nothing is sent, and you get a report of exactly how it would have handled your inbox. Proof before you hand over a single message.
Approve by email
The agent drafts a reply but can't send it. A named person gets an email, reads it, and clicks to approve — and only then does it go out. The AI never releases its own messages.
The misdirected document that can't happen
The agent tries to send a document to a counterparty it isn't cleared to email. It doesn't go out — the send is stopped before it leaves, and the attempt stays on the record. The costly mistake simply can't happen.
The audit trail a compliance reviewer verifies
Every message the agent touches is written to a sealed, tamper-evident record. Your auditor can re-check the whole chain and confirm nothing was altered.
The agent asks; a person decides
The agent hits the edge of what it's allowed to do and asks for a specific, named permission. A person reviews the request and grants or refuses it. The AI never widens its own authority.
The capability model
Every capability an agent holds is granted by a named person. An agent does not provision its own inbox, add itself to an allowlist, or widen its own permissions — it operates strictly inside limits an administrator set for it. This is the deliberate inverse of a self-provisioning agent-email tool, where the agent signs itself up and starts sending on its own authority.
Permissions are scoped, not granted wholesale. For each mailbox an administrator defines which senders the agent will act on, which topics or request types it may handle, and which actions it may take — reply, forward, distribute a document, hold for approval. The default action for an unrecognised sender or an out-of-scope request is to bounce or escalate, not to proceed: the policy is fail-closed. Anything the administrator has not explicitly allowed, the agent cannot do.
Because the grant is human and the scope is explicit, there is always a person accountable for what a given agent is permitted to do. When a reviewer asks "who decided this agent could send to that counterparty?", the answer is a named administrator and a policy version — not the model.
The policy gate
The limits are enforced server-side, outside the model. Every outbound action the agent attempts is evaluated against the mailbox's policy by code that runs on our servers before anything leaves. The model proposes; the gate decides. Because the check lives outside the LLM, it cannot be argued with: no prompt, however cleverly written, talks the agent past a rule, because the rule is not evaluated by the thing reading the prompt.
A send to a recipient who is not on the mailbox's approved counterparty list is refused at the gate — the message is never transmitted. The same gate enforces the other scoped limits: which actions are permitted, and per-sender rate and cost budgets. An action the policy does not allow is blocked, and the block itself is recorded (see the audit log below) — a refused send is signal, not something swept away silently.
Where a policy holds an action for human approval rather than allowing it outright, the agent produces a draft and stops. The draft is not sent until a person releases it. The model has no path to release its own held drafts.
Inbound verification and content guards
Email lets anyone write to your agent, and a sender's name can be faked. So an inbound message is checked on our servers before the model reads a single word of it. Two checks run in order, and either can turn a message away before it reaches the agent.
Sender authentication (SPF, DKIM, DMARC)
We read the standard email-authentication results for each inbound message — SPF, DKIM and DMARC, plus whether the From address aligns with the authenticated domain. A message that fails the authentication your policy requires is rejected at verification and never handed to the model. This is how the agent knows a sender is really who they claim to be, rather than trusting the display name.
Content guards (prompt-injection screening)
A message that passes authentication is then screened against the mailbox's content guards for the tell-tale shape of a prompt-injection attempt — instructions buried in the body that try to redirect the agent, exfiltrate data, or override its policy. A message that trips a guard is rejected at the content stage, again before the model reads it. A stranger cannot smuggle instructions into your agent through an email body, because the body is inspected before the agent ever sees it.
Only a message that clears both checks reaches the model — and even then it is subject to the capability scope and the policy gate above. Verification verdicts and guard outcomes are recorded on every message, whether it was delivered or turned away.
The audit log
Every decision leaves a row: what arrived, whether the sender checked out, what the agent decided, what it cost, what was sent — and every block and every denial, not just the successes. The log is what lets you put an agent on the inbox and still answer a reviewer's questions after the fact.
The log is tamper-evident by construction. Entries are hash-chained per customer: each row's hash is computed over its own contents together with the hash of the previous row, so the rows form a chain. Editing or deleting any row changes its hash and breaks the link to every row that follows — the tampering is detectable by recomputing the chain, which the export lets you (or your SIEM) do independently. You cannot quietly alter history and leave the log looking intact.
The record is exportable to the security tooling you already run — Splunk, Datadog, Elastic — and retained for as long as your regulator requires. On the Business tier the tamper-evident chaining and seven-year retention apply.
Illustrative example — not real customer data
# Illustrative audit-log excerpt. Values are examples (example.com # addresses, fabricated hashes) to show the shape of the record — NOT # real customer data. Each entry_hash chains to the previous prev_hash. [2026-07-08T09:14:22Z] mailbox=ops-inbox [email protected] [email protected] spf=pass dkim=pass dmarc=pass from_aligned=true outcome=delivered reason="sender on approved list; nomination" tools_used=[classify, draft_reply] held_for_approval=true prev_hash=8f3c…a91d entry_hash=2b7e…44c0 [2026-07-08T09:15:03Z] mailbox=ops-inbox action=send_reply [email protected] decision=draft_pending_approval reason="topic=nomination requires human release" cost={tokens_in:1840, tokens_out:210} prev_hash=2b7e…44c0 entry_hash=c05a…9f12 [2026-07-08T10:02:47Z] mailbox=ops-inbox action=send_document [email protected] decision=blocked reason="recipient not on mailbox approved-counterparty list" prev_hash=c05a…9f12 entry_hash=6d41…e7ab [2026-07-08T11:31:10Z] mailbox=ops-inbox [email protected] [email protected] spf=fail dkim=none dmarc=fail from_aligned=false outcome=rejected_at_verification reason="DMARC fail; message not handed to model" prev_hash=6d41…e7ab entry_hash=1a90…3c58 [2026-07-08T13:47:55Z] mailbox=ops-inbox [email protected] [email protected] spf=pass dkim=pass dmarc=pass from_aligned=true outcome=rejected_at_content_guard reason="content guard tripped: embedded instruction override attempt" prev_hash=1a90…3c58 entry_hash=e3f8…20d7
The fields shown — sender and recipient, the SPF/DKIM/DMARC verdicts and From-alignment, the outcome and reason, the tools used, token cost, and the prev_hash / entry_hash chain links — mirror the columns the product actually records. The values are invented for illustration.
Data residency and security posture
Mailbuttons is operated by a UK company. Customer data — the contents of email passing through your mailboxes and the audit logs derived from it — is stored within the United Kingdom and European Economic Area. We are the EU/UK vendor, not a US service wrapped in EU paperwork.
We do not use customer data to train models. LLM inference is used only when the hosted-agent feature is enabled, under Standard Contractual Clauses; a customer can disable it, in which case no customer email content leaves the UK/EEA.
Our ISO/IEC 27001 information-security policy set is authored to the 2022 control framework, published in full, and in force today. Formal certification is planned for 2027 — a deliberate early-adopter position, stated plainly rather than dressed up as a completed audit. You can read the controls now, and the full procurement posture — sub-processors, data-flow, incident response — in the Trust Center.
When governed is the wrong choice
This model is not free. A human-granted, fail-closed, server-side-enforced boundary is more setup and more friction than handing an agent an inbox and letting it run. That friction is the product — but it is only worth paying for in one situation.
If you are building a consumer product, a prototype, or anything where an agent acting on its own authority is acceptable and mistakes are cheap to undo, a self-provisioning agent-email tool is the right call, and it will be faster. Tools like AgentMail optimise for exactly that — an agent can sign itself up and start sending in seconds. For many products that is the correct trade, and we would point you to them without reservation.
Mailbuttons is built for the opposite case: where a wrong recipient or a wrong figure is commercial and legal exposure, where a named person has to be accountable for every message sent, and where a compliance reviewer will ask to see the record before the agent goes anywhere near a system of record. If that is your situation, the governance on this page is the reason you can say yes at all. If it isn't, you probably don't need us yet.
See it applied to your own inbox
A shadow-mode assessment runs these mechanisms against your real traffic without sending anything: one forwarding rule, nothing migrates, nothing leaves. You see what the agent would have handled, what the guards caught, and the audit record it would have written.