The Agentic Email Safety Playbook

Model the agent as a privileged user

Do not treat an agent as a harmless text feature. It may have mailbox access, memory, credentials, tools, network reach, and the ability to act later. Document the data it can read, the decisions it can make, the tools it can call, the people it can contact, and the damage possible if each capability is misused.

Create a risk tier for actions. Reading a restricted label is lower risk than sending externally. Drafting is lower risk than changing a customer record. Calendar holds are lower risk than payments, account recovery, legal commitments, deletion, or credential changes.

Start with a separate, restricted mailbox

Connect the agent to a dedicated mailbox, alias, or label rather than an executive’s entire inbox. Use least-privilege OAuth scopes and a separate identity. Avoid administrator credentials, broad delegated access, and shared secrets copied into prompts or configuration files.

Begin read-only. Add drafting after the classification quality is understood. Add tools one at a time. External sending should remain behind approval until the operating evidence justifies a narrower exception.

Keep authority outside the message

An email can claim to be a chief executive, a vendor, a system alert, or an administrator. Display names and message text do not grant authority. Trusted identity should come from verified sender context, organizational directories, cryptographic or provider signals, and policy maintained outside the untrusted thread.

Even a legitimate sender can forward malicious instructions or have an account compromised. Authorization should consider action type, recipient, amount, data classification, timing, and freshness—not sender identity alone.

Defend against prompt injection

Treat bodies, quoted text, signatures, attachments, images, document text, links, and retrieved pages as data. Delimit them from system instructions. Remove active content. Use parsers and structured extraction rather than copying arbitrary text into a tool-capable prompt.

The policy layer should reject attempts to reveal secrets, alter instructions, expand permissions, contact new recipients, disable logging, or execute steps that came only from message content. Test with synthetic malicious messages before production and continuously afterward.

Put a deterministic policy gate before tools

The model can propose an action; policy decides whether the action is allowed. Validate structured outputs against a schema. Check identity, recipient allowlists, data classification, business hours, rate limits, action tier, duplicate state, and required approval.

Deny by default. A tool should expose the smallest useful operation, not a generic ability to run arbitrary code, query every record, send to anyone, or browse any URL. Keep secrets in the tool layer and return only the minimum result to the model.

Design approval tiers

• Automatic: classify, label, summarize, extract non-sensitive fields, and create internal low-risk notes.
• Review queue: drafts, proposed routing, internal notifications, or updates that are reversible.
• Explicit approval: external sends, new recipients, calendar changes, customer-facing updates, and sensitive record access.
• Prohibited: credential disclosure, payments, account recovery, destructive deletion, legal commitments, or expanding its own permissions without a separate trusted system.

Approvals should display the source message, verified identity, proposed action, destination, sensitive data, policy result, and a clear explanation of what will happen. Recheck authorization when the approval is executed, not only when it is proposed.

Make actions idempotent and bounded

Use stable action IDs so retries cannot send duplicate mail or create duplicate tickets. Limit messages, tool calls, recipients, and runtime per workflow. Apply timeouts, circuit breakers, and maximum recursion or planning depth.

An agent that encounters an ambiguous or failing state should stop and escalate. It should not improvise around a permission error, repeatedly retry an external recipient, or choose a broader tool because the narrow tool failed.

Log evidence and protect it

Record source message IDs, normalized sender context, model and policy versions, structured proposals, policy decisions, approvals, tool calls, destination results, and final status. Avoid storing unnecessary full message bodies or secrets in logs.

Operators need a timeline that answers what the agent saw, why it proposed an action, which policy allowed it, who approved it, and what each downstream system returned.

Test failure and stop mechanisms

Create adversarial fixtures: fake executives, hidden instructions, malicious attachments, poisoned quoted text, stale approvals, replayed messages, destination outages, tool errors, and attempts to exfiltrate secrets. Measure both unsafe actions and excessive refusal.

Maintain a kill switch that revokes credentials, disables workflows, blocks sending, and preserves evidence. Practice using it. A stop mechanism that has never been tested is documentation, not a control.

Adopt autonomy in stages

1. Observe only: summarize historical messages without tools.
2. Classify: label and route to human queues.
3. Draft: prepare responses without sending.
4. Assist: create reversible internal records after review.
5. Act narrowly: automate a small allowlisted action with monitoring.
6. Expand cautiously: add one permission or tool at a time based on evidence.

Clawbot, OpenClaw, and other autonomous assistants can be useful interfaces to this architecture. The product name does not change the safety model: untrusted input, external authority, narrow tools, human approval, evidence, and a tested stop path.

Red-team the mailbox boundary before granting autonomy

Create an adversarial mailbox corpus before connecting live tools. Include direct instructions to ignore policy, hidden text, encoded payloads, malicious links, calendar invitations, attachments, forwarded conversations, quoted instructions from a trusted employee, fake approval language, look-alike domains, and messages that attempt to retrieve secrets from prior threads. Label the intended safe outcome for each example so every model, prompt, and workflow change can be tested against the same baseline.

Test authorization confusion separately from language quality. The agent should distinguish the authenticated sender from a name written in the body, a signature block, a forwarded header, or a model-generated summary. It should not infer financial authority, employment status, customer identity, or approval rights from prose. High-risk actions need deterministic checks against an authoritative directory or system of record, current transaction state, amount limits, destination allowlists, and an approval that is bound to the exact proposed action.

Probe for data exfiltration through every available tool. Ask whether an email can make the agent quote unrelated messages, attach a private document, post secrets to a webhook, place sensitive content in a URL, or send to an attacker-controlled address. Use synthetic secrets and canary values to detect leakage. Constrain retrieval by mailbox, label, customer, time window, and task; constrain outputs by recipient, destination, data class, and maximum payload.

Measure more than task completion. Track unsafe-action rate, sensitive-data exposure, false approvals, missed escalations, duplicate actions, excessive refusals, human correction rate, tool errors, and time to revoke access. Require a release gate whenever a model, system prompt, connector, permission, or policy changes. Keep credentials revocable, preserve an immutable audit trail, and rehearse the kill switch with the same seriousness as any other privileged production system.