Coven Documentation

Security posture for the Coven daemon: same-user local IPC trust, daemon-owned enforcement, no stored provider credentials, remote access guidance, and explicit destructive confirmations.

Coven's daemon security model is local-first and deliberately narrow.

The Rust daemon is the authority.
The platform local IPC endpoint is same-user trust.
Coven does not store provider credentials.
Destructive operations require explicit confirmation.

For the broader product safety framing, see Safety Model and Authentication and local access.

Daemon authority

Clients can ask. The daemon decides.

The daemon validates:

Project roots.
Working directories inside project roots.
Harness adapter ids.
Session ids.
Session liveness before input or kill.
Control-plane action ids.
API route version compatibility.

Client-side validation is useful for better forms and friendlier errors, but it is not the trust boundary.

Same-user local IPC trust

The daemon does not use OAuth, JWTs, bearer tokens, API keys, or browser cookies. Access uses:

$COVEN_HOME/coven.sock on Unix-like hosts; or
an owner-only named pipe reported by health and coven daemon status on Windows.

Anyone who can connect to that endpoint can act as a local Coven client. Keep $COVEN_HOME and the endpoint private to the user who owns the daemon.

Provider credentials

Coven does not own model-provider credentials. Harness CLIs keep using their own login and auth stores.

That boundary matters:

codex auth stays with Codex.
Claude Code auth stays with Claude Code.
Gemini CLI auth stays with Gemini CLI.
Local model configuration stays with the harness or provider runtime.

Coven records session metadata and output for replay and audit, so $COVEN_HOME is still sensitive even though provider credentials are not copied into the daemon.

Remote access

Coven does not bind TCP by default. If you need a remote daemon, put an explicit authenticated transport in front of the platform local IPC endpoint and treat that transport as the auth layer.

Reasonable owner-operated patterns:

SSH local forwarding to a machine you control.
Tailscale between your own devices.
A private gateway that adds authentication before touching the socket.

Avoid exposing the daemon's local IPC endpoint directly to browsers, public networks, shared machines, or unauthenticated TCP bridges.

Experimental agent filesystem boundary

The experimental Agent filesystem crate has an opt-in NFSv3 export for engineering validation. It is not a Coven daemon route or a supported CLI workflow. Its example binds 127.0.0.1 only and uses an ephemeral port by default, but loopback NFS has no authentication: any local process that can reach the port can make unauthenticated requests to the export. Operating-system policy can still restrict a particular client's mounted-volume operations.

Do not treat the NFS spike as a sandbox or an access-control boundary. A mounted view does not stop a process from writing outside that view. A human-operated macOS Terminal pass confirmed loopback read/write behavior for one consented client, but the macOS privacy policy remains process-specific and other client processes may still be denied without explicit consent. Loopback exposure, access control, platform sandboxing, and recovery must be validated before a mount becomes a supported default.

Destructive confirmations

Destructive operations must remain explicit even when wrapped by another client:

Operation	Confirmation posture
`coven sacrifice <id> --yes`	Permanent delete requires `--yes`.
Process/cache relief commands	Require explicit confirmation flags.
OpenClaw patch flows	May generate patches, but v0 should not silently commit or push.

Every local client must surface the same confirmations instead of hiding them behind a prettier button.

Security posture