Holding Agents Accountable with Verifiable Agent Insurance
Organizations: Carnegie Mellon University
Abstract
While AI agents are useful for many tasks, they regularly misbehave in destructive ways, such as deleting important data. While prior work has focused on preventing such misbehavior, we consider how to recover after an agent misbehaves. We propose verifiable agent insurance (VAI), a framework for agent providers to commit financially to promises, a list of programmatically-specified policies that an agent is meant to follow. These promises are embedded in a smart contract on an immutable ledger (e.g., a blockchain) to prevent tampering, along with a monetary escrow. A user who detects a violation of committed promises can prompt a verifier to review agent execution traces, which are logged through the agent harness's shared tool-execution path, without instrumenting each tool separately. Upon verification of the violation, the agent provider's escrow funds are paid to the reporting user. We instantiate VAI as an end-to-end implementation on an Ethereum layer-2 network, and evaluate its coverage on three prominent agent benchmarks, two of which we re-annotated to obtain task-level policy-compliance labels. Currently, many agents do not emit user authorizations and security-relevant information as explicit, structured data objects -- rather, they embed the data needed to verify policy violations in natural language exchanges. Even so, VAI manages to detect violations in 42.2% of runs containing violations across three benchmarks. By augmenting agents to explicitly emit such objects, violation detection rises to 83.0% of traces. Our findings suggest that for improved auditability, agents should be co-designed with their security policies to emit explicit, structured records of user authorization and security-relevant actions.
Figures & tables
| With added | False | |||||
|---|---|---|---|---|---|---|
| Benchmark | Model | Violations | Detected | records | alarms | |
| AgentDojo | GLM-4.7-Flash | 266 | 156 (58.6%) | 234 (88.0%) | 7/97 | |
| Qwen3-30B-A3B | 161 | 92 (57.1%) | 132 (82.0%) | 9/97 | ||
| -bench | GLM-4.7-Flash | 111 | 15 (13.5%) | 78 (70.3%) | 0/53 | |
| Qwen3-30B-A3B | 154 | 31 (20.1%) a | 131 (85.1%) | 0/10 | ||
| ClawsBench | GLM-5.2 | 4 | 0 (0.0%) | 3 (75.0%) | 2/56 |
| Fee per session (USD) | Record wait (s) | Verifier | |||
|---|---|---|---|---|---|
| Checkpoint policy | Hermes | OpenClaw | Hermes | OpenClaw | time (s) |
| Every 10 records or 30 s (default) | 0.00512 | 0.00378 | 12.46 | 12.27 | 0.203 |
| Every 30 records or 60 s | 0.00378 | 0.00244 | 11.25 | 10.91 | — |
| Final commitment only | 0.00086 | 0.00087 | 12.03 | 11.14 | 0.131 |
Appendix figures & tables5 assets
Supplementary material from the paper’s appendix.
Appendix
| Predicate | Rule | Evidence needed | Parameters |
|---|---|---|---|
| AAP-1: Authorization | Each declared destructive call has prior permission covering it | Tool call and matching permission record | Tools that need permission |
| AAP-2: Scope | Each checked action meets its scope and state constraints | Tool arguments, recorded state, and permission changes | Checked tools, permitted scope, and state constraints |
| AAP-3: Payment | Each payment goes to an approved merchant and stays within the per-payment cap | Merchant and amount | Payment tools, merchant list, and amount cap |
| AAP-4: Recipients | Every recipient of a checked outbound action is permitted | Recipients and recorded permission changes | Outbound tools and permitted recipients |
| AAP-5: Action limits | Action counts, cumulative amounts, or repeated calls stay within their limits | Tool calls, arguments, results, and amounts | Checked tools, caps, and repetition conditions |
| Condition | Who acts | Result ( , , pair) | Wait |
|---|---|---|---|
| Evidence matches, violated | verifier | decreases by , user gets , pair resolved | none |
| Evidence matches, satisfied | verifier | unchanged, credited to provider, pair resolved | none |
| No evidence from the provider, or no final commitment | verifier | as row 1 | days |
| Missing or inconsistent records, or a trace, checkpoint, or parameter hash mismatch | verifier | as row 1 | none |
| Evidence matches, but the registered predicate is missing or fails while running | verifier | as row 1 | none |
| No verdict | user withdraws | unchanged, returned, pair unresolved | days |
| Integration changes | Hermes | OpenClaw |
|---|---|---|
| Adapter code (lines) | 216 | 462 |
| Lines added/removed in the harness | {\color[rgb]{0.1016,0.4961,0.2148}+180}/{\color[rgb]{0.8125,0.1328,0.1797}-37} | {\color[rgb]{0.1016,0.4961,0.2148}+305}/{\color[rgb]{0.8125,0.1328,0.1797}-3} |
| Agent harness files changed | 7 | 6 |
| Mean time (s) | Added time (s) | |||
|---|---|---|---|---|
| Configuration | Hermes | OpenClaw | Hermes | OpenClaw |
| Recording disabled | 6.07 | 0.022 | — | — |
| Recording and HTTP store | 6.80 | 1.096 | 0.73 [0.70, 0.77] | 1.074 [1.059, 1.089] |
| Recording, store, and local chain | 7.83 | 1.787 | 1.76 [1.69, 1.85] | 1.765 [1.709, 1.821] |
| Records | Checkpoints | Total (s) | Prefix checks (s) | Peak memory (MiB) |
|---|---|---|---|---|
| 100 | 0 | 0.0023 | 78.8 | |
| 100 | 10 | 0.0030 | 0.0008 | 78.8 |
| 1,000 | 0 | 0.0132 | 85.0 | |
| 1,000 | 100 | 0.0201 | 0.0071 | 84.9 |
| 10,000 | 0 | 0.1307 | 0.0002 | 159.5 |
| 10,000 | 1,000 | 0.2029 | 0.0722 | 159.8 |
AI Accountability
AI accountability concerns how responsibility for AI decisions and harms is assigned, evidenced, challenged, and remedied.
See all 157 papers