Security foundations
Automic Vault's security model starts with the operation, then works outward to identity, policy, human authority, delivery, and evidence. Reading the model in that order avoids the most common mistake: treating possession of a Secret Name or a signed process identity as permission by itself.
The request envelope
An Authorization Request is the complete immutable operation presented to policy. Depending on the Gate, it contains:
- the Verified Launcher and the observed execution chain;
- the Gate Client and selected Authorization Gate;
- the resolved Target executable, command, arguments, and physical working directory;
- the exact Secret Names and selected Value sources;
- Target runtime posture, including Hardened Runtime where required;
- environment conflicts and Gate-specific facts such as registry, host, or GPG payload digest.
A decision binds to that envelope. Changing an argument, Target, directory, Value source, launcher generation, or relevant runtime fact creates a different request. A label such as “ChatGPT,” “gh,” or “read only” is useful UI shorthand, but is not the complete security decision.
Before approving, read the request from top to bottom. Confirm the command is the operation you intended, the Secret Names are the minimum required, the working directory is expected, the full Target path is native and immutable enough for the policy, and the Verified Launcher is the app or bundle you meant to authorize. Warnings are part of the request, not decoration.
Custody, Application, and Disclosure
Secret Custody stores a Value under macOS-backed protection. Secret Application places that Value into an authorized operation without displaying it. Secret Disclosure reveals the raw Value and is a stronger authority. These are different capabilities.
A Target controls a Value after receiving it. It may log, cache, transform, transmit, or disclose that Value. Automic Vault narrows who may receive a Value and for which operation; it cannot retract a Value already delivered or promise that an authorized Target behaves well.
An Execution Gate controls an operation without
requiring a Secret; Homebrew is the current example. A Secret
Gate controls Secret Application or Disclosure. GPG Signing is
a Tool-specific Secret Gate: the signed av gpg-sign Target
receives the private key, while Git and av-gpg receive only
the detached signature.
Identity and provenance
A Verified Launcher is a live, revalidated code identity used as an input to policy. Code signing, a Launcher Bundle, a blessed script digest, and Hardened Runtime can strengthen identity and integrity. None proves benign intent.
Launcher provenance is checked again at use time. A mutable wrapper, unexpected interpreter, replaced binary, incompatible entitlement, lost execution ancestry, or changed script can invalidate the route. A native Target or exact reviewed snapshot gives policy a stable object to revalidate. A shell leaves every child behind a broad interpreter boundary.
When adding a Verified Launcher, Automic Vault may discover signed helpers sealed inside its app. Approving an association lets that exact helper represent the app wherever current or future Gate policy names the app. Discovery, a shared Team ID, or bundle containment alone grants no association. Review the cross-gate warning before enabling a helper; disable it to remove that association without changing the app's rules.
The built-in Claude Code association allows its exact signed helper to represent verified Claude.app outside the parent bundle by default, including separately installed copies with that identity. Its Tool-specific gate rules also accept Claude Code's disabled library validation, including existing strict Claude.app rules. Third-party code loaded into that helper can exercise those permissions. Review the warning and opt-out in Verified Launcher Helpers. Direct Access Rules, Temporary Access Grants, other helpers, and Claude.app itself retain their recorded runtime requirements. See the canonical helper rules.
Authority and decision sources
An operation can be allowed by Human, Policy, or a narrowly scoped Temporary Access Grant. Authorization History records the source so an operator can distinguish “a person allowed this exact request” from “an existing rule matched this request.”
Approval may be carried on the Mac or an eligible iPhone. The Mac remains the Local Execution Boundary in both cases: it builds and revalidates the request, applies the decision, and performs the operation. Moving the human gesture to an iPhone does not move execution or Custody to the phone.
Secure defaults
Defaults trade convenience for narrow authority:
- new Secret Gates begin at Read Only;
- GPG Signing and the optional SSH Agent Gate begin at Approval Required;
- Homebrew begins at Read & Update, which excludes installs and upgrades;
- Direct Secret Access begins at Approval Required;
- Detached Processes is off;
- proxy sessions always require Approval and keep rules only in memory;
- Project Value selection never falls back after a selected Value fails to read;
- availability while locked is separate from authorization;
- unknown, elevated, Disclosure, Direct, and mutation operations are excluded from Temporary Access Grants.
Fail-closed behavior can surface as a denial after an update, move, permission change, or runtime change. Diagnose the mismatch; do not weaken the rule merely to restore yesterday's behavior.
What Automic Vault does not do
Automic Vault is not a sandbox, malware detector, whole-process containment system, network firewall, defense against a compromised kernel or root account, or proof that signed code has good intent. Proxying does not force a Target to use the proxy. History is not a remote, append-only audit ledger. Project Directory is not project identity. Agent Task Context is not identity.
Those boundaries are security properties, not disclaimers to work around. They tell you where another control is needed: sandbox the Target, restrict network egress, protect the administrator account, ship logs remotely, or use a dedicated short-lived credential system when the threat model requires it.