Incident triage and response coordination works best when the agent runtime is constrained by machine-enforced policy, not by “please be careful” prompt text. In Claw EA, OpenClaw is the baseline agent runtime, and Claw Bureau adds permissioned execution with WPCs, CSTs, gateway receipts, and proof bundles so you can prove what happened and safely roll it back.
The operational goal is simple: let an agent gather evidence and draft actions quickly, but require explicit policy and step-up approvals for irreversible moves like disable access, block egress, rotate keys, or declare incident. You end each run with verifiable artifacts that can be reviewed after the fact without trusting the agent’s narrative.
Step-by-step runbook
This runbook assumes you already have an incident channel and an on-call rotation. It also assumes your agent can reach your systems via official API, via MCP server, or via an enterprise buildout.
-
Create a case and select an incident WPC. Treat the WPC as the “what is allowed” contract for this specific incident severity and environment. The WPC is fetched and verified via the WPC registry, and its hash becomes the anchor for the run.
Do not start with a broad “security engineer” prompt and full tool access. Start with a narrow WPC that permits read-only evidence collection and drafting, then escalate in controlled steps.
-
Issue a CST for the job, pinned to the case scope. Mint a CST (issued by clawscope) that is job-scoped and bound to the incident identifiers you care about, such as case ID and environment. Use CST scope hash and optional policy hash pinning so the token is only valid for the intended policy.
This makes token reuse harder across cases, and it reduces the chance that a copied token can be replayed in a different context.
-
Start OpenClaw in “triage mode” with tool allow/deny lists. Configure OpenClaw tool policy to allow only evidence collection tools (logs, ticket read, alert read, query tools) and deny any tool that can mutate production by default. If you use sandboxing, keep tool execution inside the sandbox unless an explicitly approved step requires elevated execution.
OpenClaw’s separation of sandbox, tool policy, and elevated execution matters during incidents because “read data” and “change system state” need different controls.
-
Route model calls through clawproxy and collect gateway receipts. Configure the model provider path so model calls are proxied and receipted, for example OpenRouter via fal routed through clawproxy. Each model call yields gateway receipts that can later be verified independently of your chat transcript.
This step is what turns “the agent said it did X” into “here are the signed receipts for the model interactions that produced the recommendation.”
-
Evidence sweep: gather, normalize, and summarize. Have the agent pull the minimum needed telemetry: alert details, recent deployments, auth events, network anomalies, and key asset inventory. Keep write actions disabled, and require the agent to cite specific evidence objects (IDs, timestamps, query links) in its summary.
If you use Microsoft security data, collect it via official API with appropriate Microsoft Graph permissions/scopes, and prefer temporary elevation through PIM where applicable. Conditional Access can be used to restrict where the human approver can authenticate from, but do not rely on it as the only control.
-
Step-up approvals for irreversible actions. When the agent proposes an action like disable access, block egress, rotate keys, or declare incident, it must pause and request a human approval with a clearly stated blast radius and rollback plan. On approval, re-issue a new CST or switch to a stricter WPC variant that explicitly allows only the requested action and nothing else.
This is the core difference between prompt-only guardrails and permissioned execution: the enforcement is in the execution layer, not in the agent’s self-restraint.
-
Close the loop: produce a proof bundle and publish for review. At the end of the run, package gateway receipts and run metadata into a proof bundle. Store the proof bundle in Trust Pulse so responders and auditors can review what policy was in force, what the agent asked the model, and what actions were approved.
In post-incident review, you should be able to answer “what did we allow?” and “what did we do?” without reconstructing intent from chat logs.
Threat model
Incident response is adversarial by default, and the agent’s inputs are often hostile: alert text, ticket comments, pasted terminal output, and user-provided artifacts. Design the workflow so the agent can read widely but act narrowly, and so approvals are visible and attributable.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection from incident artifacts | An attacker hides instructions in logs or tickets to trick the agent into disabling access or rotating keys. | WPC tool allow/deny lists default to read-only; irreversible tools require step-up approval and a policy change before execution. |
| Tool escalation to host execution | The agent finds a path to run elevated commands and touches host files or secrets during triage. | OpenClaw sandboxing for tool execution, deny elevated tools by default, and isolate “elevated” into a separate approved step. |
| Token replay across incidents | A CST copied from one case is reused to run actions in another case or environment. | Marketplace anti-replay binding with job-scoped CST binding, plus CST scope hash and optional policy hash pinning. |
| Disputed “who approved what” | After the incident, no one can prove whether a human approved a high-risk action or if it was improvised. | Step-up approvals are treated as explicit gates; store decision metadata alongside the proof bundle and WPC hash. |
| Model call integrity disputes | Someone claims the agent never asked the model to do a certain analysis, or that outputs were edited. | Gateway receipts from clawproxy for model calls, packaged into a proof bundle for verification and review. |
Policy-as-code example
This is a simplified, JSON-like sketch of an incident triage WPC. The point is that the enforcement lives in policy and tokens, not in the prompt.
{
"wpc": {
"name": "incident-triage-sev2",
"mode": "triage",
"tools": {
"allow": [
"tickets.read",
"alerts.read",
"logs.query",
"inventory.read",
"evidence.export"
],
"deny": [
"access.disable",
"network.block_egress",
"keys.rotate",
"incident.declare"
]
},
"approvals": {
"step_up_required_for": [
"access.disable",
"network.block_egress",
"keys.rotate",
"incident.declare"
],
"approver_group": "oncall-incident-command"
},
"kill_switch": {
"on_trigger": "deny_all_mutations",
"note": "Emergency stop if behavior deviates or scope is unclear."
}
},
"cst": {
"issued_by": "clawscope",
"scope_hash": "job:INC-24817:prod",
"policy_hash_pinning": "optional",
"bind": {
"case_id": "INC-24817",
"environment": "prod",
"job_scoped": true
}
}
}
In practice, you keep “triage” and “containment” as separate WPCs. Moving from one to the other is a deliberate act, not an emergent behavior from a longer prompt.
What proof do you get?
You get gateway receipts for model calls, emitted by clawproxy, which let you verify that specific model interactions occurred under a specific CST and policy context. Those receipts are assembled into a proof bundle, which ties together the run metadata, policy hash references, and receipt envelopes for audit and verification.
For coordination work, the proof bundle is the handoff artifact. It supports a clean separation between “fast iteration” during triage and “slow certainty” during review, because the reviewer can check the WPC used, the CST scope hash, and the set of receipted model calls that drove recommendations.
When you need a durable place to store and view the run’s evidence package, publish the proof bundle to Trust Pulse. This is useful for post-incident review, compliance sampling, and internal dispute resolution about what was permitted and what actually happened.
Rollback posture
Rollback in incident response is mostly about avoiding irreversible actions until you have sufficient evidence. When you must do irreversible work, you make the rollback plan explicit and you capture evidence that the right policy and approvals were in force.
| Action | Safe rollback | Evidence |
|---|---|---|
| Disable access | Prefer temporary disable with an expiry; document which identities were impacted and why. Re-enable only after confirming containment criteria. | WPC that explicitly allowed the action, step-up approval record, and the proof bundle for the run that proposed and executed it. |
| Block egress | Start with the narrowest scope (service or subnet), time-box the block, and keep an exception path for critical dependencies. | Approval gate metadata plus the policy change that moved from triage to containment permissions. |
| Rotate keys | Stage new keys first, validate consumers, then revoke old keys. Keep a documented backout window if service stability is at risk. | Proof bundle showing the recommendation chain, plus explicit human approval before mutation tools were enabled. |
| Declare incident | Use a reversible “suspected incident” state if your process supports it; upgrade severity only after validation. Keep stakeholder comms templated and consistent. | WPC and approval log showing the declaration was intentional, not triggered by untrusted inputs. |
| Emergency stop (kill switch) | Revoke the CST and switch to a deny-all-mutations WPC variant. Restart in read-only mode to preserve evidence gathering without further changes. | CST revocation event plus the WPC hash for the emergency posture attached to the incident record. |
FAQ
Why isn’t a carefully written prompt enough for incident response?
Because incident artifacts are untrusted input, and the agent is incentivized to “be helpful” under pressure. Permissioned execution puts the guardrails in enforceable policy (WPC plus CST constraints), so the agent cannot perform irreversible actions unless the execution layer allows it.
What is the minimum set of controls you recommend for triage?
Start with tool allow/deny lists, sandboxed tool execution where feasible, and step-up approvals for disable access, block egress, rotate keys, and declare incident. Add a kill switch that can immediately revoke the CST and force a deny-all-mutations posture.
How do gateway receipts and proof bundles help in a post-incident review?
They let reviewers verify model calls and policy context without trusting a chat transcript or a human summary. The proof bundle becomes the audit anchor: which WPC was in force, which CST scope hash was used, and which model interactions were receipted.
Can this workflow operate in a Microsoft environment?
Yes, but treat Microsoft Graph access as a privileged integration and scope it tightly. Use Entra ID controls like PIM for time-bound elevation and Conditional Access for approver sign-in constraints, and collect data via official API with explicit permissions/scopes.
What should we do if the agent starts behaving unexpectedly mid-incident?
Trigger the kill switch: revoke the CST and move to a deny-all-mutations WPC posture. Restart the run in read-only mode so you can continue evidence collection while you inspect the proof bundle for what the agent was attempting.