Gmail is a high-impact surface for enterprise agents because it combines sensitive data access with the ability to send messages that look official. In Claw EA, you should treat Gmail actions as permissioned execution: a Work Policy Contract (WPC) must explicitly allow what the agent can read, draft, send, label, or delete, and the run must be bound to scoped tokens (CST) so access is least-privilege and revocable.
OpenClaw is the baseline agent runtime, but prompt-only instructions are not an authorization system. You need policy-as-code because Gmail risks come from tool calls, OAuth scopes, and misconfiguration, not just from what the model says it intends to do.
Step-by-step runbook
-
Define the Gmail use case and separate it into read-only and write paths. Treat “send email”, “modify mailbox state”, and “admin-like operations” as distinct capabilities with separate approvals.
-
Implement the Gmail connection via official API with enterprise buildout controls (this is not a native connector by default). Use OAuth or service account patterns appropriate to your Google Workspace setup, and choose explicit least-privilege Gmail API scopes for the path you are enabling.
-
Write a WPC that enumerates allowed Gmail actions, allowed target identities (which mailbox, which domain), and required human gates for high-risk steps. Publish the WPC to the WPC registry so it is signed and hash-addressed.
-
Issue a CST (from clawscope) for the job, and pin the CST to the WPC hash when you want the run to fail closed if policy changes. Use the job-scoped CST binding to reduce replay risk if a token leaks.
-
Run the agent in OpenClaw with a tight tool profile and sandboxing on, then expose Gmail as a single tool with narrow methods. Avoid giving the agent generic HTTP tooling to reach Gmail directly unless you can enforce the same WPC gates on those calls.
-
Route model calls through clawproxy so you get gateway receipts for model calls, then package the run outputs into a proof bundle. Store the proof bundle (or a pointer) in Trust Pulse when you need a durable audit artifact.
Threat model
| Threat | What happens | Control |
|---|---|---|
| Prompt injection via email content | An attacker sends an email that instructs the agent to forward threads, exfiltrate attachments, or change settings. The model may comply if it can reach Gmail tools without hard gates. | WPC rules that limit actions to a safe subset, plus tool policy in OpenClaw so Gmail is not callable outside approved flows. Keep read-only and write capabilities separated, and require approvals for “send” and “modify”. |
| OAuth scope overreach | The integration is authorized with broad scopes, so even a benign bug becomes a mailbox-wide incident. A single token can enable reading and sending across too much data. | Explicit least-privilege auth scopes, documented in the WPC and enforced in review. Use CST scope hash and optional policy hash pinning so jobs cannot silently expand privileges. |
| Impersonation and fraudulent outbound email | The agent sends convincing emails to vendors or employees, creating financial or legal exposure. Reply chains can amplify the impact because the message inherits trust. | WPC approval gates for outbound send, plus constraints like allowed recipient domains, allowed sender identity, and message templates. Add “draft only” mode as the default and require explicit promotion to “send”. |
| Mailbox state corruption | Misconfigured automation marks items as read, deletes messages, or mutates labels at scale. Recovery can be slow and incomplete. | WPC limits on batch size, label namespaces, and disallowed destructive actions by default. Prefer idempotent actions and require human gate for deletes or permanent changes. |
| Token replay across jobs | A leaked token is reused to run new actions outside the original job context. The attacker does not need the original agent state. | Marketplace anti-replay binding using job-scoped CST binding, plus short TTLs and revocation procedures. Bind each job to a specific WPC hash when the operation is sensitive. |
Policy-as-code example
This is a JSON-like sketch of a WPC for Gmail. The point is to make the allowed operations machine-checkable, not implied by a prompt like “only send safe emails”.
{
"tool": "gmail",
"connection": "via_official_api_enterprise_buildout",
"identities": {
"allowedMailbox": "ops-triage@company.com",
"allowedSenderAliases": ["ops-triage@company.com"]
},
"auth": {
"oauthScopes": [
"gmail.readonly",
"gmail.send"
]
},
"actions": {
"read": {
"allowed": true,
"queryAllowlist": ["label:inbox", "newer_than:14d"],
"attachmentPolicy": { "downloadAllowed": false }
},
"draft": {
"allowed": true,
"recipientDomainAllowlist": ["company.com", "trusted-vendor.com"]
},
"send": {
"allowed": true,
"requiresApproval": true,
"maxPerJob": 10
},
"modify": {
"allowed": true,
"labelAllowlist": ["triage/*"],
"deleteAllowed": false
}
},
"jobBinding": {
"requireCST": true,
"pinPolicyHash": true
}
}
In practice, your enterprise buildout should make “send” and “modify” fail closed unless the WPC is present and verified. If the agent lacks WPC approval for a method, the tool should refuse the call even if the prompt asks for it.
What proof do you get?
For model calls, clawproxy emits gateway receipts that can be verified later. This is especially useful when you route OpenRouter via fal through clawproxy, because you can prove which model endpoint was called and when.
Claw EA bundles those receipts with policy and run metadata into a proof bundle. At minimum, you should expect the proof bundle to include the WPC hash that governed the run, the CST scope hash used for authorization, and job identifiers used for anti-replay binding.
Trust Pulse can store and display the resulting artifact for audit viewing. If your Gmail integration is implemented via official API, the Gmail API call evidence typically comes from your integration logs and the Google Workspace audit trail, and can be attached to the same case file alongside the proof bundle in your enterprise process.
Rollback posture
| Action | Safe rollback | Evidence |
|---|---|---|
| Stop new Gmail actions immediately | Revoke the CST and rotate to a new CST policy tier, then publish a new WPC revision that removes Gmail permissions. The agent continues to run, but Gmail tool calls fail closed. | WPC hash change record plus CST issuance and revocation records, and the proof bundle showing which WPC was active for the job. |
| Contain suspected token leakage | Invalidate the OAuth credentials used for Gmail access and re-consent with narrowed scopes. If using job-scoped CST binding, ensure old job tokens cannot be replayed into new jobs. | Proof bundle job metadata plus your OAuth provider logs and the before-and-after scope set documented in the WPC. |
| Undo mailbox state changes | Prefer reversible operations: labels instead of deletes, drafts instead of sends, “archive” with limits. For destructive actions, require approvals and keep batch sizes low so recovery is bounded. | Tool invocation summaries in run logs, Gmail audit trail, and the proof bundle tying the action window to a specific job. |
| Post-incident verification | Re-run verification on the proof bundle, then review gateway receipts to confirm which model calls occurred during the incident window. Use this to separate model behavior from tool authorization failures. | Gateway receipts for model calls and the associated proof bundle stored for the job, optionally published to Trust Pulse for consistent review. |
FAQ
Is Gmail supported as a native connector in Claw EA today?
Not as a default native connector. Gmail can be connected via official API with enterprise buildout controls, and you should treat it as a high-risk tool that requires explicit WPC approval gates and least-privilege auth scopes.
Why is prompt-only control not enough for Gmail agents?
Because the real failure mode is a tool call with broad OAuth scopes, not an “unsafe sentence” in the prompt. Policy-as-code in a WPC makes the authorization boundary explicit and machine-enforced, even under prompt injection.
What should require approval for Gmail?
At minimum: send, delete, bulk modify, forwarding rules, and any action that affects external recipients. Many teams start with “draft only” and then gate “send” behind an approval step written into the WPC.
What do CST and WPC actually change operationally?
A CST scopes what a specific job is allowed to do and can be revoked quickly. A WPC is the signed policy artifact that defines the allowed Gmail actions and constraints, and you can pin the CST to the WPC hash to prevent policy drift during execution.
What audit artifacts should I keep for a Gmail incident?
Keep the proof bundle for the job, including gateway receipts for model calls, plus the WPC hash and CST scope hash that governed execution. Pair that with your Google Workspace audit logs for Gmail API activity and OAuth changes.