Security policy

• Email security@deedglass.com.
• Please don't open a public issue, pull request or discussion for a security problem.

If your report holds something sensitive, say so in a first message and we will agree a channel.

• 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.

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.
• 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.

• 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.

• 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.

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.

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

• Attack suite: every case's expected outcome written down before its code, and the latest run (make attack).