Bringing macOS security to the terminal.

Apple has added several layers of protection around Mac apps. Code signing gives software a stable identity and lets macOS detect changes. Notarization checks distributed software before users run it. App Sandbox limits access to files, devices, and network capabilities. Privacy controls make people approve access to protected data such as contacts, calendars, the camera, and files owned by other apps.

Command-line executables can be signed, hardened, and notarized too. Those protections establish where a binary came from and whether anyone changed it. A typical tool installed into /opt/homebrew/bin still lacks an independent sandbox and its own row of carefully chosen privacy permissions.

A shell launches child processes. Those processes run as your Unix user and receive the environment, open file descriptors, working directory, and other context passed down by their parent. Apple also requires a command-line helper inside a sandboxed app to inherit the containing app’s sandbox configuration.

In everyday terminal use, macOS presents many privacy decisions at the host-app boundary. You grant access to Terminal, iTerm, an editor, or another application. Every command launched inside that room can then make use of the room’s authority unless another control intervenes.

For years this arrangement was easy to reason about. You opened Terminal and typed a command. The terminal application was the obvious host, and you were the person driving it.

Developers now run commands from AI desktop apps, code editors, background automation, and agent harnesses. A harness can start gh, aws, kubectl, or a package installer without a visible shell window. The child process still arrives with authority derived from the app and user session that launched it.

This changes the trust question. “Do I trust gh?” is incomplete. You also need to ask whether you trust this launcher to make this gh request, from this directory, with this credential.

Giving an agent harness broad file or privacy access may be necessary for useful work. That grant should not silently become permanent authority for every CLI the harness can invoke.

Automic Vault resolves both the credential-bearing CLI and the signed launcher above it. You can allow direct access when Terminal launches a named tool, while requiring approval when Codex, another harness, or an unknown app launches the same executable.

The credential stays out of plaintext dotfiles and out of the launcher’s ambient environment. At request time, Automic Vault can show the launcher, executable, command, working directory, and key before you approve or deny the handoff. The audit log retains the same context afterward.

Automic Vault focuses on secret handoff and sensitive tool execution. General filesystem and network containment remain the responsibility of macOS and the host app. The result brings stable identity, least authority, explicit consent, and an audit trail to the terminal layer where developer credentials actually get used.