Security model

Security is the core of the product, not a feature. The rules on this page are non-negotiable: a violation is treated as a high-severity bug. The design goal is that the agent — the least-trusted component — can do useful work without ever holding a secret, leaving its worktree, or reaching the network directly.

Credential isolation via the broker

Credentials never reach the agent. Only the broker knows the real secret:

• The MCP config the agent sees always points to http://127.0.0.1:<port>/mcp/<id> plus a session bearer — never the real endpoint, never the secret.
• The broker validates the bearer, requests a short-lived scoped token from the enterprise panel, injects the real credential, and forwards the call to the remote endpoint.
• The panel’s mint_token is the only secret-bearing endpoint: it is authenticated per call, rate-limited and audited, and the minted token is short-lived. It returns the real upstream secret only to the broker. Anonymous minting is rejected.
• Credentials are never injected into the agent’s environment or config, and catalog entries with an empty secret get no Authorization header injected upstream — an empty bearer is never sent to a third party.

Loopback-only broker, per-session bearer

The broker listens on loopback only. Its session bearer is validated on every call, so no other local process can use the proxy. The egress allowlist permits the real MCP endpoints to the daemon/broker only — the agent cannot reach them even if it learns the URL. Short-lived tokens are cached in memory only.

Secrets in the OS keychain

Secrets live in the OS keychain (macOS Keychain / Windows Credential Manager) — never on disk in cleartext, never in the worktree, never in persisted variables. On the panel side, the catalog signing key lives in a KMS/secret manager: never in the repo, never in the database in cleartext, never shipped to a client.

Never log secrets. Tokens, API keys and repo credentials are redacted before anything is written to logs or the database. The audit log records which MCP was used, not the token.

Signed catalog verification

The panel is the single source of truth for the catalog of authorized MCPs, context and capabilities. The daemon downloads the signed catalog filtered by teams, verifies the signature before trusting it, and resolves the global→team cascade.

• The trusted path uses asymmetric Ed25519 signatures: the panel signs with a private key it never ships; the daemon verifies with a pinned public key only. Anything that can verify cannot forge.
• An unsigned catalog, an invalid signature, or an unknown key id is rejected, not silently degraded.
• The payload carries a key_id and the daemon holds a small trusted-key set, so key rotation does not break live sessions.
• The cascade is resolved panel-side and re-checked daemon-side over the signed payload — defense in depth.
• MCPs outside the signed catalog are not allowed, and users cannot add MCPs locally: in Claude Code the managed settings file fixes the allowlist and blocks user-added servers.

The same discipline applies to governed context: a tampered context bundle means the session still creates but nothing materializes, and the failure is audited and surfaced — rejected, never degraded.

Per-session sandbox

Every session runs in a sandbox (seatbelt on macOS, job objects on Windows):

• Filesystem is scoped to the session’s worktree.
• Network follows an egress allowlist; the daemon/broker is the only thing that reaches the real MCP endpoints.
• The session terminal runs inside the same sandbox and audits every command — it is the largest attack surface, so it depends on the sandbox being in place.

Approval gates

Destructive operations — force push, mass deletion, network installs, running arbitrary scripts — require explicit approval. The final merge is always approved by a person or a certifying agent, and only proceeds by policy: checks green, required approvals present, and the actor holding pr.merge. Chronos is the source of truth for roles but assumes the host’s branch protection (GitHub/GitLab) as a backstop; in-app enforcement is never relied on alone.

Append-only audit

Every prompt, tool call, command, change, MCP use and approval is recorded immutably. End-to-end traceability is a product requirement, not an extra:

• The daemon audit covers sessions and commands; the cloud audit covers every authorize/mint/cascade change with its actor. They complement, not replace, each other.
• Governed prompt bodies never appear in the audit trail — metadata only.
• Signature, sandbox and audit errors are never silenced.

Memory boundaries

Session memory stays local and enters the audit log. Cross-session memory writes are explicit and reviewable — never silent auto-memory — and memory respects team boundaries: it is never shared across teams.

All panel traffic runs over TLS, and the offline/CI path never needs the network — the mock panel remains a first-class fallback, with its shared-secret HMAC verifier confined to mock/tests only.