Use OpenClaw as the baseline agent runtime to draft release notes and prepare customer notifications, but make the publish and send actions permissioned by policy-as-code. In Claw EA, that permissioning is expressed as a WPC and enforced using CST plus gateway receipts and proof bundles, so you can prove what was proposed, who approved it, and what was actually sent.
Prompt-only controls fail because the same prompt that says “ask for approval” can be overridden by injected content or a tool error path. A WPC makes the execution layer fail-closed: the agent can draft freely, but it cannot publish release notes or email customers unless the policy conditions and approval requirements are satisfied.
Step-by-step runbook
-
Define the workflow boundary: “Draft is reversible, publish is irreversible.” Treat “publish release notes” and “email customers” as high-risk actions that must be gated behind explicit approvals and an output policy.
Decide which surfaces you will use (for example: your docs site CMS, a status page, and an email provider), and plan to integrate via official API or via an MCP server.
-
Create a WPC for the release workflow and register it. The WPC should specify which tools are allowed for drafting, which tool(s) are allowed for publishing, and what approval steps must occur before publish or send.
Keep the WPC narrow: allow read-only access to release artifacts (tickets, commits, changelog files), and block any tool that can mutate production content until approvals clear.
-
Issue a CST for the job from clawscope, scoped to the minimum set of actions. Pin the CST to the WPC (policy hash pinning) so the token cannot be replayed under a different policy.
Use job-scoped CST binding to reduce replay risk across runs, especially for “send” actions.
-
Run the drafting phase in OpenClaw with sandboxing enabled for tools. Drafting can call models and summarize diffs, but it should not have the capability to publish or send yet.
As part of drafting, require the agent to produce a “candidate artifact” that is structured: audience, version, change list, known issues, and a customer-facing email body.
-
Apply DLP and redaction rules before anything leaves the drafting boundary. Enforce redaction on secrets, internal hostnames, customer identifiers, and security-sensitive details that should not be disclosed in release notes.
If your environment uses Microsoft controls, align the human approval step with your existing process (for example via a flow that uses Entra ID identity and Conditional Access), implemented via official API or enterprise buildout.
-
Perform step-up approvals (human-in-the-loop). The approver should see a diff view of the proposed release note and the exact customer notification content, plus the policy summary that explains what will happen when approved.
On approval, re-issue or elevate the CST for a short TTL, still pinned to the same WPC, and allow only the publish and send tools needed for this one run.
-
Execute the publish and send phase through clawproxy so model calls and key execution metadata generate gateway receipts. Store the proof bundle and, if needed for external sharing, write a Trust Pulse artifact for audit/viewing.
After completion, revoke or let the CST expire, and run a post-run check that the published content hash matches the approved artifact hash.
Threat model
| Threat | What happens | Control (operational) |
|---|---|---|
| Prompt injection via release artifact text | The agent is tricked into skipping approvals or adding hidden content to the customer email. | Policy-as-code gates tool execution: WPC denies publish and send until approvals are present. Draft output must pass an output policy and redaction checks before an approval can be requested. |
| Credential misuse | A long-lived token is reused to publish outside the intended job window. | Use CST with short TTL and job-scoped CST binding. Pin CST to the WPC hash so the token cannot be repurposed under a different policy. |
| Over-broad tool access in the agent runtime | The agent can access filesystem, shell, or admin APIs while drafting, increasing blast radius. | Use OpenClaw sandboxing and tool policy to keep drafting tools read-only and isolated. Avoid elevated execution for this workflow unless you can justify it and keep it off by default. |
| Data leakage in release notes | PII, secrets, internal URLs, or incident details leak into public release notes. | DLP and redaction rules are enforced before approvals and again before publish. Require a “public-safe” checklist in the approval UI and block publish on any unresolved redaction findings. |
| Repudiation after a bad send | Teams cannot prove what the model saw, what was approved, and what content was sent. | Route model calls through clawproxy to emit gateway receipts. Package receipts, policy hash, CST scope hash, and run metadata into a proof bundle for later verification. |
Policy-as-code example
This is a compact, JSON-like sketch of a WPC that separates drafting from irreversible actions. The key idea is that the agent may draft, but publishing and sending require step-up approvals plus output policy checks, enforced at execution time rather than requested in a prompt.
{
"wpc_version": "1",
"policy_name": "release-notes-to-customers",
"risk": {
"irreversible_actions": ["publish_release_notes", "email_customers"],
"step_up_approval_required": true
},
"token_constraints": {
"require_cst": true,
"require_scope_hash": true,
"policy_hash_pinning": "required",
"job_scoped_binding": "required"
},
"tools": {
"draft_phase": {
"allow": ["read_repo", "read_tickets", "model_call", "render_markdown"],
"deny": ["publish_release_notes", "email_customers", "admin_api"]
},
"publish_phase": {
"allow": ["publish_release_notes", "email_customers"],
"conditions": [
{"type": "approval", "role": "release_manager", "min_approvers": 1},
{"type": "approval", "role": "security_or_comms", "min_approvers": 1},
{"type": "output_policy", "must_pass": ["dlp_redaction", "no_secrets", "no_internal_hosts"]},
{"type": "artifact_hash_match", "approved_hash_required": true}
]
}
},
"logging": {
"require_gateway_receipts_for_model_calls": true,
"proof_bundle_required": true
}
}
What proof do you get?
For every model call routed through clawproxy, you get gateway receipts that can be checked later to confirm the call happened under the expected policy constraints. These receipts are signed, and they bind to the job context so they are meaningful in an audit.
At the end of the run, Claw EA produces a proof bundle that packages gateway receipts plus related metadata like the WPC hash, CST scope hash, and run identifiers. If you need a human-friendly view for auditors or internal review, you can store and view the run as a Trust Pulse artifact.
This matters operationally when a customer reports “you announced X” or “you emailed the wrong segment.” Instead of reconstructing from logs and chat transcripts, you verify the proof bundle and compare the approved artifact hash to the published content hash.
Rollback posture
| Action | Safe rollback | Evidence you should retain |
|---|---|---|
| Draft release notes | Discard or replace the draft; no external impact. | Draft artifact hashes and approval denials (if any), plus proof bundle if models were used. |
| Publish release notes | Publish a corrected revision and link to an errata section; avoid silent edits if your policy requires transparency. | Approved artifact hash, published artifact hash, timestamps, and the proof bundle showing the publish was gated by approvals. |
| Email customers | Send a correction email with clear subject prefix and an internal incident record; do not attempt recalls unless your mail system guarantees it. | Recipient selection criteria snapshot, the exact sent body hash, approval record, and proof bundle capturing the final generation step. |
| Token or policy misconfiguration discovered mid-run | Revoke CST immediately, stop the job, rotate any exposed credentials, and re-run under a tightened WPC. | CST issuance details, WPC hash, and receipts showing what actions did and did not occur before revocation. |
Optional: egress allowlists enforced outside clawproxy can be implemented if you need network-level containment for publishing tools. Treat this as a separate control plane decision because it is environment-specific.
FAQ
Why isn’t “ask for approval in the prompt” enough?
Because prompts are not a control boundary: they can be overwritten by injected content, tool outputs, or a simple “ignore previous instructions” attack. A WPC makes approval a machine-enforced precondition to the publish and send tools, so the run fails closed.
Where do approvals live in this workflow?
Approvals are referenced as conditions in the WPC and are checked before enabling irreversible tools. The approval system itself can be wired in via official API or via MCP server, and it should record approver identity and the hash of the approved artifact.
How do CST and WPC relate to each other?
CST is the scoped token issued by clawscope; it carries scope constraints for the job. The CST can be pinned to a WPC hash so a token issued for “release-notes-to-customers” cannot be reused to run under a different policy.
What exactly do gateway receipts prove?
Gateway receipts are signed receipts emitted by clawproxy for model calls, so you can verify the model calls that occurred in the run. Combined with a proof bundle, they support audits like “did a model generate the final email body after approval” and “which policy was in force.”
Can this workflow integrate with Microsoft identity and governance?
Yes, but treat it as an integration decision: you can align approvals and access with Entra ID and Conditional Access, and implement checks via official API. The key is to keep irreversible actions behind step-up approvals and short-lived CST, regardless of the identity provider.