Responsible disclosure
How to report a security vulnerability in PolicyVault.
This page mirrors PolicyVault's SECURITY.md.
Reporting a vulnerability
Open a GitHub security advisory on the PolicyVault repository (https://github.com/zapsoblige-hash/PolicyVault) — preferred — or a plain issue if the report is not sensitive. Please include reproduction steps.
There is no bug bounty at this time. Reports are credited unless you ask otherwise.
What to include in a report
To help a report get triaged quickly:
- What you observed, and what you expected instead.
- Exact reproduction steps — including which layer is involved (covenant/ VM, backend/API, SDK, web client, MCP server, a specific adapter).
- Whether the issue could be reproduced against the covenant directly (a Kaspa consensus rejection failing to trigger, or triggering incorrectly) versus only against the hosted application layer.
- Any relevant transaction ids, request ids, or logs — never include a seed phrase or private key in a report; PolicyVault never needs either to investigate an issue, and you should never send them to anyone.
How reports are evaluated
PolicyVault's stated security boundary is Kaspa L1 consensus (see Non-custodial architecture); reports are evaluated first against that boundary — does this let a covenant-invalid transaction succeed against consensus, even with a fully cooperating legitimate key-holder? — and then against the coordination layer (availability, information disclosure, tenancy correctness, UX that could lead to an unintended signature).
A concrete example of this process working end to end: a 2026-08-27 production defect in hosted tenancy's participant derivation briefly prevented an external approver's own wallet from seeing its vault and pending request. It was classified, fixed, covered by new regression tests, and disclosed honestly in the project's changelog as a strictly fail-closed availability defect with no funds, authority, or cross-tenant exposure — the kind of transparent handling you should expect for a genuine report.
Custody
There are no master keys, no admin bypass, and no custodial recovery. The hosted service never holds, requests, or reads seed phrases or private keys; signing happens exclusively in your own wallet. The one class of secret the hosted server holds at all is per-endpoint webhook signing secrets, used to sign outgoing webhook payloads.
See also: External audit status, If the hosted server is compromised.