Security and reporting

Report vulnerabilities privately. Verify what you run.

OpenCoven handles local agent execution and personal context, so security reports should go through private channels—not public issues. Open a repository Security Advisory, or join the OpenCoven Discord and privately DM @BunsDev. Do not post vulnerability details in a public Discord channel.

What belongs in a security report.

The current repository policy welcomes reports affecting core routing, memory and session boundaries, authentication and identity handling, execution boundaries, or cross-user and cross-context isolation.

Session isolation

One user or agent must not gain another context without explicit permission.

Identity integrity

A familiar identity must not be forgeable merely by another agent or external caller possessing context.

Execution boundaries

Tool and runtime actions must remain within their intended scope and explicit authority boundary.

Use first-party release evidence.

OpenCoven does not claim certifications or independent audits that have not been obtained. Verification should start from repository releases, checksums, signatures, and attestations where the producing repository publishes them.

Coven Cave releases

Inspect the release page and GitHub provenance or attestation evidence associated with the exact artifact you install.

Open latest Cave release

Repository security policies

Implementation-specific scope and reporting details remain canonical in each repository's SECURITY.md rather than this public explanation surface.

Browse OpenCoven repositories

Security language stays bounded.

Local-first architecture and guarded actions are useful properties, not blanket guarantees.

  1. No public claim of SOC 2, ISO 27001, third-party audit, formal certification, or complete conformance is made here.
  2. Third-party dependency and model-provider vulnerabilities should be reported to the relevant upstream provider unless they expose an OpenCoven integration flaw.
  3. Protocol-level identity and authority guarantees remain maturity-scoped; implemented runtime proof must not be generalized into future cross-device or cloud guarantees.