hiveD is a control plane for running AI agents with an explicit identity, policy, and audit model — see docs/PROJECT.md §1–§3. This document covers how to report a vulnerability and the security model the project is being built around. hiveD is pre-alpha (M0): most of the security-relevant machinery described below (real token issuance, policy enforcement, executor egress control) is not implemented yet — see docs/adr/ for what is drafted vs. built, and treat this document as a statement of intent as much as current behavior.

Please do not open a public GitHub issue for security vulnerabilities.

Report suspected vulnerabilities privately to the maintainers via GitHub's private security advisory ("Report a vulnerability"). If you cannot use that channel, email the maintainers at security@hived-project.dev.

Please include, where you can:

• A description of the issue and the impact you believe it has
• The affected component(s) — e.g. hived-keeper, hived-drone, hived CLI
• Steps to reproduce, or a proof of concept
• The version / commit you tested against and relevant configuration

We aim to acknowledge a report within a few business days and will keep you updated as we investigate. Please give us a reasonable window to release a fix before any public disclosure. We are happy to credit reporters in the advisory unless you prefer to remain anonymous.

hiveD is experimental and pre-1.0. Security fixes land on main only.

hiveD's design (ADR-0002) is built around PASETO v4.public tokens, issued solely by the Keeper, scoped to a hive/colony/agent/agentVersion/ run/session/parentRun claim set. In M0 this is drafted but not issued — internal/identity ships as a no-op stub; every request is accepted with a fixed dev principal. Do not expose an M0 Keeper on an untrusted network.

The Keeper (control plane) never executes agent logic; the Drone (per-Cell runtime) never makes policy decisions — this invariant is structural, enforced by which binary the code lives in, not by a runtime check. See ADR-0001. The Drone does not exist yet in M0.

Cell isolation and egress control are the responsibility of the pluggable Executor (vibeD, local-docker, ...), never the Drone — see ADR-0003 for the vibeD executor contract (drafted, not yet implemented). No Executor ships in M0.

hiveD delegates durable memory to mindD. ADR-0004 records a known gap: mindD's capability tokens today scope by a flat tenant string plus admin-predeclared namespace globs, not by hiveD's run-level path scheme — until that is resolved, a compromised Run token can reach sibling Runs' memory within the same colony. No mindD integration ships in M0.

This module's scripts/check-import-boundary.sh (run in CI) asserts it never imports github.com/vibed-project/* directly — which now covers mindD (github.com/vibed-project/mindD) — so its security posture does not implicitly depend on a sibling repository's internals.

• hiveD does not sandbox anything itself; sandboxing is the Executor's job. Treat hiveD's own configuration, secrets, and database credentials as trusted inputs.
• Reports about missing hardening in explicitly-stubbed M0 paths (no-op identity, unauthenticated dev Keeper) are useful for tracking, but note these are intended to be replaced before any production exposure.

Thank you for helping keep hiveD and its users safe.