A two-person rule for agents means the agent cannot complete specific high-risk actions unless a second human approves the exact action payload. In Claw EA, you implement this as permissioned execution: a Work Policy Contract (WPC) defines which actions require approval, scoped tokens (CST, from clawscope) constrain what can run, and clawproxy emits gateway receipts so you can prove what the model actually called.
This is stronger than prompt-only instructions because prompts are advisory and can be overwritten by tool output, injected content, or simple model error. The execution layer must be policy-as-code so the runtime can fail closed when approvals are missing, regardless of what the model “decides.”
Step-by-step runbook
-
Define the “break-glass” surface. List the exact tool calls and parameters that must require dual approval, such as “send email externally,” “transfer funds,” “create OAuth consent,” “change firewall rules,” or “export customer data.”
Keep this list parameter-aware so you can approve a specific recipient, amount, tenant, or dataset, not a vague intent.
-
Encode the rule in a WPC. The WPC should declare an approval policy that maps tool routes to “requires second approver,” plus which identities are eligible approvers and what evidence must be recorded.
Store the signed, hash-addressed WPC in the WPC registry (served by clawcontrols), and treat the WPC hash as the change-controlled unit.
-
Issue a CST with policy hash pinning. When starting a job, request a CST (issued by clawscope) whose scope hash reflects the allowed tool surface, and optionally pin the WPC hash so the job cannot silently switch policies mid-run.
Use job-scoped CST binding to reduce replay risk across jobs, especially for approval-bearing steps.
-
Enforce the gate at execution time in the OpenClaw runtime. OpenClaw is the baseline agent runtime: use its tool policy and sandbox boundary to keep the default tool set minimal, and route model calls through clawproxy for receipting.
For the two-person rule, wrap the sensitive tools so they first create an “approval request” object, then block until an approver supplies an approval artifact that matches the exact request hash.
-
Integrate the approver identity system. In Microsoft environments, the approver check typically maps to Entra ID group membership, optionally requiring PIM activation for the approver role, and Conditional Access for device and location constraints.
When the approved action is a Microsoft 365 operation, run it via official API using Microsoft Graph permissions/scopes that match the WPC and the CST scope.
-
Record proof and verify. For every model call, clawproxy emits gateway receipts; attach the approval artifact, WPC hash, and CST scope hash into a proof bundle.
Publish the bundle to Trust Pulse for audit viewing when you need a persistent artifact that can be reviewed later.
Threat model
The two-person rule is primarily about preventing a single compromised path from completing irreversible actions. The control must assume the model can be tricked, the operator can be rushed, and the agent can be induced to ask for broader access than intended.
| Threat | What happens | Control (two-person rule implementation) |
|---|---|---|
| Prompt injection through email, web pages, or tickets | The agent is steered to execute a high-risk tool call (exfiltrate data, add an external mailbox rule, or send funds) while presenting it as routine work. | WPC marks the tool route as “dual approval required” and blocks execution unless an independent approver signs an approval artifact for the exact payload hash. |
| Single-operator compromise (phished admin, stolen workstation session) | An attacker can drive the agent to run actions that look like normal operator commands. | Separation of duties: the runner CST cannot complete gated actions; it can only create approval requests. A second identity must approve, and the approval is validated against the WPC rules. |
| Tool misuse due to model error or ambiguous instruction | The model chooses the wrong recipient, wrong tenant, wrong dataset, or wrong environment, causing real impact without malice. | Parameter-aware approvals: approver signs the exact destination, scope, and bounds. Any mismatch causes a fail-closed execution denial. |
| Replay of an approval or token | A previously approved payload is re-used in a different job, or a CST is replayed to bypass fresh approval. | Marketplace anti-replay binding via job-scoped CST binding, plus approval artifacts bound to a job id and WPC hash. Proof bundles show the bindings for review. |
| Policy drift during an incident | Operators “temporarily” weaken the guardrail, and the weaker state persists. | Pin the WPC hash in the CST so the job is cryptographically tied to the reviewed policy. Rotate the WPC hash for any change, and treat it as a deployment. |
Policy-as-code example
This is a deliberately small JSON-like example showing how teams typically express a two-person rule as a WPC-backed contract. The key is that the policy describes specific tool routes, required approver identities, and what must be bound into the approval artifact.
{
"wpc_version": "1",
"policy_name": "two_person_rule_enterprise_agents",
"requires": {
"approval": {
"mode": "two_person",
"min_approvers": 2,
"independent_of_requester": true,
"approver_identities": {
"provider": "entra_id",
"allowed_groups": ["Agent-Approvers-Prod"],
"require_pim_activation": "optional"
},
"bind": ["job_id", "wpc_hash", "tool_route", "payload_hash", "expires_at"]
}
},
"gated_tool_routes": [
{ "route": "m365.graph.sendMail", "when": { "external_recipient": true } },
{ "route": "m365.graph.addAppRoleAssignment" },
{ "route": "payments.transfer", "when": { "amount_usd_gte": 500 } },
{ "route": "storage.export", "when": { "dataset": "customer_pii" } }
],
"token_requirements": {
"cst": {
"scope_hash_required": true,
"pin_wpc_hash": true,
"job_scoped_binding": true
}
},
"logging": {
"require_gateway_receipts": true,
"bundle": "proof_bundle"
}
}
In OpenClaw, you pair this with tool policy and sandbox defaults so the agent cannot bypass the gate by calling a more generic tool. If you must allow an “elevated” path, treat it as gated and approval-required, since it bypasses sandbox protection.
What proof do you get?
For every model call routed through clawproxy, you get gateway receipts that identify the model call inputs and outputs in a signed, verifiable form. These receipts are the core evidence that the model traffic you audited is the model traffic that occurred.
Claw EA packages receipts plus job metadata into a proof bundle. A typical bundle includes the WPC hash used for enforcement, the CST scope hash (and optional policy hash pinning), the approval artifact hashes, and enough metadata to reconstruct whether the two-person gate was satisfied at the moment of execution.
When you need a durable audit view, you can store the resulting artifact in Trust Pulse. This gives reviewers a single object to inspect without relying on ad hoc logs from the agent host.
Rollback posture
Two-person rule rollbacks should be designed to fail safe. Your goal is to stop high-risk actions quickly while keeping low-risk read-only workflows available for incident response.
| Action | Safe rollback | Evidence you should retain |
|---|---|---|
| Approver channel compromised | Remove approver eligibility (Entra ID group change), and rotate to a new approver group referenced by a new WPC hash. | Proof bundles before and after the WPC change, plus the WPC hashes and gateway receipts for any attempted gated actions. |
| Runner token suspected leaked | Revoke the CST and re-issue with tighter scope hash and shorter TTL. Keep gated tools blocked until a new job-scoped CST binding is in place. | CST identifiers and revocation records, and proof bundles showing which job ids were bound to which CST scope hashes. |
| Policy too strict, business outage | Temporarily move specific routes from “two-person” to “one-person” in a new WPC, limited to a narrow allowlist and short expiry, then revert. | Both WPC versions (hashes), plus receipts proving no disallowed routes were called during the temporary window. |
| Model provider incident or unexpected tool behavior | Disable the affected tool route in OpenClaw tool policy and keep the two-person gate intact for all remaining sensitive routes. | OpenClaw configuration diff, gateway receipts that show the last successful calls, and the proof bundle boundary for the incident window. |
FAQ
Isn’t a prompt instruction like “always ask for approval” enough?
No. Prompt-only controls are not binding, and the agent can be induced to skip them through injection, confusion, or tool output that reframes the task.
Policy-as-code makes approval a runtime precondition enforced with WPC rules and CST scoping, not a suggestion.
How do I keep approvals specific, not “approve anything the agent does”?
Require the approval artifact to bind the tool route and a payload hash. This forces the approver to sign the concrete recipient, amount, dataset, or permission scope.
If the agent changes any parameter, the hash changes and execution fails closed.
Can this work with Microsoft 365 actions?
Yes, when your agent performs actions via official API using Microsoft Graph permissions/scopes that match your WPC. The two-person gate should protect permission-changing operations (like app role assignments) and external communications (like sending mail outside the domain).
Use Entra ID group membership for approvers, and consider Conditional Access and PIM to reduce who can approve and under what conditions.
What prevents an approval from being reused later?
Bind approvals to a job id and WPC hash, and use job-scoped CST binding for the job that consumes the approval. That way, even a copied approval artifact is not valid in a different job context.
Your proof bundle should make these bindings visible to auditors.
What do auditors actually verify?
They verify that the WPC hash in the bundle matches the reviewed policy, that the CST scope hash aligns with the intended tool surface, and that the gateway receipts show only permitted model calls. For gated actions, they also verify the approval artifact bindings and timing.
This is the difference between “we think it asked for approval” and “we can prove it could not execute without approval.”