Contract review and approval workflow (Permissioned Execution)
This workflow runs contract review and redline generation under machine-enforced constraints, then requires step-up human approval before anything leaves your boundary. It is designed for OpenClaw as the baseline agent runtime, with Claw EA adding policy binding, receipted model traffic, and auditable outputs.
The key design choice is permissioned execution (policy-as-code) rather than prompt-only instructions. Prompts can be ignored or subverted, but a Work Policy Contract (WPC) and scoped token (CST) can fail closed and produce proof of what was allowed and what happened.
Use a WPC to define exactly what the agent may read, transform, and output during contract review, then run the job with a CST pinned to that WPC. Route all model calls through clawproxy so you receive gateway receipts, and package the run as a proof bundle for audit and later verification.
Treat “approve contract language” and “send redlines” as irreversible actions that always require step-up approvals. Enforce DLP and redaction at the execution layer, so the system can block or redact sensitive content even when the prompt is manipulated.
Step-by-step runbook
-
Define the contract-review WPC. Write a WPC that restricts tools to read-only document ingestion, approved clause libraries, and limited drafting tools. Include explicit output rules (what can be produced) plus DLP and redaction requirements.
Store the signed WPC in the WPC registry so it can be fetched and verified at runtime.
-
Issue a CST pinned to the policy. Request a CST from clawscope with a scope hash that matches the allowed actions for this workflow, and optionally pin the policy hash so the token is only usable with the intended WPC. Bind the CST to a single job where possible to reduce replay risk.
If you map humans to identities in Microsoft Entra ID, keep the approval identity checks in your existing access patterns (for example, Conditional Access and PIM for approvers), and pass the approval result into the run as an external signal via official API.
-
Run the agent in OpenClaw with sandbox and tool policy tightened. Enable sandboxing for tool execution and keep tool allowlists minimal, so the agent cannot “discover” extra capabilities. Use OpenClaw’s security audit regularly to catch footguns like open inbound access and weak redaction settings.
Keep elevated execution disabled for this workflow unless you have a documented exception and a separate WPC for that exception.
-
Route model traffic through clawproxy for receipting. Configure the agent’s model provider path so calls are proxied and receipted, producing gateway receipts for each model call. If you use OpenRouter via fal, route it through clawproxy so receipts still cover the model exchange.
This is the difference between “we think the agent followed the rules” and “we can verify what was called and under which token and policy binding.”
-
Apply DLP and redaction before any externalization. Require a redaction pass that removes or masks sensitive fields (for example: bank details, personal addresses, customer lists, pricing tables) based on policy rules. Keep both the raw draft and the redacted version as separate artifacts, with the raw draft restricted to the smallest set of reviewers.
If the agent cannot satisfy redaction rules deterministically, force a human review step and block sending.
-
Step-up approval gate for irreversible actions. Before “send redlines” or “approve contract language,” require an explicit human approval event that references the job id, the WPC hash, and the output artifact hashes. The agent may prepare the packet, but it cannot execute the action until approval is recorded.
When the approval is absent or ambiguous, fail closed and produce an exception report in the proof bundle.
-
Finalize and archive as a proof bundle. Bundle gateway receipts, policy identifiers, token binding metadata, and output hashes into a proof bundle. Store the proof bundle for audit, and optionally publish a Trust Pulse for centralized viewing.
This gives legal and security teams a stable artifact for later verification, without re-running the agent.
Threat model
This workflow assumes the agent can be influenced by prompt injection in documents, emails, or chat threads. The controls focus on preventing unauthorized actions and proving what occurred when the agent handled sensitive contract content.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection inside the contract PDF or email thread | The agent is instructed to reveal secrets, skip redaction, or send redlines to an attacker-controlled address. | Permissioned execution: WPC tool and output constraints, CST scope hash, and a hard step-up approval gate before sending. |
| Data leakage in generated redlines | Confidential annexes, pricing, or personal data appear in comments or markup that gets shared externally. | DLP and redaction rules enforced by policy; block externalization unless redaction passes and artifacts are hashed and recorded. |
| Unverifiable model behavior during review | After an incident, you cannot prove which model was called or what was sent to it. | Gateway receipts from clawproxy for model calls, stored in a proof bundle for verification. |
| Token replay across jobs | A token captured from logs or a misconfigured runner is reused to run unauthorized contract reviews. | Marketplace anti-replay binding using job-scoped CST binding, plus optional policy hash pinning to prevent token reuse under different WPCs. |
| Tool escape or overbroad tool access | The agent writes files, runs shell commands, or reaches unapproved network destinations during review. | OpenClaw sandboxing and strict tool allowlists; keep elevated execution disabled for this workflow. |
Policy-as-code example
This is a minimal JSON-like sketch of a WPC for contract review. It shows the core idea: lock tool access, require redaction, and force human approval for irreversible actions.
{
"wpc_version": "v1",
"workflow": "contract_review_approval",
"inputs": {
"allowed_document_types": ["pdf", "docx", "txt"],
"max_document_pages": 250
},
"tools": {
"allow": [
"doc.read",
"doc.extract_text",
"clause_library.search",
"draft.redlines.generate"
],
"deny": [
"shell.exec",
"fs.write",
"network.send",
"email.send"
]
},
"output_policy": {
"allowed_outputs": ["redline_suggestions", "risk_summary", "issue_list"],
"blocked_outputs": ["final_approved_language_without_human_signoff"],
"redaction_required": true,
"dlp_rules": [
{"type": "pii", "action": "mask"},
{"type": "bank_account", "action": "remove"},
{"type": "pricing_table", "action": "mask_unless_approved"}
]
},
"approvals": {
"step_up_required_for": ["send_redlines", "approve_contract_language"],
"approval_binding": ["job_id", "wpc_hash", "output_hashes"]
}
}
In production, the signed WPC is stored as a hash-addressed artifact in clawcontrols. The CST from clawscope can carry an optional policy hash pinning value so the runtime can refuse mismatched policies.
What proof do you get?
Each model call routed through clawproxy produces gateway receipts. These receipts can be used to verify that calls were made under the expected token binding and that the proxy path was used for the job.
At the end of the run, Claw EA produces a proof bundle that ties together the WPC identifier, CST binding metadata, gateway receipts, and hashes of outputs (drafts, redacted drafts, and the approval packet). If you need a centralized place for audit viewing, you can store the run artifact as a Trust Pulse.
Rollback posture
Rollback in contract workflows is mostly about stopping externalization and proving what was shared. The system should assume that once redlines are sent, you cannot fully retract them, so the goal is to prevent sending until approvals and redaction are complete.
| Action | Safe rollback | Evidence |
|---|---|---|
| Agent generated an unsafe redline draft | Quarantine the artifact, re-run redaction under the same WPC, and require a new approval event tied to new output hashes. | Proof bundle shows the original output hash and the corrected output hash, plus the redaction requirement and job metadata. |
| Attempted “send redlines” without approval | Fail closed and record a blocked action outcome; do not allow the tool call to proceed. | WPC step-up requirement plus a run record in the proof bundle; gateway receipts confirm model calls but not an outbound send. |
| Approval granted to the wrong artifact version | Invalidate the approval for this job, issue a new CST for a new job, and re-run with corrected inputs. | Approval binding includes output hashes; mismatch is detectable when the hashes do not line up with the approved packet. |
| Policy mistake discovered mid-rollout | Rotate to a new WPC version and stop issuing CSTs pinned to the old policy hash. | WPC hashes are distinct; proof bundles show which jobs used which policy version. |
FAQ
Why is prompt-only control not enough for contract review?
Contracts can contain adversarial instructions and sensitive data, and the model can be coerced into ignoring “do not send” guidance. Policy-as-code lets you block tools and outputs deterministically, then prove which policy governed the run.
Where do WPC and CST fit in the workflow?
The WPC defines what is allowed, and the CST authorizes a specific job to run under that scope. With optional policy hash pinning, a CST can be made unusable if the runtime tries to swap policies.
What exactly is the step-up approval gate?
It is a hard stop before irreversible actions like “send redlines” and “approve contract language.” The approval event should bind to the job id, the WPC hash, and output hashes so approval cannot be replayed onto different content.
Can we integrate this with Microsoft Entra ID approvals?
Yes, typically via official API, with approvers governed by your existing Conditional Access and PIM practices. Claw EA focuses on binding the external approval result to the job and preserving it inside the proof bundle.
What do gateway receipts cover and what do they not cover?
Gateway receipts cover model calls that go through clawproxy, including metadata needed for verification. They do not automatically prove what happened in tools that run outside the receipted path unless you also capture and hash those artifacts in the proof bundle.