This policy applies to every repository in the PromptSign organization that does not publish its own.

A PromptSign verifier becomes a trust root the moment anything relies on it: harnesses, marketplaces, and CI systems act on its verdict. When a verifier accepts something it should reject, the whole property fails and nothing announces it. We treat reports 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:

• promptsign-cli
• promptsign-core
• promptsign-node
• spec
• promptsign-npm

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, in order of usefulness:

1. The artifact that demonstrates it: a bundle, manifest, policy, or feed that verifies when it should not, or fails when it should not.
2. The exact command and version (promptsign --version, or the package version), and the platform.
3. Which implementations you tried. "Rust accepts this and Node rejects it" is itself a finding, even if you cannot say which one is 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, and we close such reports 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." We document that choice, and every surface that shows a result repeats it.

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. We credit reporters in the advisory unless they ask otherwise. There is no bug bounty.

Nothing in this policy asks you to delay disclosure without end. If we go quiet on you, say so in public.