This workflow lets an OpenClaw agent draft and send customer emails only when DLP checks pass and a human approves the final payload. Claw EA makes the execution permissioned with policy-as-code so the agent cannot bypass controls using prompt tricks or tool misuse.

The core mechanism is a WPC (Work Policy Contract) that constrains which tools can run, what data can appear in outbound content, and when step-up approvals are required. Each model call routed through clawproxy produces gateway receipts, which are packaged into a proof bundle for later verification and audit.

Step-by-step runbook

Use this when an agent is allowed to communicate with customers but you want strong controls on outbound email and attachments. The intent is to make “drafting” cheap and reversible, and make “sending” gated and provable.

  1. Define a WPC for customer communications. Encode allowed tools (draft, classify, redact, prepare email), deny direct send by default, and require approval for any irreversible action. Store the signed, hash-addressed WPC in the WPC registry served by clawcontrols.

  2. Issue a CST for the job, pinned to the policy. Use clawscope to mint a CST (scoped token) with a scope hash matching the workflow’s privileges, and optionally pin the WPC policy hash. Bind the CST to the job to prevent replay across runs.

  3. Run the agent in a sandboxed tool environment. In OpenClaw, enable sandboxing for tool execution so file and process access are reduced during drafting and analysis. Keep “send email” out of the default tool profile, and expose it only via a gated tool that enforces approvals.

  4. Draft with DLP and redaction in the loop. The agent generates a draft, then runs DLP classification and redaction rules over the outgoing body, subject, recipients, and attachment names. If the content includes restricted patterns, the policy should force redaction or block the send path.

  5. Step-up approval before send. Route the prepared “send request” to a human reviewer with a minimal approval UI that shows recipients, subject, body diff, and attachment hashes. Require explicit approval for external recipients, attachments, refunds/credits language, or any exception to the default output policy.

  6. Send via official API, constrained by policy. If you send through Microsoft, do it via the official API using Microsoft Entra ID and Microsoft Graph permissions/scopes that match the minimum needed. Apply Conditional Access and, if appropriate, PIM for the sending identity so the agent cannot silently gain broad mailbox access.

  7. Collect evidence and publish the run artifact. Route model calls through clawproxy to emit gateway receipts and bundle them with job metadata into a proof bundle. Store the proof bundle and optionally publish a Trust Pulse artifact for audit viewing and internal review.

Threat model

Outbound customer email is high risk because it is hard to undo and easy to abuse for data exfiltration. Treat “send” and “share attachment” as privileged operations that should fail closed when policy checks are missing.

Threat What happens Control
Prompt injection causes unauthorized send The agent is coerced to email sensitive data or contact unintended recipients. Policy-as-code in a WPC denies direct send, requires step-up approval, and enforces recipient allow rules and output redaction.
Data exfiltration via attachments The agent attaches internal files or exports data into a PDF and sends it out. DLP rules block or redact attachment names and content; policy can require “no attachments” unless explicitly approved with hashes shown to reviewer.
Scope creep from broad email permissions A compromised agent token can send as any mailbox or read unrelated mailboxes. Use a CST with a narrow scope hash; for Microsoft, minimize Microsoft Graph permissions/scopes and constrain identity with Entra ID, Conditional Access, and optionally PIM.
Replay of an approved action A previously approved send request is reused to send again or to new recipients. Marketplace anti-replay binding using job-scoped CST binding, plus approval objects bound to job id and policy hash.
Audit gap after an incident You cannot prove what the model saw, produced, or which policy was enforced. Gateway receipts from clawproxy plus a proof bundle that records policy hash, token scope hash, timestamps, and model routing details.

Policy-as-code example

This is a compact, JSON-like sketch of what teams typically encode into a WPC for customer email. The point is to make “send email” conditional on concrete checks and approvals, not on the agent’s own self-report.

