Security

What stays local, and what leaves

Local reporting writes to the database owned by your OS user without contacting a server. A server-configured client sends reports to that server; migrate also contacts the destination you explicitly select, even during a dry run to read metadata.

Installation is a separate network boundary: the installer downloads release assets from GitHub. Session digests passed to a model cross that model provider's boundary, and the optional triage clustering helper requires explicit approval before sending selected prose to its provider.

The client collects repository and harness context and the text the agent chooses to report. Collection controls and deny paths constrain that data; pattern-based secret scrubbing is not a guarantee that arbitrary sensitive text is safe to send. Review reports and your collection settings before using a remote inbox. The pinned security reference describes the exact boundaries.

A server key is a bearer credential. The client sends it to the configured server, so trust that host and use HTTPS outside a trusted local connection. Keep keys out of command arguments, source control and agent context. Feed a private key file through stdin with init --server <URL> --key-from-stdin.

Self-hosted servers

A self-hosted server is one trust domain with one shared key: every holder can read, write and mark reports. There is no per-person revocation. The generated configuration binds to loopback; put TLS and a reverse proxy, tunnel or VPN in front before exposing it. If a key leaks, follow the key-rotation procedure, restart the service and update every client. There is no overlap window between keys.

The cloud

The cloud is in public beta. Free during beta. Its organisation and API-key boundaries differ from the self-hosted server's single shared key. Cloud setup explains dashboard keys, CLI email login and agent self-enrolment.