Only the latest release receives security updates. Pin to a specific version for production and upgrade promptly when a security advisory is published.

Do not open a public issue.

1. Preferred: use GitHub Private Vulnerability Reporting.
2. Fallback: email security@latchgate.ai with subject [LatchGate Security].

Include:

• Description of the vulnerability and its impact
• Reproduction steps or proof of concept
• Affected version(s) and component(s)
• Severity assessment if known (see classification below)

We use CVSS v3.1 for severity assessment:

These are targets, not guarantees. Complex issues may take longer. We will communicate progress to the reporter throughout.

We follow coordinated disclosure. We ask reporters to keep findings confidential until a fix is released. We will coordinate a disclosure timeline with the reporter and request a CVE where applicable.

We credit reporters in the release notes and security advisory unless anonymity is requested.

We consider security research conducted in good faith to be authorized and 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 they own or with explicit permission of the account holder
• Do not exploit a vulnerability beyond the minimum necessary to demonstrate it
• Report the vulnerability through the channels described above before any public disclosure

This policy covers all components of the LatchGate security boundary:

• Server runtime: latchgate-api, latchgate-kernel, latchgate-auth, latchgate-policy, latchgate-ledger, latchgate-providers, latchgate-core
• MCP adapter: latchgate-mcp (latchgate-mcp binary)
• SDK clients: Python SDK (latchgate on PyPI), TypeScript SDK (latchgate on npm)
• WASM provider interface: host I/O contracts, sandbox enforcement, module verification
• Supply chain: release pipeline, Docker images (ghcr.io/latchgate-ai/latchgate), install script, Homebrew tap (latchgate-ai/tap/latchgate)
• Cryptographic operations: DPoP proof generation/verification, Ed25519 receipt signing, JCS canonicalization, grant integrity

• Example and demo configurations shipped in examples/
• Third-party OPA policies authored by users
• User-authored WASM providers (report to the provider author)
• The documentation site itself (unless it serves executable content)

See the Security Model for trust boundaries, threat model, defense-in-depth layers, fail-closed behavior, and explicit non-goals. See Architecture for the system layer diagram, crate layout, and security invariants.