This workflow handles a cloud cost spike with permissioned execution: the agent can investigate broadly, but any irreversible action (stop workloads, scale down, disable services) is blocked unless it matches policy-as-code and gets step-up approvals.
Run it on OpenClaw as the baseline agent runtime, then bind the run to a WPC and a job-scoped CST so every model call and decision is traceable via gateway receipts and a proof bundle.
Step-by-step runbook
Use this when you receive a billing alert, budget threshold breach, or “bill shock” notification from your cloud provider or FinOps tooling. The goal is to move from “spike detected” to “bounded action and verified recovery” without giving an agent broad, prompt-only permissions.
-
Open an incident and freeze the blast radius. Create a job that scopes the agent to a single account, subscription, or billing project, plus a single time window. Issue a CST from clawscope that encodes a scope hash for that job and optionally pins the WPC hash.
-
Bind the run to a WPC before the agent starts. Store a WPC (Work Policy Contract) in clawcontrols that specifies allowed tools, read versus write phases, and explicit approval gates. The point is that the execution layer must enforce the policy, not the prompt.
-
Collect read-only facts first (no mutations). Pull cost and usage breakdowns via official API (for example: AWS Cost Explorer, Azure Cost Management, or GCP billing export queries), plus relevant inventory and tag metadata. Keep the agent in a read-only tool profile during this phase and run tools in a sandbox where feasible.
-
Explain the spike with a ranked hypothesis list. Require the agent to attribute the anomaly to concrete drivers: new resource types, region changes, SKU changes, data egress, logging growth, autoscaling behavior, or failed spot capacity. The output should include “what changed” and “how to verify” with queries the agent already ran.
-
Simulate-first and draft a remediation plan. Force a dry-run phase where the agent proposes actions and generates a rollback plan, but is not allowed to apply changes. If the provider supports plan mode (for example IaC plan), use that; otherwise, treat “simulate-first” as a hard policy rule that blocks apply tools until approval is recorded.
-
Step-up approvals for irreversible actions. Any stop/scale/disable operation must require a human approval step that references the incident ID, target resources, and expected cost impact. Approvals can be implemented via an internal ticketing workflow or an MCP server that records approvals, but the WPC must make “approval required” machine-checkable.
-
Execute in a write window with narrow permissions. Re-issue a tighter CST for the write phase, still pinned to the same WPC, and limit tools to only the exact mutation operations approved. Route model traffic through clawproxy so you receive gateway receipts for every model call used to decide and execute changes.
-
Verify outcomes and package proof. Re-run the same cost and usage queries for the post-change window, confirm the anomaly slope has normalized, and document residual risk. Produce a proof bundle that includes the gateway receipts, policy hash, scope hash, and execution metadata for audit and later review.
Threat model
Cloud cost response is a high-risk automation category because the fastest fixes are often irreversible and affect availability. The controls below focus on preventing an agent from escalating from investigation into unreviewed shutdowns, and on ensuring you can prove what happened after the fact.
| Threat | What happens | Control |
|---|---|---|
| Prompt-only “approval” spoofing | An agent claims approval in text and proceeds to stop workloads or disable services. | WPC-enforced step-up approvals that must be recorded as a real artifact, plus tool gating so write tools cannot run without an approval reference. |
| Wrong account or billing scope | The agent mitigates costs in the wrong org, subscription, or project, causing outages with no cost benefit. | CST scope hash bound to a single account and time window; require policy hash pinning so a different WPC cannot be substituted mid-run. |
| Overbroad tool access | An investigation step turns into configuration drift, deletion, or security regression. | Two-phase tool profiles: read-only first, then a narrow, approved write window; sandbox tools in OpenClaw to reduce local blast radius. |
| Runaway model usage during incident | Investigation increases your own model spend and slows response. | Budget fields in the WPC and operational guardrails in the harness; automatic cost budget enforcement is optional and can be implemented if you need hard stop behavior. |
| Disputed post-incident narrative | Teams disagree on what the agent saw, what it asked the model, and why it took action. | Gateway receipts for model calls from clawproxy, then a proof bundle that binds receipts to the job, CST scope hash, and WPC hash. |
| Replay of prior “approved” execution | A token or approval artifact is reused to re-run a destructive action later. | Marketplace anti-replay binding using job-scoped CST binding, and short TTL CSTs for write phases. |
Policy-as-code example
This JSON-like WPC sketch shows the core idea: the agent can read broadly to diagnose a spike, but cannot apply changes until a dry-run completes and a human approval artifact is present. The enforcement point is the execution layer, so the policy is checked even if the prompt is manipulated.
{
"wpc_version": "1",
"intent": "cloud_cost_anomaly_response",
"scope": {
"cloud_account_ref": "aws:123456789012 OR azure:/subscriptions/0000... OR gcp:billingAccount/AAAAAA-BBBBBB-CCCCCC",
"time_window_utc": { "start": "2026-02-10T00:00:00Z", "end": "2026-02-11T00:00:00Z" }
},
"execution": {
"runtime": "openclaw",
"require_sandbox_for_tools": true,
"simulate_first": true,
"phases": [
{
"name": "read_only_diagnosis",
"tools_allow": [
"cost.query",
"usage.breakdown",
"inventory.list",
"tags.read",
"logs.read"
],
"tools_deny": [ "stop_workload", "scale_down", "disable_service", "delete_resource" ]
},
{
"name": "approved_write_window",
"requires_step_up_approval": true,
"approval_ref_required": true,
"tools_allow": [ "scale_down", "disable_service", "stop_workload" ],
"constraints": {
"deny_if_missing_rollback_plan": true,
"max_targets": 5
}
}
]
},
"token_controls": {
"cst_required": true,
"cst_scope_hash_required": true,
"optional_policy_hash_pinning": true,
"write_phase_ttl_minutes": 15
},
"budgets": {
"incident_spend_budget_usd": 2000,
"model_spend_budget_usd": 50,
"note": "Hard enforcement can be implemented; always record spend estimates and stop conditions."
},
"model_calls": {
"route_via": "clawproxy",
"require_gateway_receipts": true,
"provider_hint": "openrouter_via_fal"
},
"audit": {
"produce_proof_bundle": true,
"store_trust_pulse": true
}
}
What proof do you get?
Every model call routed through clawproxy emits gateway receipts. Those receipts make it practical to verify what the model was asked and what it returned during the incident timeline, without relying on a mutable app log.
Claw EA packages receipts and execution metadata into a proof bundle, including the WPC hash, CST scope hash, and job identifiers. If you use Trust Pulse, you can store the artifact for later viewing and audit, and rely on marketplace anti-replay binding to reduce reuse of job-scoped credentials.
This proof set is useful for post-incident review: “what data did we query,” “what options did we consider,” “who approved the irreversible step,” and “what was executed under which policy.” It also helps you rerun the same investigation with the same constraints if the anomaly recurs.
Rollback posture
Cost mitigation often trades off availability. Treat rollback as a first-class deliverable: you want a safe way to restore service even if the original mitigation was correct but operationally disruptive.
| Action | Safe rollback | Evidence |
|---|---|---|
| Scale down a workload | Restore previous replica counts or autoscaling settings from the captured baseline, then monitor error rates and queue depth. | Pre-change inventory snapshot plus post-change verification queries included in the proof bundle. |
| Stop workloads | Start only the minimal set of services required for core functionality, then re-enable dependencies in order. | Approval reference, target list, and timestamps bound to CST scope hash and WPC hash. |
| Disable a cloud service feature | Re-enable the feature with the prior configuration, and run a short canary window before full restore. | Recorded dry-run outputs and the exact applied change set, plus gateway receipts for the decision path. |
| Rotate credentials or revoke access after suspected abuse | Issue new least-privilege credentials and re-run the read-only diagnosis to confirm cost drivers persist. | CST revocation events, new CST issuance for the follow-up job, and a new proof bundle for the verification pass. |
FAQ
Why is prompt-only control not enough for cost anomaly response?
Because the dangerous step is not “what the agent says,” it is what the agent can execute. A permissioned execution layer enforces WPC rules even if the model is manipulated into claiming approvals or skipping simulation.
How do WPC and CST work together during an incident?
The WPC defines what is allowed, including dry-run requirements and approval gates. The CST issued by clawscope scopes a specific job and can optionally pin the policy hash, so a run cannot silently switch to a looser policy.
Do I get an audit trail of the model’s involvement?
Yes, if you route model traffic through clawproxy you receive gateway receipts for model calls. Claw EA then bundles those receipts into a proof bundle with job metadata for verification and review.
Can the agent query AWS, Azure, or GCP billing data?
Yes, via official API or via an MCP server you operate. Keep those calls in the read-only phase, then require explicit approvals for any mutation of runtime infrastructure.
How do you handle budgets if automatic enforcement is not guaranteed?
Put budget limits in the WPC and require the agent to compute a spend estimate before proposing changes, then gate write actions on approval. If you need hard stop behavior, automatic cost budget enforcement is optional and can be implemented in the harness.