systemprompt.io is self-hosted AI governance infrastructure. Customers run the binary inside their own compliance boundary, so vulnerabilities in this codebase can affect regulated environments (HIPAA, SOC 2, ISO 27001 programmes). We take reports seriously and prioritise coordinated disclosure.

Email: ed@systemprompt.io

Include, where possible:

• Affected version(s) and commit hash
• Reproduction steps or proof-of-concept
• Impact assessment (confidentiality / integrity / availability)
• Any suggested mitigation

Please do not open public GitHub issues for security reports. If you need an encrypted channel or a Signal handoff, request one in your initial email and we will arrange it.

We will keep you informed throughout triage. If a fix requires more time than the SLA above, we will tell you why and agree an extended timeline in writing.

0.63.0 is the next release; when it ships, 0.62.x becomes the previous minor and 0.61.x leaves support.

While the project is pre-1.0, security fixes land on the current minor release. The previous minor receives Critical and High fixes until the minor after it ships, at which point it moves out of support. Production deployments should track the latest 0.x minor release.

In scope for this policy:

• The systempromptio/systemprompt-core repository and all crates it publishes to crates.io under systemprompt-*
• The systemprompt facade crate
• The systemprompt-bridge binary, including its manifest-apply, cloud-backup and credential-helper flows
• Official release binaries attached to GitHub releases

Out of scope:

• The marketing site at systemprompt.io (report via the same email, but not governed by this SLA)
• Third-party extensions built against our public trait interfaces
• Vulnerabilities in upstream dependencies that we cannot remediate (we will forward to maintainers)
• Denial-of-service via unrealistic resource consumption against a local development build

We will not pursue legal action against researchers who:

• Make a good-faith effort to avoid privacy violations, data destruction, and service disruption
• Only interact with accounts and data they own or have explicit permission to test
• Report the vulnerability privately to the address above and give us reasonable time to remediate before public disclosure

If your research requires testing against a production deployment not owned by you, obtain written permission from that deployment's owner first.

• Dependencies are audited continuously with cargo deny against the RustSec advisory database, covering advisories, licences, banned crates and registry sources across every workspace in the repository. It runs on each push, on each pull request, and on a daily schedule — see .github/workflows/supply-chain.yml.
• Advisories we have assessed and accepted are recorded, each with a written justification, in deny.toml. We publish the register rather than reporting a clean scan: as of 0.62.0 it holds fifteen entries. Three concern the published crates' lockfile — one reachable at runtime (rsa, RUSTSEC-2023-0071), one optional dependency that is never compiled (rkyv), and one build-time-only proc-macro (proc-macro-error2) — and twelve are reachable only from the desktop bridge's Linux windowing stack, which the bridge does not compile.
• systemprompt-bridge release binaries are built in GitHub-hosted CI runners from tagged commits and signed with Sigstore (cosign keyless, OIDC-bound to this repository and workflow) — see .github/workflows/release-sign.yml. Verify one with:

  cosign verify-blob \
    --certificate-identity-regexp 'https://github.com/systempromptio/systemprompt-core/.*' \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    --signature <artifact>.sig \
    --certificate <artifact>.pem \
    <artifact>
  

• The core platform ships as source and as systemprompt-* crates on crates.io; those artefacts are not signed by us. Organisations that repackage the platform for internal distribution sign the resulting artefact packs under their own key and provenance.
• A CycloneDX SBOM can be generated on demand from the committed Cargo.lock with cargo cyclonedx. It is not currently produced or attached by CI.

A self-hosted installation sends nothing to the vendor. The server binary has no crash reporting, no usage or licence pings and no update check. Its only outbound connections are ones the operator configures:

1. Upstream AI providers — the endpoints declared in the services manifest, called when a gateway or agent request is routed to them.
2. OpenTelemetry export — the OTLP endpoint in the profile's observability.otlp block. Unset by default, in which case nothing is exported.
3. systemprompt.io cloud — api.systemprompt.io, contacted only when a cloud profile (target: cloud) or the systemprompt cloud commands are used, for tenant credentials and deployment. A self-hosted profile never contacts it.
4. Bridge release feed — when the services manifest declares a bridge releases repository, the gateway resolves the newest bridge release from that GitHub repository on a desktop bridge's request, cached per platform.

The desktop bridge checks for its own updates against the gateway it is enrolled with (/v1/bridge/latest), never against the vendor, and only when its auto-update policy allows. Outbound egress controls describes how every outbound request is guarded and the egress policy a deployment still provides; the four channels above are what that policy has to allow.

• Threat Model
• Compliance Control Matrix
• RFI Readiness Audit — security-review posture, accepted risks, and known gaps
• Stability Contract
• Compatibility Matrix
• Deploy in Production