This policy applies to every repository in the PromptSign organization that does not publish its own.
PromptSign's verifiers become a trust root the moment anything relies on them: harnesses, marketplaces, and CI systems act on their verdict. A verifier that accepts something it should reject is not a bug in a utility — it is the whole property failing silently. Reports are treated accordingly.
Please report privately, not in a public issue.
Use GitHub's private vulnerability reporting on the affected repository — Security → Report a vulnerability — which opens a draft advisory visible only to you and the maintainers:
If you are not sure which repository is affected, or the issue spans several, email info@promptsign.ai instead. A flaw in the format itself belongs to the spec repo, not to whichever implementation you happened to find it in.
Helpful to include, roughly in order of usefulness:
- The artifact that demonstrates it — a bundle, manifest, policy, or feed that verifies when it should not, or fails when it should not.
- The exact command and version (
promptsign --version, or the package version), and the platform. - Which implementations you tried. "Rust accepts this and Node rejects it" is itself a finding, even if neither is obviously wrong.
- A verifier accepting a bundle it must reject, or rejecting one it must accept — signature, manifest integrity, unlisted files, or malformed input.
- Divergence between implementations on canonical bytes, digests, or verdicts. The format is only real if two implementations agree on it.
- Trust-policy or trust-on-first-use bypass: getting a name accepted under an identity that policy does not permit, or changing a pinned signer without a hard failure.
- Manifest path handling — absolute paths,
..traversal, symlinks, or anything that writes or reads outside the target directory. - Keyless verification flaws: certificate chains that should not validate, accepted signed entry timestamps, certificate validity mishandled at log-integration time, or identity taken from display hints rather than the certificate.
- Revocation feed handling — accepting a feed from an unpinned signer, mis-scoping an identity revocation, or mishandling staleness.
- Any network access on a verify path. Verification is offline by design; a verifier that can phone home is both a tracking beacon and a thing that can be down.
- The CLI's online paths: token handling and caching, the browser login flow, the local CORS proxy, and trust-root fetching.
- Supply-chain exposure in a verifier's dependency tree.
These are real risks, but they are not defects in PromptSign — the specs say so explicitly, and a report of one will be closed with a pointer here:
- Malicious content that is honestly signed by a publisher someone chose to trust. A signature names an accountable party; it does not vouch for their content. A signed prompt-injection payload is still a prompt-injection payload.
- Runtime prompt injection from web pages, tool output, or anything an agent pulls in mid-session. None of it was signed, so there is nothing to verify.
- Model jailbreaks — a property of the model and its guardrails, not of an artifact's provenance.
- Compromise of the consumer's own machine. An attacker who can rewrite instruction files can also rewrite the verifier that checks them.
- Reports whose substance is that "signed" does not mean "safe." That is documented, deliberate, and stated everywhere a result is surfaced.
We aim to acknowledge a report within a few days and to agree a disclosure timeline with you from there; a fix ships before details are published. Reporters are credited in the advisory unless they ask otherwise. There is no bug bounty.
Nothing in this policy asks you to delay disclosure indefinitely — if we go quiet on you, say so publicly.