Security model

Covenant is a local-first daemon. The model assumes the operator owns the host and trusts their own user account; it does not defend against an adversary that has already obtained shell access as the operator. Within that boundary, Covenant provides hard guarantees over Covenant-mediated actions: ed25519-signed capability tokens, an append-only audit log, and enforcement at dispatch. Trusted-local subprocess execution is not process isolation. The runtime crate has an initial Linux gVisor runner, daemon-selectable backend configuration, and opt-in live Linux coverage; repeatable CI provisioning and broader policy enforcement are still required before production sandbox claims.

Trust boundaries

BoundaryDefendedMechanism
Operator → daemonYes (within the OS user model)File permissions on $COVENANT_HOME, identity key at 0600, Unix-socket access controlled by the filesystem.
Daemon → trusted-local agentPartialCapability checks at dispatch, wall-clock budget, JSON-line stdin/stdout protocol, and daemon-owned attribution. This is not a sandbox against hostile code.
Agent → daemonPartialAgents only see what the daemon hands them on stdin. They cannot mutate state directly; everything goes through the daemon.
External MCP serverNoServers execute with the operator's privileges. The daemon gates invocation via tool.call.<name> but cannot constrain the behavior of a malicious server post-invocation.
Network → daemonYes (via loopback)The HTTP gateway binds 127.0.0.1 only. Anything beyond that requires explicit operator configuration.
Sandbox-required agent → hostPlannedManifests can require linux-gvisor, and the trusted-local runner fails closed instead of downgrading. The initial runner supports only read-only packages with network disabled until broader policies have real enforcement.

Threat model

What Covenant defends against

  • A registered agent attempting an action it does not have capabilities for. Hard rejection at dispatch; audit row recorded.
  • A registered agent exceeding its CPU budget. The runtime kills the process; the dispatch returns an error.
  • A registered agent injecting forged audit entries. Impossible — agents do not write to the audit log directly.
  • Out-of-band edits to capability files producing tokens without a matching grant audit event. covenant verify reports the mismatch.
  • A registered agent fabricating a result for a different agent's intent. Each AgentResult is captured by the runtime with a known matched agent; attribution is set by the daemon, not the agent.

What Covenant does not defend against

  • An attacker with the operator's shell. They can read the identity key, sign capabilities, edit files, restart the daemon. Outside the scope of the daemon.
  • A malicious external MCP server granted tool.call.<name>. The capability gates who can invoke the tool; the tool itself runs as the operator and can do anything the operator can do.
  • Side-channel resource consumption. Memory budgets are advisory until a sandboxed runtime (gVisor, Firecracker) enforces them.
  • Host filesystem, environment, or network access by a malicious trusted-local subprocess. The current subprocess runner is for first-party or otherwise trusted local automation only.
  • Network-level mitm to the on-chain RPC. Use a trusted RPC provider and verify TLS; the daemon does not pin certificates.

Defaults

  • Identity key written at mode 0600; the daemon refuses to start if the key file is world-readable.
  • HTTP gateway bound to 127.0.0.1. Remote access requires deliberate configuration and an authentication proxy in front of the gateway.
  • Default agent network policy is outbound-https-only; full network access requires explicit opt-in per agent.
  • Agents declaring sandbox.required fail closed on the trusted-local runner. Covenant must not silently downgrade a sandbox-required agent to subprocess execution.
  • The default .covenantignore seeds rules for common credential filenames; intents whose text references paths such as id_rsa are short-circuited and never persisted to memory.

Operator responsibilities

  • $COVENANT_HOME contains identity material, capability tokens, and the full audit log. Restrict access, back it up, and exclude it from version control.
  • Review external MCP servers prior to configuration. Prefer the server with the narrowest scope appropriate to the task.
  • Treat capability grants as deliberate authorization decisions. Each grant is recorded in the audit log; new grants should be reviewed and justified rather than issued ad hoc.
  • Inspect the audit log on a regular cadence. covenant verify provides drift detection across the cross-references but does not replace direct inspection of events.jsonl.
  • Rotate the identity key on a schedule consistent with the deployment's security requirements. Re-issuing the keypair invalidates every capability signed under the prior key; plan the corresponding re-grant in advance of rotation.

Reporting a vulnerability

Use GitHub's private advisory flow at github.com/open-covenant/covenant/security/advisories/new, or email security@opencovenant.org. Do not open a public issue for anything that could compromise keys, capability tokens, audit-log integrity, or on-chain funds.

Related