Deedglass

Deedglass

Check what your AI agents actually changed.

An agent said it updated 1 row. Postgres changed 301.

Safety for AI agents that work on databases and health records. Rules decide each AI agent tool call;

Deedglass checks what really changed and seals a record. Open source, self-hosted, every feature free.

Start in one command

npx -y deedglass

An app opens in your browser. It runs on your own computer, signed in, with no account, no sign-up and no Docker or database to set up, and nothing is sent to us. Choose who will use it (a clinic, hospital IT, or people building with AI), then connect Claude Desktop, Cursor, VS Code, a record system or a database. You need Node 18 or newer. Read Start here for a short tour, or try it without installing anything at deedglass.com/play.

For developers, three commands:

npx -y deedglass start      # an agent reports 1 row, Postgres changed 301, and it's caught

npx -y deedglass protect # guard Claude Code, Cursor and other coding agents npx -y deedglass help # the eight everyday commands; "help all" lists every command

Without Docker, start plays the same scene inside the binary, every line labelled live or replay, in under 30 s. More: Quickstart · Docs · Policy Generator · Healthcare · Benchmarks · Security · deedglass.com

Found it useful? A star helps other people find Deedglass. To hear about new releases, use Watch › Custom › Releases.

What it does

Deedglass 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 (Claimed, Checked or Proven; Matches, Doesn't match or Can't check), and each result is sealed as a signed record anyone can check offline. It can undo the rows an action changed.

A real run of make demo-hero (commit 97a524c, 2026-10-14), each line shown at the time it printed. Source: docs/assets/demo-hero.cast.json , recorded by scripts/demo/capture.mjs and drawn by scripts/demo/cast2svg.mjs ( make demo-svg ).

Install

curl -fsSL https://deedglass.com/install.sh | sh   # macOS and Linux: checks the sha256, copies deedglass into ~/.local/bin

npx -y deedglass help # or run it with no install (Node 18 or newer) npm install -g deedglass # or install it from npm

The install script downloads the release archive for your platform, checks its sha256 against the release's checksums.txt (and the signature, when cosign is installed), and copies deedglass into ~/.local/bin; read it first: scripts/install.sh. It downloads from a copy of the release on deedglass.com and falls back to GitHub: about 7 s on one network in India, where the GitHub-only install took 81-119 s. A public container image is coming; until it's published, build the image locally as above. Checksums, signatures and SBOMs: docs/INSTALL.md.

Who it's for

• Developers with agents on databases. Claude Code, Cursor or your own agent writes to Postgres. Your rules decide each call first, Postgres's change log shows what really committed, and the rows one action changed can be undone after a person countersigns. MySQL and other databases can be checked from a Debezium change feed (docs/WITNESS_DEBEZIUM.md).
• Health-tech teams and hospitals on FHIR. The FHIR connector (beta) puts a FHIR R4 server behind Deedglass with SMART Backend Services, reads each write back at the version the server reported, and checks Proven on HAPI FHIR JPA 8.x and Medplum 5.x running on Postgres. See deedglass.com/healthcare and the FHIR benchmark. To see it on synthetic data first, with no Docker and no server, run npx deedglass health pilot (the 15-minute hospital pilot).
• Security teams. Lockdown makes every agent write wait for a person, needs two people for high-risk writes and for turning lockdown off, and keeps each agent to one connector (docs/LOCKDOWN.md). Records are signed and anyone can check them offline with deedglass verify.

Project status

• Pre-1.0. Every release is in CHANGELOG.md and on the releases page. The deed format is a versioned public spec (spec/), so old records keep verifying.
• One maintainer. Deedglass is built by Arjun Prabhakaran in India (GOVERNANCE.md). Replies are best effort (SUPPORT.md).
• Free and self-hosted. Every feature is free while we grow, including ee/, and it runs on your machines with your own Postgres. Nothing checks a licence and nothing is sent to deedglass.com (Security).
• Not yet: no SOC 2 report, no outside penetration test and no SSO. Known limits are in docs/LIMITATIONS.md and KNOWN_ISSUES.md.

How it works

flowchart LR

A["AI agent Claude · OpenAI · Cursor · any MCP client"] -->|tool call + agent key| R subgraph D["Deedglass · one binary + Postgres"] R["1 · Rules allow · deny · ask a person"] --> X["2 · Run with credentials from the vault"] X --> C["3 · Check what really changed"] --> S["4 · Seal a signed record"] end X --> T["Tools Postgres · FHIR · GitHub · Slack · Stripe · MCP servers"] T -->|change log or read-back| C S --> U["Undo Postgres rows, after a person countersigns"] H[People] -->|approve · stop| R

Every tool call passes through Deedglass with the agent's key. Your rules (policies) decide allow, deny or require_approval; Deedglass runs the call with credentials the agent never holds; the check compares what happened with what was asked; and the outcome is sealed as a record in the org's chain.

How sure each check is

Each record claims one level and one result: Matches, Doesn't match or Can't check. When Deedglass can't tell whether a tool ran, the result is Can't check, never Matches. The API keeps the short names (L0/L1/L2, VERIFIED/MISMATCH/UNVERIFIABLE); the glossary maps them.

The 301-row scene

What an agent reports is not always what the system stored, and a log the agent writes itself can't show the difference. An agent was asked to mark order 42 as shipped. It ran one UPDATE and its tool reported 1 row. A legacy trigger shipped 300 more orders in the same transaction. This is the real output of the Quickstart's last step on 2026-10-14 (shortened where you see …):

$ npx -y deedglass init --trigger

… ✕ UPDATE order 42 Proven · Doesn't match · Postgres changed 301 rows in public.orders. The agent reported 1. expected UPDATE 1 row in public.orders where id = 42 · sets status observed UPDATE 301 rows in public.orders · 300 outside id = 42 … ✓ Trigger off orders_ship_open_batch dropped ✓ Undo preview Undo available · 301 rows in public.orders · 301 updates policy undo-needs-approval · a person countersigns first

The agent's log says 1 row. Deedglass read Postgres's own change log for that transaction, found 301, sealed the difference as a record, and planned an undo from those rows that runs only after a person countersigns.

Quickstart

Docker running with about 2 GiB of free disk, Node 18 or newer, and macOS or Linux, then (from the tested Quickstart). On Windows, npx deedglass runs the native Windows binary, no WSL needed; deedglass init uses Docker on macOS and Linux, so on Windows start with npx deedglass app, which needs no Docker:

mkdir acme-agents && cd acme-agents

npx -y deedglass init --yes npx -y deedglass doctor npx -y deedglass init --trigger

<!-- quickstart:end -->

deedglass init starts two Postgres 18.6 containers in Docker (Deedglass's own database and a demo database), runs deedglass serve on 127.0.0.1:8080, creates an org, an agent and the postgres-check policy (reads and writes run, every write is checked at Proven, DROP and TRUNCATE never run; use postgres-safe in production, where writes wait for a person), and ends with a blocked DROP TABLE and an UPDATE checke