Deedglass

Deedglass is an open-source, self-hosted layer built by Arjun Prabhakaran that sits between AI agents and the systems they change. Rules decide each tool call, a check compares what the system really changed with what the agent reported, and each result is sealed as a signed record anyone can check offline. The latest release listed is 0.15.0, and the core is Apache-2.0.

What It Is

Deedglass is a safety and verification gateway for AI agents that write to databases and health records. Agents connect through Deedglass with a Deedglass key instead of the tool's real credentials. Rules allow, block or ask a person before the call runs. Afterward, Deedglass reads the result from the real system and records a verdict of Matches, Doesn't match or Can't check.

Its headline demo shows an agent reporting an update to 1 row while Postgres's change log shows 301 rows changed because of a legacy trigger. Deedglass seals the difference as a record and can plan an undo that runs after a person approves.

How the checks work

Each check carries one of three evidence levels. Claimed means the tool reported success. Checked means Deedglass read the result back from the target, such as GitHub, Slack, Notion or Stripe sandboxes. Proven means the system's own change log shows what committed, which applies to Postgres, to FHIR servers on Postgres (HAPI FHIR JPA 8.x and Medplum 5.x), and to MySQL through a Debezium change feed. Proven checks on Postgres need wal_level = logical and REPLICA IDENTITY FULL on watched tables.

Ways to use it

Running npx deedglass opens a local console in the browser with no Docker, account or database to set up. Developers can run a read-only scan that grades MCP configs and agent setups from A to F, wrap an MCP server with deedglass mcp wrap, or wrap a function with the TypeScript SDK. A shell guard can ask before commands such as prisma migrate reset or DROP TABLE run in Claude Code and other coding agents. Observe mode watches a session and reports which rows Postgres committed, and can save undo SQL.

Records, approvals and limits

Sealed records are Ed25519-signed and hash-linked, so they can be verified offline with the public key. Only a person can approve actions, and a stop switch halts agents. The project states it has no SOC 2 report, no outside penetration test and no SSO. A healthcare edition covers FHIR R4 write verification.