Responsible disclosure

Deedglass records what AI agents did, so people rely on it when something goes wrong. If you find a way to make it record the wrong thing, run something it shouldn’t, or show one org’s data to another, we want to hear about it, and we are grateful when you tell us first. This page is the repository’s SECURITY.md.

Reporting

• Email security@deedglass.com. The address is being set up. Until this note is removed, also send your report through GitHub private vulnerability reporting (below), so it can’t be lost.
• GitHub private vulnerability reporting on github.com/deedglass/deedglass (Security › Report a vulnerability), once the repository is public.
• Please don’t open a public issue, pull request or discussion for a security problem.

No encryption key is published yet. If your report holds something sensitive, say so in a first message and we will agree a channel. The machine-readable contact is /.well-known/security.txt (RFC 9116).

What to include

• What you found and what an attacker could do with it.
• The steps to reproduce it, from a fresh deedglass init if you can.
• The version (deedglass version), the operating system, and the Postgres version.
• Whether you want to be credited, and how.

What we will do

We are a small team, so these are the times we can keep:

• Acknowledge your report within 3 business days.
• Assess it within 7 business days: whether we can reproduce it and how severe it is (the scale in the security review).
• 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 before we publish a fix, and credit you in the release notes and the security review if you want credit.

There is no bug bounty at this stage. We can’t pay for reports yet, and we won’t pretend otherwise.

Scope

• The deedglass binary: serve, the Gate, policies, connectors, the vault, the Witness and the decoder, deeds and deedglass verify.
• The Console and the approval pages it serves.
• The CLI, including deedglass init, doctor, scan and mcp wrap.
• The SDKs: @deedglass/sdk (TypeScript) and deedglass (Python).
• docs.deedglass.com and deedglass.com.
• The hosted beta, when it exists.

Out of scope

• Volumetric denial of service, and load tests against anything you don’t run yourself.
• Social engineering of anyone, and physical attacks.
• Findings that need a compromised Deedglass host, database superuser or seal key first.
• Missing headers on static pages with no sensitive data, without a demonstrated impact.
• Rate-limit reports without demonstrated harm.
• How often a model falls for a prompt injection. Deedglass limits and records what a manipulated model’s tool calls can do; it doesn’t measure the model.

Safe harbour

We won’t pursue or support legal action against research done in good faith within this policy. In return, please:

• Test against your own installation, or your own org on a hosted instance.
• Don’t access, change or keep anyone else’s data. If you see someone else’s data, stop, and tell us what you saw without copying it further.
• Give us a reasonable time to fix a problem before you talk about it publicly.

Supported versions

The latest minor release gets security fixes. Before 1.0, that is the latest release.

How Deedglass is built to resist attack

• Threat model: assets, trust boundaries, attackers, and the control and test for each threat, with what stays possible.
• Attack suite: every case’s expected outcome written down before its code, and the latest run.
• Security review: what was checked, what was found and what was done.
• Limitations: every known limit.