Security
Security you can check yourself.
What we do, what we attack it with, what never leaves your side, and where it stops. In plain words.
70 of 70
attacks in our public suite end exactly the way we wrote down before running them. None differ today. Any that do get published too.
See every attack- Rules and SQL7/7
- Check against the database4/4
- Identity, intents and budgets4/4
- Connectors, egress and secrets4/4
- Check against the database: expected and seen13/13
- Approvals, links and webhooks8/8
- Undo5/5
- Observe mode2/2
- People, sessions and the live stream8/8
- Hostile MCP servers and upstreams8/8
- Resources, records and output7/7
How it's built.
It fails closed.
If Deedglass, its database or a rule can’t be reached, agents are blocked, not waved through.
Agents never hold the keys.
Connection secrets are encrypted and used only by Deedglass, so an agent can’t walk off with them.
People approve risky actions.
A rule can require one or two people. An agent can never approve itself.
Records check offline.
Each record is signed and linked to the one before. Checking needs only the public key, not us.
Your data stays on your side.
Self-hosted Deedglass sends us nothing. There's no telemetry. Your records, rules and credentials stay in your own Postgres, and your records are signed with a key you hold, so they still check if we're gone.
This site sets no cookies and loads nothing from other domains.
- Telemetry
- None
- Records and rules
- Your Postgres
- Signing key
- Held by you
- Checking a record
- Offline, with the public key
What it doesn't protect against.
We'd rather you hear the limits from us.
A machine someone else controls.
Whoever controls the server running Deedglass controls what it records.
Records cut from the end.
The chain shows a changed, removed or reordered record anywhere before the newest one. Removing the newest records isn’t visible in the chain alone.
A stolen signing key.
Records signed with it look genuine until the key is replaced and revoked.
Agents that skip Deedglass.
An agent that holds its own credentials and never asks first isn’t covered.
Changes we can’t see.
Schema changes, tables we don’t watch and systems we can’t read back. Then the result is Can’t check, never Matches.
Acknowledge
3 business days
Acknowledge your report within 3 business days.
Assess
7 business days
Assess it within 7 business days: whether we can reproduce it and how severe it is.
Fix or mitigate
30 days
Fix or mitigate a high-severity issue within 30 days, or tell you why it takes longer and what we are doing meanwhile. Medium and low issues are scheduled and you hear when.
Tell you
Tell you before we publish a fix, and credit you in the release notes and the security review if you want credit.