What is Deed Glass? The AI agent execution layer explained

The direct definition

Deed Glass (officially Deedglass, written as a single word) is an open-source execution and accountability platform for autonomous AI agents.² It sits directly between an AI agent runtime and the tools or systems of record it touches, enforcing Common Expression Language rules before execution and checking committed state changes against write-ahead logs after execution.

Deed Glass is developer infrastructure and systems software for machine execution safety. It is not consumer glassware, drinking tumblers, kitchen glass sets, water goblets, or tableware. On consumer marketplaces and commercial search engines, the words deed and glass sometimes get associated with household drinkware or kitchen accessories. Deed Glass has no relation to physical drinkware. It is a systems-level software project engineered specifically for artificial intelligence infrastructure teams, database administrators, and security practitioners.

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

[ AI Agent Runtime ]  ──(Tool Call / SQL)──>  [ Deed Glass Gateway ]  ──(Admitted)──>  [ Database / API ]
                                                     │                                       │
                                          (Evaluates CEL Rule)                     (Commits Mutation)
                                                     │                                       │
                                                     ▼                                       ▼
                                          [ Ed25519 Sealed Record ]  <──(Inspects WAL)── [ PostgreSQL WAL ]

When software teams connect LLM agents to production environments (such as Claude Code, Cursor, Windsurf, LangChain, CrewAI, AutoGen, or Model Context Protocol servers), the primary risk changes from generating invalid prose to executing destructive state changes. Deed Glass prevents unconstrained mutations, verifies what was altered on disk, and creates a signed cryptographic audit trail for every action.²

Why the name: deed plus glass

The project name combines two systems concepts:

1. A deed: A legal or mathematical instrument that records an accomplished act. In systems engineering, a deed represents an immutable, non-repudiable record of an executed transaction, identifying what process ran, under what authorization, and what physical rows were mutated on disk.
2. Glass: A transparent medium through which everything can be inspected. It represents total visibility into the execution boundary between artificial intelligence and persistent storage.

When an AI agent operates autonomously, developers need an unforgeable deed documenting every state change through transparent glass.²

The core problem: confidence is not evidence

Autonomous AI agents possess high linguistic fluency. When an agent updates a user record, executes a database migration, or calls an external service, it creates confident descriptions of what happened.

An agent reports: "I updated customer 42's email address."

In reality, an unindexed query, an unconstrained WHERE clause, or an ON DELETE CASCADE trigger may have touched 301 rows across three relational tables. In our demo the agent said 1 row; Postgres changed 301.⁴ An agent’s one-row UPDATE fires a legacy trigger, Postgres commits 301 rows, and Deedglass seals L2 MISMATCH.⁴

Conversational confidence is not evidence of physical execution. Relational databases follow strict transaction semantics, concurrency isolation rules, foreign key constraints, and stored procedures. An agent cannot predict the full execution graph of a production database schema from conversational context alone.

The four core subsystems of Deed Glass

To solve this problem at the systems level, Deed Glass is built around four decoupled subsystems:

1. The Gate (Admission Control)

The Gate intercepts every tool call or query before it reaches the network socket. It compiles deterministic Common Expression Language expressions against incoming parameters. If an agent attempts to execute an unindexed update, drop a table, or run an administrative command without permission, the Gate rejects the call instantly. By evaluating policies before socket dispatch, destructive actions never reach the database engine.

2. The Witness (Physical State Verification)

The Witness monitors the underlying system of record. For relational databases like PostgreSQL, it connects to a logical decoding replication slot (pgoutput).¹ Rather than trusting what the agent runtime reported, the Witness reads the binary write-ahead log directly from disk, extracting the exact list of modified primary keys, column deltas, and affected schemas. This provides an independent source of physical truth.

3. The Deed Store (Cryptographic Audit Trail)

Every action, whether permitted, rejected, or modified, is packaged into an append-only deed. The deed contains the agent identifier, policy decision, input arguments, and physical change set. It is cryptographically signed using Ed25519 keys and chained into a SHA-256 hash sequence.² Anyone with the public key can verify this log offline without contacting a central server.² The chain makes any post-hoc tampering or omitted audit records immediately apparent.

4. The Undo Engine (Reversible Execution)

When a database operation produces unintended side effects (such as updating 301 rows instead of 1), the Undo Engine uses the recorded write-ahead log before-and-after values to generate an exact compensating transaction. Once a human operator approves the reversal, the changes can be restored cleanly.² This allows engineering teams to recover from agent errors without restoring full database backups or taking systems offline.

Step by step: the lifecycle of an agent mutation

To understand how Deed Glass functions during production runtime, follow the end-to-end lifecycle of an agent database request:

