Security policy
Primary Path is a control plane for consequential AI-agent actions. A vulnerability in it is a vulnerability in every action it governs, so reports are treated as the highest-priority work in the repository.
Reporting a vulnerability
Report it privately, in either of two ways:
- GitHub: private vulnerability reporting on om-er/primarypath-releases (Security → Report a vulnerability). Reports there are visible only to the maintainers, and the fix can be coordinated in the same place.
- Email: security@primary-path.com, if you would rather not use GitHub.
Nothing about a report appears in issues, pull requests or commit messages until a fix has shipped. Please do not open a public issue for anything you believe is a security problem. The same contacts are published at https://primary-path.com/.well-known/security.txt (RFC 9116).
Include what you can of: the affected version (the image tag, the
package version, or version from GET /healthz), the component
(server, console, an SDK, the MCP gateway, the CLI verifier, the chart),
reproduction steps, and the
impact as you understand it against the threat model.
Proof-of-concept code is welcome; a working exploit against someone
else’s deployment is not.
What to expect
| Step | Target |
|---|---|
| Acknowledgement | within 3 business days |
| Triage and severity (against the threat model’s adversaries and assets) | within 7 days |
| Fix for a confirmed high or critical finding | within 30 days, or a stated reason why not |
| Public disclosure | coordinated with the reporter; by default when the fix is released, and no later than 90 days after triage |
Credit is given in the release notes unless you ask otherwise.
Supported versions
Fixes are released on the newest minor version, and on the previous minor version for high or critical findings. Older releases do not receive fixes; upgrade paths are in docs/COMPATIBILITY.md.
| Version | Security fixes |
|---|---|
newest minor (1.y) | all severities |
| previous minor | high and critical |
| older | none |
Scope
In scope: everything a release ships — the server, the console, the Python and TypeScript SDKs, the MCP gateway and framework shims, the offline verifier CLI, the demos, the container image, compose files and Helm chart, and the documented guarantees. The security whitepaper lists what the product claims; a way to make any of those claims false is in scope even if it needs a credential the threat model already grants.
Out of scope: findings that require a malicious database superuser or host root (stated non-protections in the threat model), vulnerabilities in the customer’s own IdP, chat platform, SIEM or Postgres, and denial-of-service by volume against a deployment whose ingress has no rate limit of its own (the built-in limiter is per replica, as documented).
Verifying what you run
Exported audit bundles are verifiable offline against a pinned key (docs/verifier-guide.md). Every release’s image, chart and files are cosign-signed and ship with SBOMs; docs/verifying-downloads.md has the verification commands.