Use this section to tell people about which versions of your project are currently being supported with security updates.
| Version | Supported |
|---|---|
| 5.1.x | ✅ |
| 5.0.x | ❌ |
| 4.0.x | ✅ |
| < 4.0 | ❌ |
Use this section to tell people how to report a vulnerability.
Tell them where to go, how often they can expect to get an update on a reported vulnerability, what to expect if the vulnerability is accepted or declined, etc.
If you discover a security vulnerability in OpenCoven, please report it responsibly.
Do not open a public GitHub issue for security vulnerabilities.
Contact the maintainers directly:
- Discord: https://discord.gg/OpenCoven (DM @BunsDev)
- Or open a GitHub Security Advisory on the repository
We will acknowledge receipt within 48 hours and aim to address confirmed vulnerabilities within 14 days.
Security reports are welcome for:
- OpenCoven core harness and routing logic
- OpenTrust memory and session substrate
- Authentication and identity handling
- Agent sandbox and execution boundaries
- Any mechanism that could allow one agent or user to access another's context
- Issues in third-party dependencies (report to the dependency maintainer)
- Issues in model provider APIs (report to the provider)
We take security seriously because OpenCoven handles personal context and agent execution on behalf of users. We will credit researchers who responsibly disclose vulnerabilities (with their permission).
The following properties are design goals of OpenCoven. If you find a way to violate them, that's a security report:
- Session isolation — one user's agent context must not be accessible to another user or agent without explicit permission
- Memory ownership — a user's stored memory and context must remain under their control
- Agent identity integrity — a familiar's identity must not be forgeable by another agent or external caller
- Execution boundaries — agent tool calls must not escape their intended scope
The standalone iOS memory client reaches Cave's bearer-protected
/api/mobile/coven-memory GET routes and POST /api/mobile-token/refresh over
the existing Tailscale Serve flow. Tailscale membership alone is not
authorization. Cave validates the mobile marker before configuration or daemon
access, keeps responses private and uncacheable, strips daemon paths, and
exposes no memory mutation route.
Pairing URLs and the persisted mobile access secret are credentials. Never put
them in logs, screenshots, fixtures, issues, PR text, or support transcripts.
The invite remains usable until its shared credential is rotated. The current
credential is shared across paired mobile clients; a lost device requires
global secret rotation and re-pairing, as documented in
docs/mobile-memory.md. Screen capture by a device
owner remains outside the app's control, so review and beta evidence must use
synthetic status-only data.
Last updated: 2026-07-04