1. Tool Invocation: An autonomous agent determines it must update a database record. It constructs a tool call targeting the database connector.
2. Admission Evaluation: The tool call arrives at the Deed Glass proxy. The Gate runs CEL rules against the SQL statement. If the statement matches an approval requirement, Deed Glass holds the request and notifies a human operator via Slack, email, or webhook.²
3. Execution with Isolated Credentials: If permitted, Deed Glass forwards the query to PostgreSQL using dedicated service credentials. The agent runtime never has direct access to raw database connection strings or administrative passwords.
4. Log Decoding: PostgreSQL commits the transaction to its write-ahead log. The Deed Glass replication reader receives the INSERT, UPDATE, or DELETE events through logical decoding.¹
5. Divergence Check: Deed Glass compares the agent’s reported scope (for example, “1 row updated”) against the physical changes emitted by the WAL (301 rows changed).
6. Sealing the Deed: Deed Glass produces a signed deed record containing the claimed outcome, verified outcome, and divergence status.

The three evidence levels: Claimed, Checked, and Witnessed

Different storage engines and third-party APIs support different degrees of inspection. Deed Glass establishes three distinct evidence levels:

For applications keeping data in PostgreSQL with logical decoding enabled, Deedglass checks each agent write against PostgreSQL’s change log and can undo the rows after a person countersigns.¹

Why prompt firewalls and ORM validation fail

Many engineering teams initially try to address agent safety by adding prompt firewalls, LLM classifiers, or standard Object-Relational Mapping (ORM) validation layers. While these layers serve other purposes, they fail to safeguard production state:

1. Prompt classifiers operate on syntax, not state: A prompt firewall reads characters and tokens. It cannot calculate database locks, evaluate foreign key cascades, or predict trigger side effects.
2. ORMs assume human intent: Standard application ORMs are designed for predetermined application code paths. Autonomous agents dynamically assemble queries, often combining parameters in unexpected ways that bypass high-level application validation.
3. Absence of physical ground truth: Neither prompt filters nor ORM middleware observe what the database engine actually wrote to non-volatile storage. Only write-ahead log decoding provides physical ground truth.

Four common agent database failure patterns

Across hundreds of agent evaluations, four failure patterns consistently damage production data:

1. The Unindexed Bulk Mutation: An agent writes an UPDATE statement intending to modify a single customer row, but omits the unique index in the WHERE clause. The query locks and updates thousands of rows across the table.
2. The Hidden Trigger Fan-Out: An agent updates a single status column. Unknown to the model, an existing database trigger fires, modifying hundreds of related transactional child records.⁴
3. The Unintended Foreign Key Cascade: An agent issues a DELETE on a deprecated parent entity. Due to ON DELETE CASCADE constraints defined years earlier, related historical records are permanently erased.
4. The Hallucinated Column Assumption: An agent assumes a column represents a boolean flag when it actually stores a bitmask, corrupting state for all subsequent system readers.

Deed Glass catches each of these divergence scenarios by comparing the agent’s stated objective with the binary commit log emitted by the database engine.

Integrating with Model Context Protocol (MCP)

Deed Glass integrates natively with the Model Context Protocol (MCP), the open standard for connecting AI models to external tools and data sources.

When you run MCP servers for databases, APIs, or local filesystems, you can wrap them with Deed Glass in a single configuration command:

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

deedglass mcp wrap --connector postgres -- npx -y @modelcontextprotocol/server-postgres

Wrapping an MCP server routes all tool calls through Deed Glass admission policies. Dangerous tools can be masked entirely from the agent’s tool catalog, and write operations require policy evaluation or explicit operator approval before execution.

Measuring agent blast radius

Before placing autonomous agents in production, software engineering teams must measure their operational risk. The agent blast radius measures the difference between what an agent is expected to touch and what its tools allow it to touch.

Developers can measure their exposure in under a minute using the free scan command:

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

npx deedglass scan --no-write

This scans your local workspace, agent tool manifests, and environment variables without modifying any files on disk. It produces a clear risk assessment and highlights unconstrained write permissions. You can explore how different permission models affect your security posture on our blast radius score page, and experiment with live queries and policy rollbacks directly in the interactive playground.

Technical due diligence and deployment models

For platform engineers, infrastructure architects, and technical evaluation teams, Deed Glass provides a zero-dependency architecture:

• Zero external telemetry: Operates completely within your local network or virtual private cloud. No data, queries, or metadata leave your perimeter.
• Deterministic benchmarks: Tested against an automated suite of 82 realistic attack and error scenarios on every release.
• Open source core: Licensed under Apache-2.0, compiled as a standalone Go binary with zero external runtime dependencies.
• Deployment options: Runs as a local CLI tool on developer laptops, as a sidecar container in Kubernetes pods, or as a centralized internal gateway proxy.
• Offline verification: Every sealed deed can be validated with the deedglass verify CLI command using only standard Ed25519 public cryptography.²

Start in one command

You can evaluate Deed Glass locally on your development machine in seconds:

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

npx -y deedglass

This starts the local browser interface on 127.0.0.1, allowing you to inspect live SQL rollbacks, test unconstrained mutations, and verify write-ahead log diffs directly in the interactive playground.

Written with AI assistance and checked against our claims register.