Automic Vault gates every CLI operation before it hands over a credential, and the gate is the product

Unknown operations stop at every access level, including write

Access Levels are the dial, and the dial has a floor no setting removes. Read Only authorizes recognized reads. Write Access adds recognized writes, but disclosure and use of privileged credentials still require Approval, and unknown operations require Approval at every level. The worked example is one GitHub token producing three separate decisions: gh issue list is authorized automatically, gh issue create needs approval, and gh auth token is classified as Secret Disclosure and needs approval again. That last line is the point of the design. Using a read token and printing the token itself are different operations, and a tool that can disclose its own credential is treated as a separate risk from one that merely uses it. The recommended posture follows: agents get read only, your terminal gets write, and the default is approval required.

The gate inspects the operation, not just the command name

Before anything is allowed, the check covers the Verified Launcher, the Tool, the Target, the command, its arguments, the working directory, Secret Names, and selected Value sources. That is eight inputs feeding one decision, and it is the difference between blocking a class of command and understanding a specific request. Because working directory and Target participate, the same binary invoked against two different places is two different decisions. The trust boundary is stated as a handoff: Automic Vault controls the handoff, and the Target controls the Secret after receiving it. Once a credential has been handed over, the gate is out of the loop, so a Target that leaks the value afterwards is not something this design can observe. The project's own advice follows from that limit, suggesting that supply-chain sensitive work such as npm i belong in a separate terminal carrying no Automic authorizations and no macOS TCC permissions.

Detectors read without changing anything, and hardening comes in three shapes

Detection is deliberately inert. Over 100 developer-tool configurations are checked continuously for Exposures and Hazards, including plaintext credentials, permissive Keychain items, and ambient credential helpers, and each Finding carries a mitigation with it. Detectors inspect without changing your environment and without requesting Secrets, which means a scan cannot make things worse and a clean scan is not a clean bill of health, since it only says no supported Detector found an issue. Hardening is the part that acts, moving supported credentials into Secret Custody in the Data Protection Keychain and configuring the Tool's Authorization Gate. Depending on the tool that takes one of three shapes: a credential helper, a wrapper, or an Isotope, which is an Automic Vault-compatible build of the tool itself. The three-command loop is:

av scan   # or open the app
av harden gh
av doctor gh

av doctor is the part people skip. It verifies the protection that was actually installed rather than assuming the hardening landed.

A history record is verified before the secret is released, and kept for 30 days

The order of operations is the mechanism. Automic Vault persists and verifies the record of an allowed Secret Use before releasing the Secret, and a failure to record denies the release rather than degrading into an unlogged allow. The audit log is therefore a precondition for the decision, not a side effect of it. Reading that log is separately gated: each read requires Approval unless you have granted that exact Verified Launcher Authorization History Access in Settings, which is a different setting from the Secret Name Access that av list uses, and an unverifiable Launcher cannot use the grant at all. The read itself appears in the history it returns. Two command forms exist:

av history
av history --since 7d --json

Storage is local, as encrypted rows in one SQLite file whose key sits in the Data Protection Keychain, and retention stops at 30 days or 25 MiB of encrypted record payloads, whichever arrives first. Because one limit is a byte count, a heavy day can truncate the window earlier than 30 days implies, so --since is a query over what survived rather than a promise about what happened. Terminal tables page, and --no-pager, --json, and plain redirection get you out of them.

A ten minute write grant is scoped to a launcher, a gate, and a task

Temporary Access Grants let an eligible Codex task or a Claude Code session request write access for ten minutes. The grant lives in memory and covers exactly three things: one Verified Launcher, one Tool-specific gate, and one agent task. A visible strip lets you add ten more minutes, suspend access and its countdown, or end the grant. The task identifier is described honestly as a forgeable narrowing label, which means the Verified Launcher is where the real identity boundary sits, and the project says so rather than leaning on the task id. Grants also exclude a fixed set of operations regardless of what was granted: direct Secret access, Secret mutations, use of privileged credentials, disclosure, and unknown operations. So the grant widens the ordinary case, which is writes, while leaving the cases that can lose a credential permanently gated. The stated purpose is to keep agents at read only and escalate on a task by task basis.

Touch ID and iPhone approval both remove the click-to-allow path

Two biometric routes exist and both narrow the surface rather than adding a channel. Touch ID Approval requires a fresh biometric result for each specific request, with no password fallback, no Apple Watch fallback, and nothing pointer-driven. It needs an active Mac session and awake displays, and it coexists with iPhone Approval. iPhone Approval lets you approve across enrolled Macs from eligible iPhones on the same iCloud Keychain account, where each Mac keeps its Secrets, policy, enforcement, and history local, and the iPhone never receives Secret Values. The trade is stated rather than buried: enabling iPhone Approval removes pointer- and keyboard-driven allow actions from that Mac. A machine that previously relied on clicking Allow stops being able to. There is a warning attached as well, that iPhone Mirroring and Show on Mac can put approval controls back onto a Mac when phone biometrics are off, which is a bypass of the very mechanism you enabled.

Test-only environment overrides are compiled out of release builds

The release profile in Cargo.toml is tuned for size and for a small surface: opt-level set to z, fat LTO, a single codegen unit, symbols stripped, and panic set to abort so no unwinding machinery ships. One exception carries a stated reason, since Rust 1.96 on macOS needs proc-macro metadata retained in build dependencies. A separate test-release profile inherits release and switches debug assertions back on, and the comment above it is the useful part: test fixtures exercise optimized code, while shipped release binaries keep debug assertions disabled and therefore continue to ignore AUTOMIC_VAULT_TEST_* overrides. That is a deliberate design, an escape hatch for tests that cannot be reached from a shipped binary. It is also enforced by the build profile rather than by a CI check, which means a change to those profiles would quietly change the guarantee, and nothing in the repository description flags that as something to re-verify at release time.

One dependency set ships a MITM proxy, two TLS stacks, and a brew stub

The dependency list says what the tool is. http-mitm-proxy is pinned to an exact version with default features off, next to hudsucker pinned the same way, which is the interception layer a Secret Proxy needs. TLS arrives twice: hyper-rustls on the aws-lc-rs backend for the server and proxy side, and ring alongside reqwest and ureq for outbound calls. Cryptographic material handling is present too, with ssh-key built for ed25519, p256, p384, p521, and encryption, a pgp implementation, and zeroize in the list for wiping secret values. Then the three binaries: av is the CLI, av-gpg is a separate GPG entry point, and av-brew-stub stands in for brew, which is how hardening Homebrew itself has something to intercept. Taken together this is a credential broker with a proxy and a key toolchain attached, not a wrapper script, and the size-optimized profile is a deliberate response to shipping that much code onto every developer's machine.

Editorial conclusion

Adopt it if you run coding agents on a Mac and want their credential reach to be a policy decision rather than an accident of which config files exist. Two habits matter more than the install. First, leave the default at approval required and widen only where a task genuinely needs it, because unknown operations stop at every access level anyway. Second, run supply-chain commands such as npm i in a separate terminal with no Automic authorizations at all, since a gate that has not been granted anything cannot leak anything.

Frequently asked questions

Official sources

1. automic-vault/automic-vault on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases