Please report vulnerabilities privately via GitHub Security Advisories — do not open a public issue. You should receive a response within a few days. The latest release is the supported version — there is no support window and no backporting (docs/compatibility.md).

ochakai's security posture is deliberately narrow (see docs/design/0065-identity-and-provenance.md and requirements and configuration (Japanese)):

• It holds no warehouse credentials and never executes SQL.
• It does no authorization: whoever can reach a deployment can read and write, and identity is recorded as provenance only — never checked before it is believed. A deployment must never run publicly invokable: nothing verified the identity headers' signature, so a public one would let any caller name any person. (The publicly reachable MCP OAuth connector service existed briefly and was retired in 0.9.0.)
• The one exception is OCHAKAI_MODE=public (design doc 0066 §3): safe to run publicly only because it reads no identity and refuses every write. A deployment that is publicly readable and writable is not a configuration ochakai accepts — a report that this posture reads a header it should not, or that a write reaches the database through it, is a vulnerability.

Especially interesting reports, given that design:

• Ways a request could smuggle or spoof the forwarded identity when deployed as documented in deploy/cloudrun/README.md (Japanese).
• Anything that makes OCHAKAI_MODE=dev behavior reachable in a non-dev configuration.

Weaknesses that only manifest when the documented deployment posture is not followed (e.g. running the private service without Cloud Run IAM in front) are documentation issues rather than vulnerabilities — still welcome, as regular issues.