How to build an insurable autonomous AI agent: the technical specification

The emerging crisis of agentic liability

Over the past year, enterprise adoption of autonomous AI agents has accelerated across software engineering, healthcare administration, and financial operations. Agents now issue refunds, modify database records, and execute terminal commands.¹

With this expansion has come an emerging corporate challenge: insurability.

When an employee makes an operational mistake that causes data loss, existing Errors and Omissions (E&O) and cyber liability policies provide coverage based on established human governance workflows. When an autonomous software agent executes an unconstrained SQL command that purges a production table, underwriters ask a different set of questions:

• What controls prevented the model from executing that command?
• Where is the mathematical audit trail proving what the agent requested versus what the database committed?
• Who signed off on granting write credentials to an autonomous loop?

If an engineering team answers: “We instructed the model in its system prompt to be careful”, underwriters increasingly exclude autonomous agent actions from corporate policy coverage. Uncontrolled autonomy is considered an unquantifiable underwriting risk.

To achieve enterprise insurability, AI agent deployments must satisfy a rigorous technical specification based on deterministic engineering controls.

The three requirements for insurable autonomy

Underwriting standards and institutional risk committees require three technical safeguards before autonomous agents can be cleared for production write operations:

Code What the screen or file shows, copied as is.

┌────────────────────────────────────────────────────────┐
│                   Insurable Agent Stack                │
└───────────────────────────┬────────────────────────────┘
                            │
                            ▼
┌────────────────────────────────────────────────────────┐
│ 1. Pre-Execution Admission Control                     │
│    Deterministic CEL gates blocking unsafe statements  │
└───────────────────────────┬────────────────────────────┘
                            │ Allowed Operation
                            ▼
┌────────────────────────────────────────────────────────┐
│ 2. Independent Physical Verification                   │
│    Postgres WAL row diff inspection via decoding       │
└───────────────────────────┬────────────────────────────┘
                            │
                            ▼
┌────────────────────────────────────────────────────────┐
│ 3. Cryptographic Provenance Ledger                     │
│    Ed25519 hash-chained records verified offline       │
└────────────────────────────────────────────────────────┘

Requirement 1: Hard admission boundaries

Prompt-level constraints do not constitute legal or technical controls. A model can hallucinate, experience context drift, or fall victim to indirect prompt injection. Insurable architectures mandate that tool invocations pass through an independent, declarative policy engine before reaching the target socket.⁴

Requirement 2: Independent storage verification

The agent’s conversational summary cannot serve as operational truth. An agent may declare that it updated a single user record, while underlying database foreign key cascades deleted hundreds of records. Insurable systems inspect the physical change log on disk to verify actual state transitions.²

Requirement 3: Tamper-evident audit ledgers

Standard text logs can be edited, deleted, or truncated by compromised credentials. Underwriters require cryptographic permanence: every action, admission decision, and storage diff must be signed with private asymmetric keys and linked into a hash chain that can be verified offline.⁴

Deterministic admission control at the socket

The first line of defense is an external policy gate that intercepts tool calls before the driver or API executes them.⁴

Consider an agent operating an MCP database server. In an unmonitored setup, the agent sends raw SQL directly to PostgreSQL. In an insurable setup, the agent connects through Deedglass, which evaluates each request against Common Expression Language (CEL) rules:

Code A settings file: the rules a tool reads before it acts.

version: deedglass:policy/v1
name: enterprise-database-policy
rules:
  - id: block-schema-modifications
    match: { connector_type: postgres }
    when: sql.kind in ["drop", "truncate", "alter"]
    decision: deny
    reason: Autonomous agents are prohibited from modifying relational schema.
  - id: require-two-party-approval-for-bulk-writes
    match: { tool: "postgres.execute" }
    when: sql.kind in ["update", "delete"] && sql.estimated_rows > 10
    decision: require_approval
    reason: Bulk operations exceeding 10 rows require human authorization.

When an agent proposes an action, the gate evaluates the abstract syntax tree of the statement. If the statement violates an organizational rule, it is rejected deterministically. The database never executes the statement.

You can evaluate how declarative policy rules intercept dangerous commands using the interactive /check/ai change inspector.

Physical verification via database replication

Even when an agent sends an allowed statement, the execution outcome must be verified independently of the model.

Deedglass connects to PostgreSQL logical decoding replication slots using the deedglass_witness role.² As transactions commit, PostgreSQL writes before-and-after row images to its write-ahead log. Deedglass reads this change stream and compares the committed tuple diff against the agent’s intent:

Code What the screen or file shows, copied as is.

Intended Action: UPDATE orders SET status = 'shipped' WHERE id = 'ord_1001'
Agent Verbal Claim: "Updated order ord_1001"
Postgres Change Log: 1 row modified in public.orders (committed in txid 84019)
Verdict: Checked (Matches ground truth)

If an agent runs an update that triggers a relational cascade across auxiliary tables, Deedglass observes the complete list of committed row modifications. Furthermore, because the pre-image values are preserved in the change log, Deedglass produces an atomic undo SQL script to restore state if human review finds the action was unintended.⁴

Test atomic undo generation and review simulated cascade scenarios on the browser-based /play sandbox.

Cryptographic record chains for claims and audits

When cyber underwriters or corporate auditors investigate an operational incident, they require immutable forensic evidence.

Deedglass compiles each evaluated action, its policy verdict, its execution timestamp, and its committed storage diff into a canonical JSON record. The record is hashed using SHA-256 and signed with private Ed25519 keys:

Code Data in JSON, the format software uses to pass records and settings.

{
  "record_id": "rec_01k8312a",
  "timestamp": "2026-11-02T14:30:00Z",
  "agent_id": "claude_code_session",
  "tool": "postgres.execute",
  "decision": "allow",
  "evidence": "Checked",
  "storage_diff": {
    "table": "public.orders",
    "rows_affected": 1
  },
  "prev_hash": "a4f89d...3b21",
  "signature": "ed25519...99c4"
}

Because each record embeds the cryptographic hash of the record preceding it, historical transactions cannot be deleted, reordered, or modified without invalidating the entire ledger. External auditors can verify the chain offline using standard command-line tools without network telemetry or vendor dependencies.

Benchmarking your agent stack before underwriting

Before submitting autonomous agent workflows to an insurer or enterprise security committee, development teams should grade their current blast radius.

Run the open-source scanner from your project root:

Code Commands typed in a terminal. The text around it says what happens.

npx deedglass scan

The scan reviews your project configurations (.cursor/mcp.json, claude_desktop_config.json, .vscode/mcp.json) and database roles locally. It computes an objective security score from A to F based on five criteria:

1. Absence of superuser and bypass row security flags on database roles
2. Enforcement of read-only flags on MCP servers
3. Gating of dangerous write paths with declarative policy
4. Active change log verification via replication slots
5. Isolation of credentials from LLM prompt contexts

To review the exact formula and worked deduction examples, consult the detailed scoring rubric on /score.

By implementing deterministic admission gates, verifying committed diffs directly from database change logs, and sealing immutable cryptographic records, engineering organizations build an autonomous agent stack that meets the highest standards of enterprise governance and insurability.

Written with AI assistance and checked against our claims register.