Security model

enveigh's job is to let tools use secrets without seeing them, and to make every access visible. Here's exactly how, and where the honest edges are.

At rest

• Values live in the macOS Keychain, keyed by an immutable (secret id, version), so rotating a key writes a new entry and never mutates an old one.
• Metadata (names, tags, version history — never values) is stored in app-data, encrypted at rest with AES-GCM under a key held in the Keychain, and migrated forward from any older plaintext store on launch.
• Vault files are owner-only (0600 files, 0700 directory).
• Encrypted backup: export a backup unlockable by either a passphrase or a generated recovery key, so a lost machine doesn't mean lost secrets.

The lock

Secrets only flow while the app is running and unlocked (Touch ID / password). Lock it or quit it and the broker stops, the endpoint is cleared, and any revealed plaintext is dropped from memory. There's no background daemon holding keys open.

The broker (how tools reach values)

The unlocked app exposes a local UNIX-domain socket (0600, owner-only) plus a token. Every request is gated:

• Token + scope. The CLI uses the full session token; each MCP client gets its own scoped, revocable token. Tokens are compared in constant time.
• Real caller identity. The broker reads the connecting process's PID from the kernel and walks its parent chain (enveigh ← node ← Claude). The requestor shown in the prompt and the audit log is server-derived — a caller can't spoof who it is.
• Approval policy (your choice in Settings):
  • Touch ID per request — strongest.
  • Touch ID once per environment — default; approve once per session.
  • Unlocked = allowed — convenience; no prompt while unlocked (see the honest edge below).
• Audited before disclosure. Reveal/render/capture/agent access is written to the audit log before the value is released — if the audit write fails, the value isn't returned.

Against a misbehaving agent

• The default agent tool, run_with_env, redacts every injected value from the output the model reads, and caps output size.
• Raw-value tools (render_env, get_secret) are not even exposed unless you opted that client into reveal — and then they're still Touch-ID gated and audited.
• capture_secret is write-only — an agent can store a key but can never read one back.
• Inherited credential-shaped env vars are scrubbed from agent-run child processes, so a secret exported in the shell that launched the helper can't leak to the agent.

Catching keys before they spread

Two layers, by timing:

1. Clipboard watcher (opt-in, Settings → Security). When you copy something credential-shaped, enveigh offers to vault it before you paste it anywhere. Detection is local; non-matching clipboard content is ignored and never stored or sent. It skips enveigh's own copies and ordinary dev noise (git SHAs, UUIDs, URLs).
2. capture_secret + skill — if a key does reach an agent, the agent offers to vault it (you confirm) and stops using the pasted copy.

Honest edges

We'd rather you know these than discover them:

• run_with_env redaction is exact-match. A deliberately hostile agent could base64- or otherwise transform a value before printing it, dodging redaction. The default protects against casual exposure, not an actively malicious agent running arbitrary commands with the env injected.
• The CLI is your tool — full access, live output. If an agent has shell access and the enveigh CLI on PATH, it's a more powerful path than the scoped MCP. The approval policy is the gate; the Unlocked = allowed mode removes it (which is why it isn't the default).
• Tokens at rest are same-user readable (the broker is a same-user trust boundary). The Touch-ID approval policy — not file secrecy — is the real control. Keep the default policy and you get a prompt naming the real caller every time.

Not the Mac App Store — on purpose

The App Store sandbox would break the Keychain + broker model enveigh depends on, so it ships as a Developer ID–signed, notarized direct download with a built-in auto-updater.