An Email AI Agent Control Plane is a way to let an agent read, draft, and sometimes send email while every action is constrained by policy-as-code and leaves auditable evidence. In Claw EA, OpenClaw is the baseline agent runtime, and Claw Bureau primitives let you bind each email job to a Work Policy Contract (WPC) and a scoped token (CST) so the agent cannot exceed the permissions you actually intended.
Email is high impact because a single bad send can become a breach, a fraud event, or a compliance incident. Prompt-only controls are not sufficient because the prompt is not a security boundary; the execution layer must be permissioned so tool calls and model calls are enforced and provable.
Step-by-step runbook
-
Decide the email surface and identity model. For Microsoft 365, plan to use Entra ID app registration and Microsoft Graph permissions/scopes that match the minimum mailbox access you need, plus Conditional Access and PIM where appropriate.
If you are not on Microsoft 365, define the equivalent with your provider via official API or enterprise buildout.
-
Write a channel-specific WPC that describes what the agent can do in email. Include allowed mailboxes, allowed recipient domains, attachment rules, and whether “send” is allowed or must be a human-approved step.
Store the WPC in the WPC registry so it is signed and hash-addressed, and reference it by hash in runs.
-
Issue a CST for the job from clawscope, with a scope hash that matches the email channel policy you expect. Optionally pin the policy hash to the WPC hash so the run fails closed if the policy changes.
Use job-scoped CST binding to prevent replay of the same token across runs.
-
Run the agent through clawproxy for model calls so every model request yields gateway receipts. If you route models via OpenRouter via fal, keep that traffic routed through clawproxy for consistent receipt emission.
This is what makes post-incident reconstruction feasible without trusting local logs alone.
-
Implement the email tool surface as “read and draft” first. Treat “send” as a separate tool or separate step that can be implemented to require an explicit human confirmation, typically by presenting a draft summary and recipients in the chat UI.
If you need richer approval flows, that is typically an enterprise buildout, but the same WPC and CST binding apply.
-
Enable OpenClaw sandboxing for any tool execution that touches files or templates (for example, building an attachment from a report). Keep the tool allowlist small and avoid elevated execution unless you have a clear operational reason.
Run OpenClaw security audit regularly, especially after changing channel exposure or tool policies.
Threat model
Email agents fail in predictable ways: they get socially engineered, they over-share, or they send to the wrong place. Your goal is to make the safe path the default, and make violations fail closed at the execution layer, not “hopefully” at the prompt layer.
| Threat | What happens | Control (operational) |
|---|---|---|
| Prompt injection in an inbound email | The agent is instructed to forward mail, reveal content, or change payment instructions. | WPC restricts actions to specific tools and mailboxes; CST scope hash enforces the job’s allowed operations. Keep “send” gated, and treat external forwarding as disallowed unless explicitly whitelisted. |
| Overbroad Microsoft Graph permissions | An agent credential can read or send across more mailboxes than intended. | Use least-privilege Graph permissions/scopes and narrow mailbox access. Pair with Entra ID controls (Conditional Access, PIM) to reduce standing privilege, and keep the agent’s app identity separate from human users. |
| Recipient or domain typo | Sensitive content is sent to a wrong domain or personal address. | WPC enforces allowed recipient domains and max recipients per message. In the UI, show a pre-send recipient list and require an explicit confirmation step when “send” is enabled. |
| Data exfiltration through model calls | The agent pastes email contents into a model call that is not governed the way you expect. | Route model calls through clawproxy to produce gateway receipts, and use CST plus policy hash pinning to keep the run bound to a specific WPC. Redact or summarize at the tool boundary before content reaches the model when feasible. |
| Replay of a prior authorization | A token or job credential is reused to run the same action again. | Use marketplace anti-replay binding (job-scoped CST binding) so the CST is tied to a single job context. If a run must be repeated, re-issue a new CST for the new job. |
Policy-as-code example
This example shows an email-specific WPC intent: read and draft are allowed, and send is only allowed to approved domains with a small recipient limit. The enforcement point is the execution layer, where tools must validate policy before acting, rather than trusting the model prompt to behave.
{
"wpc_version": "1",
"channel": "email",
"mailbox": {
"allowed_mailboxes": ["ap@corp.example", "support@corp.example"],
"allowed_folders": ["Inbox", "VendorInvoices", "Tickets"]
},
"actions": {
"read": true,
"draft": true,
"send": {
"enabled": false,
"note": "Implement as a separate, human-confirmed step (enterprise buildout) if needed."
}
},
"outbound_constraints": {
"allowed_recipient_domains": ["corp.example", "vendor.example"],
"max_recipients": 3,
"allow_external_forwarding": false,
"allow_attachments": false,
"subject_prefix_required": "[ClawEA]"
},
"model_routing": {
"require_clawproxy": true,
"cst_policy_hash_pinning": true
}
}
In Microsoft 365 environments, map “mailbox access” to Graph permissions/scopes and mailbox-specific access patterns where possible. The WPC is your portable contract; the Graph configuration is the identity layer you must align with it.
What proof do you get?
For each model call routed through clawproxy, you get gateway receipts that can be retained for verification. A proof bundle ties those receipts to the run metadata, including the WPC reference and the CST scope hash, so you can answer “what policy was in force” and “what model calls occurred” without relying on ad hoc logs.
Because runs are bound to job-scoped CST binding, you also get an anti-replay posture: a receipt set from one job is not meant to be reusable as authorization for another job. When you need to share evidence with auditors or internal reviewers, store the proof bundle in Trust Pulse for consistent viewing and retrieval.
Rollback posture
Email incidents require fast containment. Your rollback plan should assume the model can be wrong and that the inbox can contain hostile content, then focus on stopping further actions and preserving evidence.
| Action | Safe rollback | Evidence to capture |
|---|---|---|
| Stop outbound actions | Disable the “send” tool path and re-run with a WPC that only allows read and draft. If “send” is required, restrict to an allowlisted domain set and require explicit confirmation. | Proof bundle for the incident job, plus the WPC hash that was active. |
| Constrain identity and permissions | Reduce Graph permissions/scopes and mailbox reach in Entra ID, then re-issue a new CST for the constrained job. Avoid reusing an old CST across runs. | Gateway receipts showing model calls around the time of the incident, and the CST scope hash used by the job. |
| Reproduce and audit what happened | Re-run the same inputs in a non-sending, sandboxed mode to validate that the agent’s behavior is now constrained. Keep OpenClaw tool policy tight and avoid elevated execution during reproduction. | Incident proof bundle, plus the new proof bundle from the reproduction run for comparison. |
| Policy rollback | Pin policy hash to the known-good WPC for production jobs so an accidental policy change causes fail-closed behavior. Introduce policy changes as new WPC hashes, not in-place edits. | Old and new WPC hashes and the proof bundles that reference them. |
FAQ
Why can’t I secure an email agent with a good system prompt?
A prompt can be ignored or manipulated, especially when the agent reads untrusted email content. Policy-as-code enforces permissions at the tool and proxy layers, where a disallowed send or forward can be blocked even if the model asks for it.
How does this work with Microsoft 365 mailboxes?
You typically use Entra ID for the agent identity and Microsoft Graph permissions/scopes for mailbox access, configured to least privilege. Claw EA then binds the runtime behavior to a WPC and CST so the agent’s execution is constrained even when the upstream identity is capable.
What shows up in the chat UI for approvals?
A common pattern is that the agent posts a structured draft summary: recipients, subject, and the exact body to be sent. The “send” step can be implemented as a separate confirmation action (enterprise buildout), and the run remains tied to the same WPC and CST constraints.
What evidence do I have after an incident?
You can retain gateway receipts for model calls and package them into a proof bundle with the job metadata, including the WPC reference and CST scope hash. You can also store the artifact in Trust Pulse for later review.
Do you require Docker sandboxing for email agents?
No, but it is a practical reduction in blast radius when tools touch local files or templates. OpenClaw separates sandboxing, tool policy, and elevated execution so you can be explicit about what runs where.