DashClaw is a governance runtime. It sits between an agent's intent and the real world: every consequential action is checked against policy before it happens, recorded while it happens, and verified after it happens. This page explains the model — then lets you play with it.
Four things, and only four: policy enforcement, decision recording, assumption tracking, and risk signals. It does not give agents tools to achieve goals — it governs the goals they already have.
Same agent, same tasks. The only difference is whether a governance runtime sits between intent and execution.
A fully governed action makes four calls. Click each step — or use the arrow keys — to see what actually goes over the wire.
Governance is usually framed as protecting the world from agents. The same ledger protects the agent — from unfair blame, from being weaponized, and from bankrupting itself. Every governed action carries an agent_defense rollup on its detail record: what the agent declared, what it assumed, and which shields stood in front of it.
Before acting, an agent records what it believed and why (assumption + basis), tied to the action. When an outcome goes wrong, the ledger shows whether the agent acted reasonably on what it knew — and which assumption was later invalidated, by whom, and why. Blame lands on the broken belief, not reflexively on the agent.
Declared goals are scanned for prompt-injection patterns on every guard call, and the scan's outcome is persisted with the decision — a manipulated agent has evidence, not just a denial. Content policies can verify claims against a source of truth (non_fabrication) and issue signed receipts, failing closed when the source can't be checked. Where a shield didn't run, the record says not recorded — the advocate never fabricates its client's alibi.
For agents that spend real money over x402, per-purchase caps and cumulative window budgets interrupt a runaway purchase before the money moves — a block or an approval pause, recorded like any other decision. An agent under a spend gate cannot quietly drain a wallet; it gets stopped, and the stop is its proof of restraint.
When a session ends, its whole record gets a defensibility review. GET /api/sessions/:id/retro composes it from the ledger on read — nothing is stored, nothing is invented — and returns a posture: clean review flagged.
The posture comes purely from the severities of evidenced findings: any high-severity finding — a blocked action, a failed shield verdict, an invalidated assumption that carried weight — means flagged; any finding at all means review; none means clean. Each finding cites the specific decision, action, or shield verdict behind it, so the verdict can be checked, not just believed.
The retro is the advocate section above, concluded: the assumptions the agent recorded, the shields that stood in front of it, and the approvals it waited for become its exhibit list. A clean retro is proof the agent operated inside its contract; a flagged one points at the exact evidence — not at the agent's reputation.
Every session detail page renders the full retro card, with the posture chip pinned in the header next to the session status. Agents can read their own review too, over MCP (dashclaw_session_retro) — retrospection is part of the governance loop, not an ops afterthought.
Describe a hypothetical action and watch the decision change. Illustrative simulation — production decisions come from the guard runtime, which computes risk server-side from the declared fields. The 40/70 bands are how DashClaw labels risk across the product; whether a given score warns, blocks, or pauses for approval is set by your org's risk_threshold policies — the toggle below mirrors one.
Policies are the contract between you and your agents. Compose one and watch it re-evaluate a day of agent activity. Illustrative simulation — production decisions come from the guard runtime.
These mirror real policy types: the spend rule is x402_spend_limit and governs paid (x402) purchases — the production policy also enforces a cumulative budget over a rolling window (not simulated here); blocked types and the risk threshold mirror block_action_type and risk_threshold, which apply to any action.
| Action | Type | Spend | Risk | Decision | Because |
|---|
The same governed action — guard, record, act, report — in whichever shape your stack speaks. Pick a scenario, pick a style, copy it out.
Distilled from running governed fleets. Each one exists because its absence has a failure story.
Agents speak to the runtime through an SDK, MCP server, or plain HTTP. The runtime enforces policy and writes the ledger. Humans watch and decide through the dashboard.
The dashboard surfaces are Mission Control (fleet posture and live decisions), Decisions (the causal-chain ledger), and Policies (the interruption contract). Note the direction of the human edge: people observe and decide; they are not in the data path of every action.