{
  "wpc_version": "1",
  "workflow": "customer-email-send",
  "tools": {
    "allow": ["draft_email", "dlp_scan", "redact", "prepare_send_request"],
    "deny": ["send_email_direct", "share_attachment_direct"]
  },
  "output_policy": {
    "recipient_rules": {
      "allow_domains": ["customer.com", "subsidiary.example"],
      "block_free_mail": true
    },
    "dlp": {
      "block_patterns": ["\\b\\d{3}-\\d{2}-\\d{4}\\b", "API_KEY_", "BEGIN PRIVATE KEY"],
      "redact_patterns": ["\\b\\d{16}\\b", "\\b\\d{3}-\\d{2}-\\d{4}\\b"]
    },
    "attachments": {
      "default": "deny",
      "allow_if": ["approved", "hash_listed_in_approval"]
    }
  },
  "approvals": {
    "required_for": ["send_email", "any_attachment", "external_recipient", "policy_exception"],
    "approver_group": "customer-comms-approvers",
    "approval_payload_must_include": ["to", "cc", "bcc", "subject", "body", "attachment_hashes"]
  },
  "token_constraints": {
    "require_cst_scope_hash": true,
    "optional_policy_hash_pinning": true,
    "job_scoped_binding": true
  },
  "model_routing": {
    "proxy": "clawproxy",
    "require_gateway_receipts": true
  }
}

Prompt-only controls fail because the same model that generates the email is also the component you are asking to “behave.” A WPC makes the decision external, machine-checked, and consistent across sessions and model changes.

What proof do you get?

For every model call routed through clawproxy, you get gateway receipts that record the call under the proxy’s signing and policy enforcement context. Those receipts make it possible to verify what was called, when it was called, and which job-bound CST was used.

Claw EA packages gateway receipts plus policy identifiers and run metadata into a proof bundle. The proof bundle is the artifact you hand to security, compliance, or an incident responder to validate that the send path required approval and that the run used the intended WPC.

If you need a shareable audit view, store the run as a Trust Pulse artifact. This gives reviewers a stable place to inspect what was produced and what was enforced, without relying on mutable application logs.

Rollback posture

Email sending is not fully reversible, so rollback needs to focus on preventing additional sends and proving the blast radius. Treat “disable future capability” as the primary rollback, and use evidence to drive customer comms and internal remediation.

Action Safe rollback Evidence
Approval granted but send not executed yet Invalidate the job by revoking or expiring the CST; require a fresh approval under a new job id. Proof bundle shows the last approved payload and the absence of any send execution receipt.
Email sent to wrong recipient Stop further sends by tightening the WPC recipient rules and re-issuing a narrower CST scope hash; escalate as an incident. Gateway receipts identify the run, job binding, and the generated content that led to send approval.
Sensitive data appears in draft output Update DLP redact/block patterns in the WPC and force redaction; retrain reviewers to reject exceptions. Proof bundle ties the output to a specific WPC hash so you can prove which rule set was active.
Suspected token misuse Revoke CSTs and rotate the sending identity; in Microsoft environments, review Entra ID sign-in logs and Conditional Access outcomes. Job-scoped CST binding plus receipts help differentiate replay attempts from legitimate runs.

FAQ

Why is policy-as-code required instead of a careful system prompt?

A prompt is advice to the same component that is generating the risky action. A WPC is a signed artifact enforced outside the model, so “send email” can fail closed when DLP or approvals are missing.

Can this work with Microsoft 365 mailboxes?

Yes, typically via the official API using Microsoft Entra ID and Microsoft Graph permissions/scopes sized to the minimum required. If you need a custom connector surface, do it via an MCP server or an enterprise buildout, and keep the “send” tool gated behind approvals.

What exactly is approved by the human?

Approve the final payload that will be sent: recipients, subject, body, and attachment hashes. Approval should be bound to the job id and the WPC hash so it cannot be reused under different policy or scope.

How do you prevent replays of a previously approved send?

Use marketplace anti-replay binding with a job-scoped CST binding, and require approvals that are only valid for that job. If a request is replayed outside the job context, it should fail policy checks.

What models can be used for drafting?

Claw EA can route model calls through clawproxy and produce gateway receipts regardless of provider, and OpenRouter via fal is supported when routed through clawproxy. The key is that drafting can vary, but the send path remains permissioned and audited.

Sources

Ready to put this workflow into production?

Get a scoped deployment plan with Work Policy Contracts, approval gates, and cryptographic proof bundles for your team.

Talk to Sales Review Trust Layer