Security model
Covenant is a local-first daemon. It assumes the operator owns the machine and trusts their own user account; it does not defend against an attacker who already has the operator's shell. Within that assumption it offers strong guarantees about what agents and tools can do — capability tokens with ed25519 signatures, append-only audit, hard enforcement at dispatch.
Trust boundaries
| Boundary | Defended | Mechanism |
|---|---|---|
| Operator → daemon | Yes (within the OS user model) | File permissions on $COVENANT_HOME, identity key at 0600, Unix-socket access controlled by the filesystem. |
| Daemon → agent | Yes | Capability checks at dispatch, wall-clock budget, JSON-line stdin/stdout protocol with no out-of-band channel. |
| Agent → daemon | Partial | Agents only see what the daemon hands them on stdin. They cannot mutate state directly; everything goes through the daemon. |
| External MCP server | No | Servers run with the operator's privileges. The daemon gates invocation via tool.call.<name>; it cannot govern what a malicious server does once invoked. |
| Network → daemon | Yes (via loopback) | The HTTP gateway binds 127.0.0.1 only. Anything beyond that requires explicit operator configuration. |
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 verifyreports the mismatch. - A registered agent fabricating a result for a different agent's intent. Each
AgentResultis 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.
- Network-level mitm to the on-chain RPC. Use a trusted RPC provider and verify TLS; the daemon does not pin certificates.
Defaults that matter
- Identity key written at mode
0600; refusal to start if the key file is world-readable. - HTTP gateway bound to
127.0.0.1. Override deliberately if you need remote access — and gate the surface behind your own auth proxy when you do. - Default agent network policy is
outbound-https-only; opt intofullonly when the agent needs it. - The default
.covenantignoreseeds rules for common credential filenames so that intents whose text mentions e.g.id_rsaare short-circuited and never written to memory.
Operator responsibilities
- Treat
$COVENANT_HOMEas you would treat your shell's dotfiles. Back it up; restrict access; do not check it into version control. - Vet every external MCP server before configuring it. Prefer the most narrowly-scoped server for the job.
- Audit capability grants. If an agent suddenly needs a new action, that should be a deliberate decision, not a drive-by grant.
- Read the audit log periodically. The cross-references
covenant verifychecks are a smoke test, not a substitute for occasionally tailingevents.jsonlby hand. - Rotate the identity key on a schedule that matches your security posture. Re-issuing the keypair invalidates every signed capability written under the old key — plan for the re-grant.
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
- Identity and keys — the ed25519 keypair behind every capability.
- Capability tokens — how dispatch is gated.
- Audit log — the system's ground truth and how to read it.