# Automic Vault Full Site Text This file concatenates crawlable text from automicvault.com for AI systems and retrieval pipelines. # / Automic Vault | A new kind of secrets manager for a new era of development. Automic Vault Secrets Policy History GitHub Download for macOS From the creator of Homebrew A new kind of secrets manager for a new era of development. Automic Vault moves developer credentials out of plaintext files, then controls their application through each Tool and Verified Launcher. Any agent. Any harness. Zeroconf. Download for macOS See the boundary work → 01 Remove plaintext secrets Credentials leave dotfiles and tool configs. 02 Control the handoff Only the right executable gets the credential. 03 Apply one local boundary Every Verified Launcher meets its Authorization Policy. Your agent inherits your access A prompt cannot protect a secret the agent can already read. C Claude Hmm… the remote server doesn’t have AWS access. C Claude No problem — I’ll upload the keys from here. T Tool call Read(~/.aws/credentials) R Tool result [default] aws_access_key_id = AKIA•••••••••••• aws_secret_access_key = •••••••••••••••••••••••••••••••• YOUR AWS KEYS LEFT THE MAC The agent found a reusable cloud credential and uploaded it to a remote server. Automic Vault keeps your keys on your Mac. C Claude Hmm… the remote server doesn’t have AWS access. C Claude No problem — I’ll upload the keys from here. T Tool call Read(~/.aws/credentials) No plaintext credential exists for the agent to read R Tool result No such file C Claude I’ll run the export command instead. T Tool call aws config export-credentials The export command still requires your approval ! Automic Vault Approval Required The local execution boundary Automic Vault controls the secret handoff. Automic Vault moves credentials out of readable tool configs. Agents and untrusted software cannot find protected secrets in the files they inspect. When a Tool requests a Secret, Automic Vault checks the Target, Verified Launcher, command, working directory, and requested Secret Name. How it works Automic Vault stores the Secret in the macOS Keychain. It applies the Authorization Policy when a Verified Launcher starts the Tool, then supplies the Secret to the designated Target for that run. The Secret is not placed in the Launcher’s ambient environment. The Target controls it after receipt. Command, working directory, and requested Secret Name, visible before anything runs. Access by app Policy follows the tool and its launcher. Terminal, Codex, and an unknown process can invoke the same executable. Automic Vault identifies the Verified Launcher and gives each pairing its own Authorization Policy. Approval Required The Launcher receives no durable policy grant. Every operation requires Approval. Write Access Recognized reads and writes are automically authorized. Secret Disclosure and Elevated Secret Application require Approval. † Read Only Recognized reads are automically authorized. Writes require Approval. † Installed packages must cross the same boundary to use protected secrets. Supply-chain attacks such as the 2025 Shai-Hulud npm worm target credentials available to developer tools. Defense in depth still matters: run npm i in a dedicated terminal with low-to-no privileges in both Automic Vault and macOS TCC. Authorization History stays on your Mac. Allowed or denied, policy or Approval: requests leave bounded local history with the decision, Launcher, Secret Names, command, and working directory. Decision Launcher Secret Names Working directory Denied and allowed requests share the same local history. Each flag includes its trigger, rationale, and mitigation steps. Know when your toolchain turns risky. Automic Vault scans developer Tools across ecosystems. It reports supported Exposures and Hazards and shows how to mitigate each Finding. Independent of the harness Control the tool layer beneath every agent. macOS can code sign apps, sandbox them, and keep them out of one another’s private data. Command-line tools usually run with the authority of whichever app launched them. That used to mean Terminal.app. Now it may mean an AI harness, editor, or automation app. Automic Vault identifies the Tool and its Verified Launcher, then applies the Authorization Policy you chose for that pairing. Read why the terminal needs its own security layer → The same CLI can receive different access from Terminal, an agent harness, or another host app. Free and open source. Automic Vault costs nothing. The optional paid iPhone app moves approval gates off the computer running the commands, so a process on your Mac cannot approve its own request. From the creator of Homebrew. Download for macOS Automic Vault About Security Blog Privacy Terms 𝕏 GitHub © 2026 · Apache-2.0 English 日本語 Deutsch Français 简体中文 # /llms.txt # Automic Vault > Automic Vault removes plaintext credentials from developer Tools and controls their application through each Verified Launcher and Target at the Local Execution Boundary. ## Product - [Homepage](https://www.automicvault.com/): Explains the Local Execution Boundary, Verified Launchers, Authorization Policy, and Authorization History on macOS. - [Download](https://www.automicvault.com/download/): Provides the signed macOS disk image, installation details, included components, and first steps after setup. - [Documentation](https://www.automicvault.com/docs/): Source-checked Automic Vault 2.9.0 CLI manual covering scan, doctor, save, inject, bless, harden, catalogs, and app links. - [Package catalog](https://pkg.so/): Searchable catalog of developer packages, dependencies, install commands, risk information, and Automic Vault hardening coverage. - [Source and releases](https://github.com/automic-vault/automic-vault): Apache-2.0 source code, tagged releases, implementation history, and public issue tracking. ## Security and Architecture - [About](https://www.automicvault.com/about/): Describes the project, founder Max Howell, macOS focus, local execution model, and relationship to Homebrew. - [The best AWS credential manager](https://www.automicvault.com/blog/best-aws-credential-manager/): Explains process-bound AWS credential delivery, temporary STS sessions, signed-launcher policy, MFA and role support, and the fail-closed profile model. - [macOS security for the terminal](https://www.automicvault.com/blog/bringing-macos-security-to-the-terminal/): Explains inherited CLI authority and the identity, Approval, and Authorization History boundary beneath shells and agent harnesses. - [Mac security best practices for agents](https://www.automicvault.com/blog/mac-security-best-practices-for-agents/): Gives a least-authority macOS baseline covering Gatekeeper, SIP, local builds, Downloads, privacy grants, and command-line protection. - [Security reporting](https://www.automicvault.com/.well-known/security.txt): Publishes the current security contact, preferred language, canonical location, and expiration date. ## Incident Analysis - [Blog](https://www.automicvault.com/blog/): Index of developer security guidance and analyses of package, extension, credential, and local execution incidents. - [Keyv npm supply-chain worm](https://www.automicvault.com/blog/prevent-keyv-npm-worm/): Explains how protected local credentials and a low-privilege install terminal would have broken the worm's credential theft and stolen-token propagation path. - [Nx Console extension compromise](https://www.automicvault.com/blog/prevent-nx-console-vscode-compromise/): Analyzes local credential theft by a compromised VS Code extension and the relevant endpoint controls. - [GitHub employee device breach](https://www.automicvault.com/blog/prevent-github-vscode-extension-breach/): Examines a poisoned editor extension, repository access, and controls at the developer workstation boundary. - [LiteLLM PyPI compromise](https://www.automicvault.com/blog/prevent-litellm-pypi-compromise/): Maps malicious Python releases and credential theft to local secret storage and executable approval controls. ## Website Policies - [Privacy](https://www.automicvault.com/privacy/): Explains website analytics, local product data boundaries, Keychain storage, logs, diagnostics, updates, and public reporting guidance. - [Terms](https://www.automicvault.com/terms/): Summarizes website use, Apache-2.0 licensing, release artifacts, package metadata, third-party services, and warranty boundaries. ## Key Facts - Category: local execution security and secrets management - Platform: macOS - Current documented release: 2.9.0 - License: Apache License 2.0 - Pricing: free open-source software - Founder: Max Howell, creator of Homebrew - Secrets remain in Keychain until an authorized Target receives them for one run. - Authorization Policy considers the Target, Verified Launcher, command, working directory, and Secret Names. - Root compromise and a malicious authorized Target remain outside the product security boundary. ## Command Surface - `av scan --show-all` audits credential exposure and unsafe tool configuration. - `av doctor --json` checks launchers, dependencies, ownership, permissions, content, and path precedence. - `av save GH_TOKEN` prompts through `/dev/tty` and stores a named value in Keychain. - `av inject +GH_TOKEN gh auth status` releases a named value to one approved command. - `av detectors --json` and `av hardeners --json` publish the installed security catalogs. ## Contact - Website: https://www.automicvault.com/ - Source: https://github.com/automic-vault/automic-vault - Security reports: https://github.com/automic-vault/automic-vault/issues # /.well-known/security.txt Contact: https://github.com/automic-vault/automic-vault/issues Preferred-Languages: en Canonical: https://www.automicvault.com/.well-known/security.txt Expires: 2027-07-28T00:00:00Z # /404.html Page Not Found | Automic Vault Automic Vault Download Packages Blog GitHub Not found This path is sealed. The page you requested does not exist, moved, or was never part of the public surface. Go home Read docs 404 CloudFront returns this page when S3 reports that a requested object is not available. © 2026 Automic Vault. Privacy Terms X GitHub # /about/ About Automic Vault | Local secrets security for macOS Download Packages Blog About GitHub Founder authority A new kind of secrets manager, from the creator of Homebrew Automic Vault removes plaintext secrets from CLI tools and controls which signed apps can use them at the local execution boundary. Last updated: July 31, 2026 Read the docs › View source › Who builds it Max Howell created Homebrew in 2009. Homebrew became the default way many macOS developers install command-line tools. Automic Vault comes from a new operating reality: those tools now run under terminals, editors, automation apps, and AI agents, while their credentials often remain readable in plaintext files. Credential storage Plaintext secrets are the problem Automic Vault moves CLI Credentials into the macOS Keychain and applies them only to an authorized Target for one run. Runtime authority Execution is the boundary Automic Vault checks the Target, Verified Launcher, command, working directory, and Secret Names before applying a Credential. Open source Source stays inspectable The project is Apache 2.0 software on GitHub, so developers can inspect how local control is implemented. macOS first The platform is explicit Automic Vault targets the macOS developer workstation instead of pretending agent security is only a cloud policy problem. Public references Public references for the product and founder. These links connect Automic Vault, Max Howell, and Homebrew to public developer-tooling history. mxcl.dev Max Howell's public site. Homebrew The macOS package manager project Max Howell created in 2009. Homebrew on Wikipedia Independent entity reference for Homebrew and its creation history. Automic Vault source The public repository for the product. Project position A local execution boundary for developer tools. Automic Vault is a local macOS authority layer for developer Tools. It moves Credentials out of plaintext files, applies them to authorized Targets for one run, and evaluates Authorization Policy for each Verified Launcher. Secrets Remove plaintext credentials Keep credentials out of files and model context. Policy Gate and Launcher rules Choose how each Verified Launcher can use each Tool and Credential. History Review Authorization Decisions Keep bounded local history of allowed and denied requests. © 2026 Automic Vault. Home About Blog Privacy Terms GitHub English 日本語 Deutsch Français 简体中文 # /blog/ Automic Vault Blog | Secure the tools agents need Automic Vault Home Packages Blog Docs Download GitHub Automic Vault Blog Package security for the agent era. Practical notes on local tooling, agent-ready package packs, and the security layer below the prompt. Latest 11 posts AWS credential security The best fricking AWS credential manager in the world Temporary credentials for one verified AWS process, under a policy for the command and the signed app that launched it. Read the post Keyv npm supply-chain worm Preventing the Keyv npm credential theft The Keyv worm stole developer credentials during npm installs and used them to poison more packages. Automic Vault would have broken the local theft path. Read the incident post macOS agent security Best practices for using a Mac with agents Keep Gatekeeper and SIP enabled, protect Downloads, and deny broad privacy permissions to agent harnesses. Read the post macOS terminal security Bringing macOS security to the terminal CLI tools run inside the authority of Terminal, an agent harness, or whichever app launched them. That boundary now matters. Read the post Nx Console VS Code compromise Preventing the Nx Console extension compromise Nx Console 18.95.0 stole local developer credentials from editor sessions. Automic Vault would have stopped the local secret access. Read the incident post GitHub employee device breach Preventing the GitHub employee device breach A poisoned VS Code extension reached a GitHub employee device. Automic Vault would have prevented local credentials from becoming repository access. Read the incident post durabletask PyPI compromise Preventing the durabletask PyPI compromise Malicious durabletask PyPI releases fetched rope.pyz and stole cloud and developer secrets. Automic Vault would have blocked the local theft path. Read the incident post TanStack npm compromise Preventing the TanStack npm credential theft TanStack packages were poisoned through trusted publishing, then stole local secrets. Automic Vault would have prevented the endpoint theft. Read the incident post node-ipc npm backdoor Preventing the node-ipc npm backdoor The node-ipc backdoor ran on module load and exfiltrated secrets over DNS. Automic Vault would have prevented useful credential theft. Read the incident post Bitwarden CLI npm compromise Preventing the Bitwarden CLI npm compromise The compromised Bitwarden CLI npm package used install-time code to steal developer secrets. Automic Vault would have stopped the local theft. Read the incident post LiteLLM PyPI compromise Preventing the LiteLLM PyPI compromise LiteLLM 1.82.7 and 1.82.8 stole local credentials. Automic Vault would have prevented the workstation credential theft phase. Read the incident post © 2026 Automic Vault. About Security Blog Privacy Terms GitHub # /blog/best-aws-credential-manager/ The Best AWS Credential Manager in the World | Automic Vault Blog Automic Vault Home Packages Blog Docs Download GitHub AWS credential security The best fricking AWS credential manager in the world. Automic Vault stores long-lived keys in Keychain and gives the AWS CLI temporary credentials for one verified process under a policy for the command and signed app. Operations that require the original keys hit a large warning. Download Automic Vault Read the source Published August 5, 2026 For Mac developers who still need AWS access keys, no other credential manager combines Keychain storage, per-command authorization, signed-launcher policy, process-bound credential delivery, short-lived sessions, MFA, roles, and a local audit record. We think that makes Automic Vault the best AWS credential manager available. Access Keys Need a Runtime Boundary the missing control AWS access keys often begin in ~/.aws/credentials . Any process running as you can read that file. Moving the pair into Keychain protects storage, but a useful credential manager must still release credentials when aws runs. aws-vault set the standard here. It stores keys in a secure backend, calls AWS STS, and exposes temporary credentials to a child process through environment variables or a local metadata server. We used it. It remains good software. Agents raised a harder question: which app launched aws , which operation did it request, and should that combination receive credentials without asking you? A wrapper around a shell session cannot answer that with the macOS identity and approval model. You Still Type aws one command av harden aws aws sts get-caller-identity The hardener imports the default access key pair into the macOS Keychain and installs a protected launcher at /usr/local/bin/aws . Your shell, scripts, and agents keep invoking aws . They never receive the stored keys in their ambient environment. The launcher registers the AWS arguments, selected profile, process ID, process start time, and a snapshot of the AWS config with the Automic Vault app. It then replaces itself with the Homebrew AWS CLI. The Credential Helper Knows Its Parent process-bound delivery The AWS CLI receives a minimal config containing Automic Vault's credential_process . AWS starts the helper as a child. The helper checks that its immediate parent has the registered PID and start time, uses the expected interpreter, and still has the approved arguments. A copied helper command cannot fetch credentials from another process. A stale registration cannot be replayed after aws exits. Each AWS invocation gets its own in-memory credential cache, which disappears with that process. Automic Vault runs the credential-bearing AWS process with an empty home and disables the normal ambient provider paths. Shared credential files, instance metadata, web identity, container credentials, plugins, aliases, pager hooks, and user-supplied credential processes stay outside that process. Temporary Credentials by Default STS and MFA The menu app calls AWS STS GetSessionToken and AssumeRole itself. Normal commands receive temporary credentials. Profiles with mfa_serial get an Automic Vault MFA prompt, and role profiles receive a role session rooted at the protected default keys. AWS restricts non-MFA GetSessionToken credentials from IAM and most STS operations. Those commands may need the original reusable keys. Automic Vault treats that as Elevated Secret Application and puts a large warning in the Approval window. Write Access still asks. Full Access may automically authorize the recognized operation when you choose it for the Launcher or an exact Blessed Script. Policy Follows the Launcher Terminal is not your agent Terminal, Codex, an editor, and an unknown process can invoke the same AWS binary. Automic Vault follows the process chain to the signed app and gives each launcher its own Secret Gate level. 01 / read only Agents inspect without deploying Commands classified as reads can proceed. Mutations and secret-revealing operations ask first. 02 / trusted Your terminal can work Normal operations follow command policy. Requests that reveal long-lived keys keep the gate. 03 / full You retain the dangerous knob An explicit launcher rule or blessed script can do everything. The approval UI says what that means. Authorization History records the Launcher, command, directory, requested Secret Names, and decision. The Authorization Policy and local record exist below the agent harness, so no agent integration has to cooperate. A Narrow Model That Fails Closed supported on purpose Automic Vault supports the imported default keys, regions, MFA, and role profiles whose source_profile chain ends at default . SSO, web identity, credential_source , independent named static keys, and custom credential processes fail with a precise error. The upstream AWS CLI remains a large Python program that Automic Vault cannot harden from within. End-to-end integrity depends on protecting its Homebrew distribution and interpreter. av harden brew is optional because developers deserve the knob, but we recommend it for the full security boundary. Yes, We Mean Best for AWS access keys on macOS AWS Identity Center and workload identity should replace long-lived IAM user keys where they fit. Plenty of developers still have keys, MFA devices, and role chains on their Macs. Those credentials deserve more than secure storage and a shell wrapper. Automic Vault narrows credential issuance to one live AWS process. It accounts for the Verified Launcher and command. It uses temporary sessions, warns before Elevated Secret Application, records the Authorization Decision, and leaves the dangerous policy choices in your hands. Download Automic Vault Inspect the implementation Sources AWS CLI: Sourcing credentials with an external process AWS STS: GetSessionToken AWS IAM: Secure API access with MFA aws-vault Automic Vault AWS hardener security model © 2026 Automic Vault. About Security Blog Privacy Terms GitHub # /blog/bringing-macos-security-to-the-terminal/ Bringing macOS Security to the Terminal | Automic Vault Blog Automic Vault Home Packages Blog Docs Download GitHub macOS terminal security Bringing macOS security to the terminal. Apple spent years giving apps stable identities, restricted data access, and explicit user consent. Most CLI tools still run inside the authority of whichever app launched them. That may be Terminal, an editor, or an AI harness. Download Automic Vault Security model Published July 12, 2026 The app that hosts your shell defines much of the command’s macOS security context. As more work moves from Terminal into agent harnesses, that host becomes part of every CLI trust decision. macOS Knows Apps the established boundary 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 CLI Inherits Its Room launcher authority 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. The Harness Is Now the Terminal agent execution 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. A Terminal-Layer Boundary identity and consent 01 / tool Identify the executable Use its code-signing identity and resolved path, so a lookalike binary cannot borrow the policy of the real tool. 02 / launcher Identify the hosting app Follow the process chain to the signed app that initiated the work, whether that is Terminal, an editor, or an agent harness. 03 / request Approve the sensitive action Bind access to the tool, launcher, command, directory, and requested secret. Record the resulting decision locally. The Automic Vault Boundary per-launcher policy Automic Vault resolves both the credential-bearing Target and the Verified Launcher above it. You can choose Write 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, Target, command, working directory, and Secret Name before you approve or deny the Secret Application. Authorization History retains the same context afterward. Automic Vault focuses on Secret Application 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 bounded local history to the terminal layer where developer credentials get used. Sources Apple Code Signing Services Apple App Sandbox documentation Apple: Protecting user data with App Sandbox Apple: Embedding a command-line tool in a sandboxed app Apple: Change Privacy & Security settings on Mac © 2026 Automic Vault. About Security Blog Privacy Terms GitHub # /blog/mac-security-best-practices-for-agents/ Best Practices for Using a Mac with Agents | Automic Vault Blog Automic Vault Home Packages Blog Docs Download GitHub macOS agent security Keep the Mac boundary intact. An agent can read files, launch tools, and install software at machine speed. The safest setup is not a Mac with its protections removed. It is a normal Mac whose existing boundaries are treated as hard limits. Published July 16, 2026 Give an agent the narrow access needed for its work, but do not dismantle the controls that limit what compromised software can do. Keep Gatekeeper and System Integrity Protection enabled, keep agents away from Downloads, and deny Full Disk Access and App Management. Keep the Defaults Working Gatekeeper and SIP Leave Gatekeeper enabled. For downloaded apps, Gatekeeper checks developer identity, notarization, and whether signed code has been altered. Do not make “Open Anyway” routine, remove quarantine attributes to silence warnings, or globally relax the policy for agent convenience. Leave System Integrity Protection enabled too. SIP restricts changes to critical parts of macOS even when a process has administrator privileges. An agent that genuinely requires SIP to be disabled should run on an isolated machine you are prepared to erase, not on the Mac that holds your identity, work, and credentials. Install as Your User no blanket elevation Most developer apps and tools can be installed in locations writable by your account. That is compatible with a secure agent workflow when the installation path is controlled and downloaded apps still pass Gatekeeper. Avoid giving the agent a reusable administrator credential or teaching it to approve every elevation prompt. Elevation should be an exceptional, visible act tied to a specific change. Treat Local App Builds as Untrusted maintainer risk Maintainers of large open-source projects face an additional targeted risk. If you build a .app from source and copy it into Applications yourself, that build may never pass through the downloaded-software path where Gatekeeper checks Developer ID, notarization, and integrity. Xcode’s “Sign to Run Locally” signature is ad hoc and tied to that particular build; it does not establish a stable, independently vouched-for distribution identity. Malware that can write to your build output or locally installed app may be able to replace its code and apply a new ad-hoc signature before you launch it. A valid signature then shows only that the current bundle has not changed since that new signature was applied—not that Apple notarized it or that it is the build you intended. This makes project knowledge valuable to an attacker. Someone who knows which apps you maintain, where you build them, or which development copy you run can target that exact path instead of attacking a public release. The larger and more trusted the project, the more valuable the maintainer’s local signing keys, release credentials, and repository access may be. For routine use, install the project’s Developer ID-signed and notarized release through a controlled download or package-management path, even when you are its maintainer. Keep development builds separate and ephemeral, protect their output directories from unrelated apps and agents, and verify the expected signing identity before treating a build as trusted. Notarization strengthens the installation boundary; it is not permanent protection for an app that remains writable afterward. Protect the Downloads Boundary stage, verify, install In System Settings → Privacy & Security → Files & Folders , turn off Downloads access for agent harnesses and other apps that do not need it. A downloaded app is most exposed between arrival and first launch. Software that can write to Downloads may be able to replace or modify that payload before you inspect it. This matters because Gatekeeper’s first-launch behavior depends in part on download provenance. Malware with write access could tamper with a download, apply an ad-hoc signature, and remove its quarantine metadata. Keeping untrusted automation out of Downloads preserves a clean handoff between the browser and Gatekeeper. If an agent needs to install GUI software, prefer brew install --cask through a Homebrew toolchain hardened with Automic Vault. That gives installations a constrained, inspectable route without granting the agent general write access to every browser download. Deny Broad Privacy Grants least authority Do not give an agent harness Full Disk Access. It collapses many of the privacy boundaries around mail, messages, browser data, backups, and other sensitive files. If a task needs a document, grant access to that document or working directory instead. Do not enable the App Management permission described by macOS as allowing an app to update or delete other apps. An agent that can rewrite applications can turn a trusted future launch into code execution. Install and update software through a narrow package-management path instead. Review Automation, Accessibility, Developer Tools, and Files & Folders at the same time. Remove grants that are not required for the agent’s current work. Permissions accumulate; a quarterly review is useful, but checking after each new integration is better. The Baseline operating rules 01 / platform Keep protections on Gatekeeper, SIP, secure boot, and normal macOS updates remain enabled. 02 / downloads Deny write access Agent apps do not receive Downloads access. Installation follows a controlled path. 03 / privacy Reject broad grants No Full Disk Access and no App Management permission for agent harnesses. Agents are useful precisely because they can act. The goal is not to make them powerless; it is to make each action occur inside boundaries that remain meaningful after a prompt injection, a compromised dependency, or a simple mistake. Use Automic Vault to protect your command line the missing boundary macOS privacy controls were designed around applications. You grant Downloads, Documents, Full Disk Access, Automation, or Accessibility permission to Terminal, an editor, or an agent harness. Commands launched inside that application then run as your Unix user and can use much of the authority of their host. macOS does not give every command-line executable its own granular Files & Folders panel , nor does it ask whether this particular invocation of gh , aws , kubectl , or a package script should be allowed to perform a sensitive action. Code signing and Gatekeeper answer whether downloaded code has an expected identity and remains intact. SIP protects critical operating-system locations. Neither is a per-command execution policy. Once an allowed host launches a tool, the operating system does not normally distinguish a command you typed from one assembled by an agent, a poisoned build script, or a compromised dependency. Automic Vault adds that missing command-line boundary. It resolves the signed identity and path of the executable, follows the process chain back to the signed app that launched it, and evaluates the requested command, working directory, and credential together. A rule can allow a familiar tool when you launch it directly from Terminal while requiring approval—or denying it—when the same binary is launched by an agent harness or from an unexpected project. Credentials stay out of plaintext dotfiles and out of the agent’s ambient environment. At the moment of use, Automic Vault can present the Verified Launcher, Target, arguments, directory, and Secret Names for Approval, then retain that context in Authorization History. The agent can still do useful work, but sensitive execution and Secret Application no longer follow from running as you. Automic Vault does not replace Gatekeeper, SIP, or macOS privacy controls. It completes them at the layer they do not address: the command line. Learn More About Automic Vault Sources Apple: Gatekeeper and runtime protection in macOS Apple: System Integrity Protection Apple: Control access to files and folders on Mac Apple: Change Privacy & Security settings on Mac Apple: Inside Code Signing requirements Apple: Notarizing macOS software before distribution © 2026 Automic Vault. About Security Blog Privacy Terms GitHub # /blog/prevent-bitwarden-cli-npm-compromise/ How Automic Vault Would Have Prevented the Bitwarden CLI npm Compromise | Automic Vault Blog Automic Vault Home Packages Blog Docs Download GitHub Bitwarden CLI npm compromise How Automic Vault would have prevented the Bitwarden CLI npm compromise. Bitwarden said the vault service was not breached. The dangerous part was the npm-distributed CLI package running with local developer authority. Automic Vault would have prevented that install-time code from turning a CLI update into workstation credential theft. Download Automic Vault Security model Run the scanner Published April 23, 2026 Automic Vault would have prevented the damaging local phase of this incident: the moment malicious package or extension code tried to read workstation secrets, use credential-bearing tools, or install persistence as the developer. Incident Facts local execution Date April 22, 2026 Trigger @bitwarden/cli 2026.4.0 from npm ran a malicious preinstall loader. Local targets ~/.ssh, .git-credentials, .npmrc, .env, shell history, cloud CLI state, and AI/MCP config files. Follow-on behavior Primary exfiltration to audit.checkmarx.cx with GitHub-based fallback staging and abuse of stolen tokens. What Happened? incident record Bitwarden disclosed that a malicious @bitwarden/cli 2026.4.0 npm package was briefly distributed on April 22, 2026. The NVD record for CVE-2026-42994 places the affected npm window from 21:57 UTC to 23:30 UTC. Researchers reported that the package used a malicious preinstall path and loader files instead of shipping the normal CLI. npm lifecycle scripts execute during installation, before a developer has a chance to run the command-line tool for a real password-manager task. The attacker did not need Bitwarden vault data to make the compromise serious. The local machine already had developer credentials: GitHub tokens, npm tokens, shell history, cloud credential databases, .env files, SSH material, and MCP or AI-tool configuration. The package tried to take those. Failure Point root cause The failed assumption was that an official package name meant install scripts were safe to run with the user account. The npm identity was trusted, so the local preinstall script inherited broad read access and network reachability. Classic secret scanning finds a leak after a value appears in a file, log, repository, or alert. This attack used the package install itself as the collection point. By the time an advisory appears, the attacker may already have enough material to push to repositories, publish new packages, or access cloud accounts. Where Automic Vault Would Have Stopped It prevention 01 / files Install code loses the secret trove Automic Vault keeps secrets out of plaintext developer-tool files. The malicious preinstall script loses the broad set of local credentials npm would otherwise expose to it. 02 / secrets Credential use would be tool-scoped The real Bitwarden CLI can be allowed to receive specific credentials for a specific execution. A setup loader or downloaded runtime does not automatically receive the same authority. 03 / execution Sensitive follow-on actions would require approval Creating repositories, using GitHub write APIs, publishing packages, or invoking credential-bearing tools are the kinds of actions Automic Vault puts behind visible command approval gates. Workstation Prevention Boundary local boundary Automic Vault would have prevented the local credential theft phase by denying the install hook the thing it wanted most: ambient access to every useful file and token on the developer machine. The compromised package could still fail installation. It could still be detected as a bad release later. What it could not do is silently collect ~/.ssh, .npmrc, cloud CLI state, shell history, and AI-tool config as a single attacker-ready archive. For developer workstations, that is the prevention line that matters. Automic Vault turns a poisoned package from a credential breach into an untrusted execution attempt with no easy local secrets to steal. Automic Vault does not claim to make npm, PyPI, GitHub Actions, or extension marketplaces impossible to compromise. The prevention claim is narrower and more useful: compromised tools should not inherit every credential and sensitive path on a developer machine. Sources Bitwarden public statement NVD CVE-2026-42994 Socket research on the Bitwarden CLI compromise © 2026 Automic Vault. About Security Blog Privacy Terms GitHub # /blog/prevent-durabletask-pypi-compromise/ How Automic Vault Would Have Prevented the durabletask PyPI Compromise | Automic Vault Blog Automic Vault Home Packages Blog Docs Download GitHub durabletask PyPI compromise How Automic Vault would have prevented the durabletask PyPI compromise. The durabletask incident turned a Python import into a cloud and developer credential collection path. Automic Vault would have prevented the package from converting local workstation authority into stolen cloud, SSH, and infrastructure secrets. Download Automic Vault Security model Run the scanner Published May 20, 2026 Automic Vault would have prevented the damaging local phase of this incident: the moment malicious package or extension code tried to read workstation secrets, use credential-bearing tools, or install persistence as the developer. Incident Facts local execution Date May 19, 2026 Trigger durabletask 1.4.1, 1.4.2, and 1.4.3 contained import-time dropper code. Local targets AWS, Azure, GCP, Kubernetes, SSH, Docker, npm, PyPI, Cargo, Terraform, Pulumi, Ansible, Vault, 1Password, Bitwarden, pass, and gopass material. Follow-on behavior Download and execution of rope.pyz, encrypted exfiltration, fallback channels, persistence, and possible cloud or Kubernetes lateral movement. What Happened? incident record On May 19, 2026, three malicious durabletask releases appeared on PyPI. StepSecurity reported that the versions were uploaded directly to PyPI without corresponding GitHub tags, releases, or CI/CD runs, which points to a publishing credential compromise rather than a normal repository release. The package contained a small Python dropper that fetched a second-stage payload named rope.pyz from attacker infrastructure. The malicious behavior began at import time, so a developer, CI runner, or service importing durabletask could trigger the collection chain. The second stage targeted a broad infrastructure surface: cloud credentials, Kubernetes contexts, SSH keys, Docker config, package registry tokens, Terraform and Pulumi state, Ansible vault passwords, HashiCorp Vault, and local password-manager tooling. Failure Point root cause The failed assumption was that a legitimate PyPI project imported by a trusted application should inherit the host account. Once durabletask code executed, it had enough local authority to enumerate cloud and infrastructure secrets far outside the narrow job of a workflow SDK. This is exactly where detection-only security is too late. If the import runs and rope.pyz reads the local credential map, the response becomes rotation, investigation, and rebuild. Prevention requires making those credentials unavailable to arbitrary library code in the first place. Where Automic Vault Would Have Stopped It prevention 01 / files Imports would not expose raw infrastructure secrets Automic Vault keeps supported credentials out of plaintext developer files and makes local secret hazards visible. A library import would not receive the workstation as an open credential filesystem. 02 / secrets Secret-manager and cloud use would be scoped Cloud and secret-manager access should happen through approved tools with visible target context. A downloaded Python zipapp does not get broad AWS, Kubernetes, Vault, or password-manager authority by default. 03 / execution Dropper and persistence behavior would be constrained Fetching a second-stage payload, installing service files, and running follow-on infrastructure commands are meaningful execution boundaries. Automic Vault puts those tool actions under local control. Workstation Prevention Boundary local boundary Automic Vault would have prevented the durabletask compromise from becoming a full environment compromise by removing the package import from the credential trust path. The poisoned wheel could still exist. The import could still be attempted. But the attack would not find broad local secrets, would not receive approved credential injection, and would not silently cross into cloud, Kubernetes, or password-manager operations. That is the difference between a compromised dependency and a compromised developer environment. Automic Vault does not claim to make npm, PyPI, GitHub Actions, or extension marketplaces impossible to compromise. The prevention claim is narrower and more useful: compromised tools should not inherit every credential and sensitive path on a developer machine. Sources StepSecurity durabletask analysis Wiz durabletask TeamPCP analysis Upwind durabletask malware report © 2026 Automic Vault. About Security Blog Privacy Terms GitHub # /blog/prevent-github-vscode-extension-breach/ How Automic Vault Would Have Prevented the GitHub Employee Device Breach | Automic Vault Blog Automic Vault Home Packages Blog Docs Download GitHub GitHub employee device breach How Automic Vault would have prevented the GitHub employee device breach. The GitHub aftermath is the cleanest proof that local developer compromise can become organization-wide source exposure. Automic Vault would have prevented the poisoned extension from turning one endpoint into a bridge to internal repositories. Download Automic Vault Security model Run the scanner Published May 21, 2026 Automic Vault would have prevented the damaging local phase of this incident: the moment malicious package or extension code tried to read workstation secrets, use credential-bearing tools, or install persistence as the developer. Incident Facts local execution Date May 18 to May 20, 2026 Trigger A poisoned VS Code extension compromised an employee device; public reporting later linked the chain to Nx Console. Local targets Editor session authority, repository access, GitHub auth material, local secrets, and source-control context available from the employee workstation. Follow-on behavior Exfiltration of GitHub-internal repositories, immediate endpoint isolation, secret rotation, and incident response. What Happened? incident record GitHub publicly confirmed in May 2026 that an employee device was compromised through a poisoned VS Code extension and that the activity involved exfiltration of GitHub-internal repositories. Public reports said the attacker claim of roughly 3,800 repositories was directionally consistent with GitHub investigation statements. The chain matters: a developer tool update ran on a workstation, reached local auth and repository context, and became a source-code exposure event for a major developer platform. That is the downstream version of the same pattern visible in LiteLLM, Bitwarden CLI, TanStack, node-ipc, Nx Console, and durabletask. The package or extension compromise happens upstream. The breach happens when the local machine grants broad authority to the compromised code. Failure Point root cause GitHub is one of the most security-aware developer organizations in the world, which makes the lesson harder to dismiss. A single endpoint with a poisoned developer extension can still become a repository access path if local credentials and source-control authority are available to that process. The usual answer is faster detection and faster rotation. Those are necessary, but they are still response controls. The prevention control is to make the endpoint incapable of handing raw repository credentials and local secrets to arbitrary extension code in the first place. Where Automic Vault Would Have Stopped It prevention 01 / files Repository access would not be ambient Automic Vault treats source-control credentials and command execution as local authority that should be scoped to trusted tools and approved operations, not exposed to every process in an editor session. 02 / secrets Secrets would stay behind a local broker The poisoned extension would lose the plaintext local tokens, SSH material, cloud credentials, and tool configs that turn one machine into many downstream accounts. 03 / execution High-impact actions would be visible Repository exfiltration, credential use, package publishing, and cloud or source-control mutations are exactly the kind of actions that should produce a local approval or hazard signal before they run. Workstation Prevention Boundary local boundary Automic Vault would have prevented the GitHub employee device breach at the workstation boundary. It would not have made the upstream extension ecosystem perfect. It would have denied the compromised extension the local materials needed to become repository access. That prevention claim is stronger than advice to be careful with extensions. Developers need extensions and packages. The missing control is a local execution layer that assumes one of those tools will eventually be bad and still refuses to hand it the whole workstation. The GitHub incident is the reason Automic Vault exists: secure the tools developers install before a trusted package, CLI, or editor extension gets one bad update. Automic Vault does not claim to make npm, PyPI, GitHub Actions, or extension marketplaces impossible to compromise. The prevention claim is narrower and more useful: compromised tools should not inherit every credential and sensitive path on a developer machine. Sources TechCrunch GitHub repository breach report BleepingComputer GitHub breach coverage Nx official postmortem StepSecurity Nx Console analysis © 2026 Automic Vault. About Security Blog Privacy Terms GitHub # /blog/prevent-keyv-npm-worm/ How Automic Vault Would Have Prevented the Keyv npm Worm | Automic Vault Blog Automic Vault Home Packages Blog Docs Download GitHub Keyv npm supply-chain worm How Automic Vault would have prevented the Keyv npm credential theft. The Keyv worm used npm install hooks to steal developer credentials, then used those credentials to poison more packages and repositories. Automic Vault would have kept protected secrets behind an explicit handoff, denying the worm the tokens it needed to steal and spread. Download Automic Vault Security model Run the scanner Published August 4, 2026 With supported Secrets moved out of plaintext files and npm installs running from a terminal set to Approval Required, Automic Vault would have denied the worm the GitHub, npm, and AWS Credentials stored behind its gates. That breaks both the credential theft and the stolen-token path used to republish packages. Incident Facts local execution Date August 4, 2026 Trigger keyv@6.0.0 and related packages added "preinstall": "node setup.mjs" . The Keyv repository also contained Claude Code and VS Code hooks that ran when a developer opened it. Observed scope SafeDep confirmed 2,234 poisoned versions across 444 package names while the response was active. The linked breaking report described at least 868 affected packages. Targets and spread GitHub, npm, AWS, GCP, Azure, Kubernetes, Vault, Stripe, Slack, private keys, and database credentials. Stolen npm and GitHub tokens let the worm publish more releases and modify more repositories. What Happened? incident record Attackers pushed malicious files into the Keyv source repository and published keyv@6.0.0 through the legitimate GitHub Actions release workflow. The npm package carried valid provenance because the real workflow built the poisoned source. A bare npm install ran setup.mjs before the install finished. The dropper fetched the Bun runtime when necessary and launched a large credential stealer. Investigators found code for harvesting package-registry tokens, GitHub credentials, cloud keys, Kubernetes and Vault access, Stripe and Slack tokens, private keys, and database URLs. The payload then used stolen npm tokens to publish malicious patch releases of every package the victim could maintain. GitHub tokens gave it a second route: it could modify repositories and add hooks to .claude/settings.json and .vscode/tasks.json , causing code to run when another developer opened the project. The package count changed throughout the response. SafeDep confirmed 2,234 poisoned versions across 444 names and found that heavily downloaded transitive dependencies such as flat-cache and file-entry-cache carried the same payload. Failure Point root cause Valid provenance proved that Keyv's real release pipeline built the package. It did not prove that the source entering that pipeline was safe. Once the install hook ran, npm gave it the developer account's readable files and inherited environment. The worm needed two local capabilities to spread: permission to read credentials and permission to use them. Automic Vault controls that boundary on a Mac by removing supported credentials from ambient files and releasing them only to an approved command launched by an identified signed app. Where Automic Vault Would Have Stopped It prevention 01 / files The stealer would find fewer usable credentials av scan finds exposed local credentials, while hardeners and av save move supported values into Keychain. Secrets removed from ~/.npmrc , ~/.config/gh , environment files, and cloud config are no longer readable by an npm install hook. 02 / secrets An install terminal would have no automatic handoff Automic Vault checks the Target, Verified Launcher, command, working directory, and requested Secret Names before Secret Application. Under the recommended Authorization Policy, the terminal used for npm install is set to Approval Required, so the worm cannot obtain those values without a human decision. 03 / execution Stolen-token propagation would fail Without a protected npm publishing token or GitHub credential, the worm cannot publish under that developer's identity or commit hooks to their repositories. Other infected machines could still spread it, but this workstation would stop contributing credentials to the chain. Workstation Prevention Boundary local boundary Automic Vault would have prevented theft of credentials that a developer had moved behind its gate, provided the install ran from a launcher with no automatic access. Protecting npm and GitHub credentials would also have cut the worm's propagation route through that developer's packages and repositories. The poisoned package could still install and execute arbitrary code. It could read plaintext secrets left outside Automic Vault, damage user-writable files, add persistence, and reach credentials supplied by cloud metadata or container service accounts. Automic Vault is a secret handoff boundary, not a general process sandbox. Run package installs in a dedicated terminal with low-to-no privileges in both Automic Vault and macOS TCC. On a suspected host, follow the incident responders' order of operations and hunt the reported token monitor before rotating credentials, because investigators found a dead-man switch triggered by revocation. Automic Vault does not clean an infected machine or make npm, GitHub Actions, Claude Code, or VS Code immune to compromise. It prevents protected secrets from becoming ambient authority. An approved executable can still use a secret released to it, and root compromise remains outside the product boundary. Sources SafeDep technical analysis and live package count Aikido analysis of the Keyv compromise and worm Wiz Research compromised-package list International Cyber Digest breaking report © 2026 Automic Vault. About Security Blog Privacy Terms GitHub # /blog/prevent-litellm-pypi-compromise/ How Automic Vault Would Have Prevented the LiteLLM PyPI Compromise | Automic Vault Blog Automic Vault Home Packages Blog Docs Download GitHub LiteLLM PyPI compromise How Automic Vault would have prevented the LiteLLM PyPI compromise. The poisoned LiteLLM releases were an upstream PyPI failure, but the breach became dangerous only after package code inherited local secrets. Automic Vault would have prevented that workstation credential theft phase. Download Automic Vault Security model Run the scanner Published March 25, 2026 Automic Vault would have prevented the damaging local phase of this incident: the moment malicious package or extension code tried to read workstation secrets, use credential-bearing tools, or install persistence as the developer. Incident Facts local execution Date March 24, 2026 Trigger litellm 1.82.7 ran through package code; 1.82.8 added a Python .pth startup hook. Local targets ~/.ssh, cloud credential files, environment variables, Kubernetes tokens, database passwords, and .env-style secrets. Follow-on behavior Data exfiltration to a lookalike LiteLLM domain plus persistence under user config and systemd paths. What Happened? incident record On March 24, 2026, malicious LiteLLM releases 1.82.7 and 1.82.8 reached PyPI. Public analysis from Datadog and Snyk ties the poisoned releases to a wider TeamPCP supply-chain campaign that first stole publishing material through other developer tooling. The high-risk version was 1.82.8 because the attacker added a Python .pth file. Python processes load .pth files from site-packages during interpreter startup, so the malware did not need a developer to explicitly import LiteLLM in the application path. A normal local Python startup in the affected environment could trigger collection. The payload looked for the exact files developers tend to leave on a Mac or Linux workstation: SSH keys, cloud CLI credentials, Kubernetes material, database passwords, shell-adjacent secrets, and environment variables. This was a local developer credential theft incident. Failure Point root cause The core failure was ambient authority. Once the package executed, it ran as the developer and could read the same home-directory files the developer could read. PyPI quarantine shortened the exposure window, but quarantine happened after the malicious code had already reached some machines. A lockfile, vulnerability scanner, or registry advisory can tell you that a bad release exists. It cannot un-read SSH keys, cloud tokens, or kubeconfig from a machine where the payload has already run. Prevention has to happen before package code can touch those files. Where Automic Vault Would Have Stopped It prevention 01 / files Secret files would not be readable Automic Vault moves supported secrets out of plaintext files and makes exposed local hazards visible. LiteLLM package code would not have found raw AWS, GitHub, .env, or SSH-adjacent material sitting in easy-read locations. 02 / secrets Approved tools receive scoped secrets A legitimate LiteLLM process can receive the credential it is approved to use. A .pth startup hook or package import does not get a broad dump of every local credential just because Python started. 03 / execution Persistence and sensitive commands would be visible Service writes, helper execution, and privileged follow-on behavior belong at an approval boundary. The attempt to install a user-level monitor would have become an explicit local security event instead of a silent second stage. Workstation Prevention Boundary local boundary Automic Vault would have prevented the damaging phase by changing the default: package code gets the project and approved tool context, not the developer account as a readable secret store. In an Automic Vault setup, the poisoned wheel could still arrive from PyPI. The difference is what happens next. The startup hook would run inside a machine where important credentials have been moved behind a local broker, sensitive tool use requires approval, and suspicious package state is visible as a local hazard. That means the attacker would have had to defeat the local runtime boundary instead of merely reading files. For this incident, that boundary is the difference between a bad package install and a full credential rotation event. Automic Vault does not claim to make npm, PyPI, GitHub Actions, or extension marketplaces impossible to compromise. The prevention claim is narrower and more useful: compromised tools should not inherit every credential and sensitive path on a developer machine. Sources Datadog Security Labs LiteLLM analysis Snyk analysis of the poisoned scanner chain Wiz incident summary GitHub advisory GHSA-5mg7-485q-xm76 © 2026 Automic Vault. About Security Blog Privacy Terms GitHub # /blog/prevent-node-ipc-npm-backdoor/ How Automic Vault Would Have Prevented the node-ipc npm Backdoor | Automic Vault Blog Automic Vault Home Packages Blog Docs Download GitHub node-ipc npm backdoor How Automic Vault would have prevented the node-ipc npm backdoor. The node-ipc incident shows why install-script policy is not enough. The malicious code ran from the CommonJS entrypoint when the package was loaded. Automic Vault would have prevented the loaded library from finding useful local secrets to exfiltrate. Download Automic Vault Security model Run the scanner Published May 15, 2026 Automic Vault would have prevented the damaging local phase of this incident: the moment malicious package or extension code tried to read workstation secrets, use credential-bearing tools, or install persistence as the developer. Incident Facts local execution Date May 14, 2026 Trigger node-ipc 9.1.6, 9.2.3, and 12.0.1 contained a backdoored CommonJS entrypoint. Local targets Environment variables, npm and GitHub credentials, cloud CLI state, SSH keys, kubeconfig, desktop key stores, browser key databases, and app tokens. Follow-on behavior Detached child process, temporary archive staging, and DNS TXT exfiltration through attacker-controlled resolver infrastructure. What Happened? incident record Datadog reported that three node-ipc releases published on May 14, 2026 contained the same malicious node-ipc.cjs file. The payload was not an npm lifecycle script. It lived in the CommonJS module path, so it could activate when application or test code required the package. The malware forked a detached child process, staged collected files into a temporary archive, compressed the result, and sent it out over DNS. Many organizations focus on HTTP exfiltration while allowing DNS traffic by default. The target list was broad and local: npm files, GitHub CLI state, Git credential files, AWS/Azure/GCP credentials, SSH keys, Kubernetes config, environment variables, and desktop token stores. The package acted as a local credential collector. Failure Point root cause This incident defeats a narrow defense that only disables npm preinstall and postinstall scripts. The payload activated at runtime, after dependency installation was over. Any policy that assumes library code is safe once installed misses this class of attack. The deeper problem is that application dependencies usually run with the same filesystem view as the developer. A utility library should not be able to read cloud credentials and desktop key stores merely because the process required a module. Where Automic Vault Would Have Stopped It prevention 01 / files Runtime access would be constrained Automic Vault containment and package boundaries cover the execution layer after installation. A loaded dependency should not receive arbitrary access to home-directory secret stores. 02 / secrets Secrets would be brokered, not scraped Tools that need credentials can receive approved, scoped values. A library backdoor that scans ~/.aws, ~/.config/gh, .npmrc, or SSH material would find far less useful data. 03 / execution Suspicious process behavior would become reviewable Detached child processes, archive staging, and secret-bearing command use are meaningful risk boundaries. Automic Vault makes those local execution decisions visible instead of treating them as normal library behavior. Workstation Prevention Boundary local boundary Automic Vault would have prevented the useful theft, even though the malicious package could still be present in node_modules. The key is that presence is not authority. In a protected setup, the node-ipc payload can try to fork and enumerate files, but the credentials it wants are no longer freely readable files. It can try to exfiltrate, but the archive lacks the local secret material that made the campaign valuable. That is the practical prevention line for runtime backdoors: deny ambient credential access before detection has to be perfect. Automic Vault does not claim to make npm, PyPI, GitHub Actions, or extension marketplaces impossible to compromise. The prevention claim is narrower and more useful: compromised tools should not inherit every credential and sensitive path on a developer machine. Sources Datadog node-ipc malware analysis Socket node-ipc compromise report The Hacker News coverage © 2026 Automic Vault. About Security Blog Privacy Terms GitHub # /blog/prevent-nx-console-vscode-compromise/ How Automic Vault Would Have Prevented the Nx Console VS Code Extension Compromise | Automic Vault Blog Automic Vault Home Packages Blog Docs Download GitHub Nx Console VS Code compromise How Automic Vault would have prevented the Nx Console extension compromise. The malicious Nx Console update ran from inside the editor, where developers keep the richest context: repositories, terminals, GitHub auth, cloud CLIs, and password-manager sessions. Automic Vault would have prevented the extension from inheriting that local authority. Download Automic Vault Security model Run the scanner Published May 21, 2026 Automic Vault would have prevented the damaging local phase of this incident: the moment malicious package or extension code tried to read workstation secrets, use credential-bearing tools, or install persistence as the developer. Incident Facts local execution Date May 18, 2026 Trigger nrwl.angular-console 18.95.0 was published to the Visual Studio Marketplace and Open VSX. Local targets GitHub auth stores, Vault tokens, npm tokens, cloud metadata and CLI state, SSH keys, .env files, Docker config, GCP ADC, and active 1Password CLI session contents. Follow-on behavior Payload download from a hidden commit, HTTPS/GitHub/DNS exfiltration, and persistence through local Python and LaunchAgent files. What Happened? incident record Nx disclosed that a malicious Nx Console 18.95.0 extension was live on May 18, 2026 in the Visual Studio Marketplace and Open VSX. Nx tied the incident back to an earlier compromised contributor machine that had resolved malicious package content. StepSecurity reported that the extension downloaded payload code from a hidden commit and ran a credential stealer when the editor opened a workspace. That activation path is especially dangerous because developers trust editor extensions with source trees, terminals, and project automation. The local target set included GitHub credentials, npm tokens, cloud and Kubernetes material, .env files, Docker config, HashiCorp Vault tokens, and active 1Password CLI sessions. The extension also wrote persistence artifacts on the workstation. Failure Point root cause The editor became the trust boundary, and the editor was too broad. A signed or marketplace-delivered extension update could run with access to the user session and the repository workspace, including auth stores that were never meant for arbitrary extension code. This is the same ambient-authority failure as a poisoned package, but worse in practice. Editor extensions sit close to source control, agent tooling, terminals, and secrets. A bad update can cross from local workstation compromise into organization-wide source and credential exposure. Where Automic Vault Would Have Stopped It prevention 01 / files Editor-launched code would not read every secret Automic Vault keeps sensitive values out of plaintext files and model-visible context. A malicious extension loses the raw GitHub, cloud, Vault, and .env material exposed through local config paths. 02 / secrets Password-manager and CLI access would be mediated Active sessions and credential helpers should not become ambient input to extension code. Automic Vault routes approved credential use to trusted tools and shows the target command before access is granted. 03 / execution Persistence writes would be treated as risky Writing LaunchAgents, backdoor scripts, or global editor and tool settings is not a normal package read. Those changes belong behind visible local approval and hazard detection. Workstation Prevention Boundary local boundary Automic Vault would have prevented the Nx Console incident from becoming a workstation credential breach by denying the malicious extension the broad local secrets it expected. The extension could still be bad. The marketplace could still ship version 18.95.0. But without readable GitHub auth stores, cloud secrets, password-manager session material, and silent persistence, the attacker loses the bridge from extension install to durable local compromise. This is the product lesson: developer tools need a local runtime boundary because trust in an extension marketplace is not the same thing as trust in every extension process that starts on your machine. Automic Vault does not claim to make npm, PyPI, GitHub Actions, or extension marketplaces impossible to compromise. The prevention claim is narrower and more useful: compromised tools should not inherit every credential and sensitive path on a developer machine. Sources Nx official postmortem StepSecurity Nx Console analysis BleepingComputer GitHub downstream coverage © 2026 Automic Vault. About Security Blog Privacy Terms GitHub # /blog/prevent-tanstack-npm-compromise/ How Automic Vault Would Have Prevented the TanStack npm Credential Theft | Automic Vault Blog Automic Vault Home Packages Blog Docs Download GitHub TanStack npm compromise How Automic Vault would have prevented the TanStack npm credential theft. The TanStack attack bypassed normal package trust by abusing the release pipeline. Automic Vault would not need to predict that upstream chain. It would have prevented the installed malware from reading local secrets and turning a valid npm package into an endpoint breach. Download Automic Vault Security model Run the scanner Published May 15, 2026 Automic Vault would have prevented the damaging local phase of this incident: the moment malicious package or extension code tried to read workstation secrets, use credential-bearing tools, or install persistence as the developer. Incident Facts local execution Date May 11, 2026 Trigger 84 malicious versions across 42 @tanstack packages were published through the trusted npm path. Local targets Cloud credentials, kubeconfig, SSH keys, GitHub and npm state, Docker config, Terraform files, Claude and Kiro MCP configs, and editor hooks. Follow-on behavior Session/Oxen file uploads, additional command-and-control domains, GitHub API abuse, and local persistence in AI/editor configuration. What Happened? incident record TanStack published a detailed postmortem showing that the attacker chained a pull_request_target workflow pattern, GitHub Actions cache poisoning, and OIDC token extraction from runner memory. The result was not a fake package. It was a poisoned package published through a trusted path. That upstream story is important, but the local story is what hurts developers. Once the malicious packages resolved on a workstation, the payload searched for the usual developer secrets: cloud CLI state, SSH keys, npm and GitHub credentials, Kubernetes config, Docker config, Terraform credentials, and AI-tool settings. The malware also targeted persistence surfaces that are specific to modern developer workflows. It wrote into Claude settings, VS Code tasks, and monitor-style local files. That is a clear signal that attackers now treat AI and editor configuration as credential-bearing infrastructure. Failure Point root cause TanStack had modern supply-chain controls, but the package that reached developers could still contain malicious runtime behavior. Provenance can tell you where a package came from. It cannot guarantee that code running locally should read ~/.aws, ~/.ssh, or .claude configuration. The practical lesson is that release integrity and local least privilege are different controls. You need both. When release integrity fails, local least privilege decides whether the compromised package becomes a machine-wide credential breach. Where Automic Vault Would Have Stopped It prevention 01 / files Local secret exposure would be removed Automic Vault scans for local secret hazards and moves supported secrets out of files that package code can read directly. The payload would not find the same plain credential map. 02 / secrets Agent and editor config would be treated as sensitive Claude, MCP, and editor task files are part of the local authority surface. Automic Vault shows package, path, Credential, Launcher, and Target context before a Tool gets sensitive access. 03 / execution Dangerous tool use would hit gates GitHub writes, package publishing, cloud mutations, and secret injection are approval boundaries. A poisoned dependency does not get to use those capabilities invisibly just because it arrived through npm. Workstation Prevention Boundary local boundary Automic Vault would have prevented the damaging endpoint phase by making the malicious package run without the broad credential set it expected. The upstream npm publish would still be a serious incident, but the workstation would not be an all-you-can-read secret sink. Local developer credential protection still matters when a project has SLSA, OIDC trusted publishing, and transparent postmortems. The package still executes on a developer machine. For TanStack, the strongest prevention claim is simple: Automic Vault would have broken the attacker assumptions that home directories are readable, secret-bearing CLIs are ambient, and editor or AI-tool hooks can be modified without a visible security decision. Automic Vault does not claim to make npm, PyPI, GitHub Actions, or extension marketplaces impossible to compromise. The prevention claim is narrower and more useful: compromised tools should not inherit every credential and sensitive path on a developer machine. Sources TanStack official postmortem SafeDep cache poisoning analysis Semgrep TanStack incident notes TechCrunch on downstream OpenAI impact © 2026 Automic Vault. About Security Blog Privacy Terms GitHub # /de/ Automic Vault | Ein neuartiger Secrets Manager für eine neue Ära der Entwicklung Automic Vault Secrets Richtlinien Audit GitHub Für macOS laden Vom Erfinder von Homebrew Ein neuartiger Secrets Manager für eine neue Ära der Entwicklung. Automic Vault entfernt Secrets für CLI-Tools aus Klartextdateien und kontrolliert dann, welche signierte App jedes Tool mit welchem Credential ausführen darf. Jeder Agent. Jedes Harness. Zeroconf. Für macOS laden So funktioniert die Grenze → 01 Klartext-Secrets entfernen Credentials verschwinden aus Dotfiles und Tool-Konfigurationen. 02 Die Übergabe kontrollieren Nur das richtige Executable erhält das Credential. 03 Eine lokale Grenze anwenden Für jeden Starter gilt dieselbe Richtlinie. Dein Agent erbt deinen Zugriff Ein Prompt kann kein Secret schützen, das der Agent bereits lesen kann. C Claude Hmm… der Remote-Server hat keinen AWS-Zugriff. C Claude Kein Problem — ich lade die Schlüssel von hier hoch. T Tool-Aufruf Read(~/.aws/credentials) R Tool-Ergebnis [default] aws_access_key_id = AKIA•••••••••••• aws_secret_access_key = •••••••••••••••••••••••••••••••• SECRET EXFILTRIERT Ein wiederverwendbares Cloud-Credential hat gerade die Vertrauensgrenze überschritten. Nach Automic Vault C Claude Hmm… der Remote-Server hat keinen AWS-Zugriff. C Claude Kein Problem — ich lade die Schlüssel von hier hoch. T Tool-Aufruf Read(~/.aws/credentials) Automic Vault entfernt Klartext-Secrets R Tool-Ergebnis Datei nicht gefunden C Claude Ich führe stattdessen den Export-Befehl aus. T Tool-Aufruf aws config export-credentials Automic Vault sperrt Zugriffswege für die Exfiltration von Secrets ! Automic Vault Menschliche Freigabe erforderlich Secrets zu verschlüsseln reicht nicht Menschliche Freigabe erforderlich Secrets zu verschlüsseln ist nur die halbe Miete, wenn sie für sensible Aktionen verwendet werden können. Automic Vault schützt deine Secrets nicht nur; es kontrolliert ihre Nutzung . Befehl, Arbeitsverzeichnis und angeforderter Schlüssel sind vor der Ausführung sichtbar. Zugriff nach App Die Richtlinie folgt dem Tool und seinem Starter. Terminal, Codex und ein unbekannter Prozess können dasselbe Executable aufrufen. Automic Vault erkennt den signierten Starter und gibt jeder Kombination eine eigene Zugriffsrichtlinie. Kein Zugriff Die App erhält keinen automatischen Zugriff. Jede Anfrage braucht deine Freigabe. Vertrauenswürdiger Zugriff Für ein Terminal, in dem du nie npm i ausführen willst. Befehle, die Secrets offenlegen, behalten immer eine Freigabesperre. Nur Lesen Für Tools, denen du teilweise vertraust, etwa Agents. Sichere Lesevorgänge dürfen laufen; Schreibvorgänge brauchen eine Freigabe. Installierte Pakete müssen dieselbe Grenze überschreiten, um geschützte Secrets zu verwenden. Defense in Depth bleibt wichtig: Führe npm i in einem eigenen Terminal mit geringen oder keinen Rechten in Automic Vault und macOS TCC aus. Jede Secret-Nutzung wird protokolliert. Genehmigt oder abgelehnt, automatisch oder manuell: Jede Anfrage hinterlässt lokal Starter, Schlüssel, Befehl, Arbeitsverzeichnis und Entscheidung. Entscheidung Starter Angeforderter Schlüssel Arbeitsverzeichnis Abgelehnte und genehmigte Anfragen landen im selben Audit-Protokoll. Jeder Fund enthält Auslöser, Begründung und Schritte zur Behebung. Kontinuierliche Überwachung von Bedrohungen in deinen Entwicklungsumgebungen Automic Vault überwacht Entwickler-Tools in allen Ökosystemen. Neue Bedrohungen werden sofort mit klaren Schritten zur Behebung markiert. Unabhängig vom Harness Kontrolliere die Tool-Schicht unter jedem Agent. Kommandozeilen-Tools laufen mit den Rechten der App, die sie gestartet hat. Automic Vault erkennt das Tool und seinen signierten Starter und wendet die Regeln an, die du für diese Kombination gewählt hast. Warum das Terminal eine eigene Sicherheitsschicht braucht → Dieselbe CLI kann über Terminal, ein Agent-Harness oder eine andere Host-App unterschiedliche Zugriffsrechte erhalten. Kostenlos und Open Source. Automic Vault kostet nichts. Für zusätzliche Sicherheit gibt es die optionale iPhone-App als kostenpflichtiges Abonnement. Sie verlagert die Freigaben vom Computer, auf dem die Befehle ausgeführt werden, auf dein Telefon, wo keine Agents oder Malware sie abfangen können. Vom Erfinder von Homebrew. Für macOS laden Automic Vault Über uns Sicherheit Blog Datenschutz Bedingungen 𝕏 GitHub © 2026 · Apache-2.0 English 日本語 Deutsch Français 简体中文 # /de/about/ Über Automic Vault | Sichere die Tools, die du mit brew install installierst Herunterladen Pakete Blog Über uns GitHub Hintergrund Sichere die Tools, die du mit brew install installierst, vom Homebrew-Erfinder. Automic Vault ist für die realen Terminals, Pakete und Credentials von macOS-Entwicklern entworfen. Herunterladen Dokumentation Max Howell Max Howell hat Homebrew 2009 erstellt und baut seit langem Entwicklerwerkzeuge für macOS. Warum jetzt AI-Agents erweitern lokale Berechtigungen; Secrets und Befehle brauchen deshalb klare Grenzen. Lokale Laufzeitgrenze Automic Vault trennt Dateien, die ein Agent lesen kann, von Credentials, die nur genehmigte Tools erhalten. Die Kontrolle sitzt im Ausführungspfad auf dem Mac, nicht nur in einer Agent-Anweisung. Homebrew und CLIs Viele Entwicklerwerkzeuge kommen über Homebrew, npm, PyPI und Cloud-CLIs. Vault erkennt Credential-Dateien und riskante Aktionen, die diese Tools hinterlassen, und setzt Freigaben an die passende Stelle. Nächste Schritte Starte zuerst den Scanner, verschiebe unterstützte Secrets in geschützten lokalen Speicher und lasse Automic Vault laufen, damit neue Hazard-Hinweise sofort sichtbar bleiben. Was sich nach der Installation ändert Die bekannten CLIs bleiben nutzbar. Der Unterschied ist, dass Secrets nicht mehr als einfache Konfigurationsdateien herumliegen, sondern nur an die genehmigte Ausführung übergeben werden, die sie wirklich braucht. Zusammenspiel mit zentralen Vaults 1Password, HashiCorp Vault und Cloud-Secret-Systeme können weiter die Quelle der Wahrheit bleiben. Automic Vault schützt den lokalen Moment, in dem ein Mac-Tool diese Werte verwenden will. Weiterführende Seiten Dokumentation, Download, Secret Scanner und Paketkatalog zeigen den Weg von Erkennung zu Härtung, Approval Gates und laufender Überwachung der Entwickler-Maschine. Laufende Überwachung Neue Pakete, veraltete Tools und neu erzeugte Konfigurationsdateien können nach der ersten Bereinigung wieder Risiken schaffen. Automic Vault bleibt aktiv und meldet frische Hazards. Vertrauenshinweise Öffentliches Repository, Sicherheitsseite, Lizenz und der Homebrew-Hintergrund von Max Howell sind verlinkt. Eine lokale Sicherheitsgrenze sollte überprüfbar sein. Wann einsetzen Nutze Automic Vault vor Agent-Läufen in Repositories, vor Cloud-CLI-Arbeit und bevor Befehle wie npm publish, gh release oder Infrastrukturänderungen echte Berechtigungen ausgeben. Automic Vault Sichere die Tools, die du mit brew install installierst, vom Homebrew-Erfinder. Herunterladen Dokumentation Pakete © 2026 Automic Vault. Website Über uns Blog Datenschutz Bedingungen GitHub English 日本語 Deutsch Français 简体中文 # /de/download/ Automic Vault herunterladen | Schutz für AI-Agents und Entwickler-Tools Herunterladen Pakete Blog Über uns GitHub Download Automic Vault für macOS herunterladen Installiere die lokale Sicherheitschicht für Homebrew-Pakete, CLI-Secrets und AI-Agent-Aktionen auf macOS. Herunterladen Dokumentation Direkter Download Lade die .dmg-Datei herunter oder installiere über das install.sh-Skript im Terminal. Was enthalten ist Enthalten sind die native App, das av-Kommandozeilenwerkzeug, Secret-Scanner-Workflows und Nucleus-Paketkontrollen. Nach der Installation Starte zuerst den Secret Scanner, prüfe Klartext-Credentials und verschiebe unterstützte Secrets in geschützten lokalen Speicher. Lokale Laufzeitgrenze Automic Vault trennt Dateien, die ein Agent lesen kann, von Credentials, die nur genehmigte Tools erhalten. Die Kontrolle sitzt im Ausführungspfad auf dem Mac, nicht nur in einer Agent-Anweisung. Homebrew und CLIs Viele Entwicklerwerkzeuge kommen über Homebrew, npm, PyPI und Cloud-CLIs. Vault erkennt Credential-Dateien und riskante Aktionen, die diese Tools hinterlassen, und setzt Freigaben an die passende Stelle. Nächste Schritte Starte zuerst den Scanner, verschiebe unterstützte Secrets in geschützten lokalen Speicher und lasse Automic Vault laufen, damit neue Hazard-Hinweise sofort sichtbar bleiben. Was sich nach der Installation ändert Die bekannten CLIs bleiben nutzbar. Der Unterschied ist, dass Secrets nicht mehr als einfache Konfigurationsdateien herumliegen, sondern nur an die genehmigte Ausführung übergeben werden, die sie wirklich braucht. Zusammenspiel mit zentralen Vaults 1Password, HashiCorp Vault und Cloud-Secret-Systeme können weiter die Quelle der Wahrheit bleiben. Automic Vault schützt den lokalen Moment, in dem ein Mac-Tool diese Werte verwenden will. Weiterführende Seiten Dokumentation, Download, Secret Scanner und Paketkatalog zeigen den Weg von Erkennung zu Härtung, Approval Gates und laufender Überwachung der Entwickler-Maschine. Laufende Überwachung Neue Pakete, veraltete Tools und neu erzeugte Konfigurationsdateien können nach der ersten Bereinigung wieder Risiken schaffen. Automic Vault bleibt aktiv und meldet frische Hazards. Vertrauenshinweise Öffentliches Repository, Sicherheitsseite, Lizenz und der Homebrew-Hintergrund von Max Howell sind verlinkt. Eine lokale Sicherheitsgrenze sollte überprüfbar sein. Automic Vault Automic Vault für macOS herunterladen Herunterladen Dokumentation Pakete © 2026 Automic Vault. Website Über uns Blog Datenschutz Bedingungen GitHub English 日本語 Deutsch Français 简体中文 # /de/llms.txt # Automic Vault > Automic Vault entfernt Klartext-Secrets aus CLI-Tools und steuert am lokalen Ausführungsrand, welche signierten Mac-Apps sie verwenden dürfen. ## Wichtige Seiten - [Automic Vault | Ein neuartiger Secrets Manager für eine neue Ära der Entwicklung](https://www.automicvault.com/de/): Entferne CLI-Secrets aus Klartextdateien und kontrolliere, welche signierten Apps sie verwenden dürfen. - [Automic Vault herunterladen](https://www.automicvault.com/de/download/): Lade Automic Vault für macOS herunter und schütze lokale AI-Agent-Läufe. - [Dokumentation](https://www.automicvault.com/docs/): Englisches, quellgeprüftes CLI-Handbuch für Automic Vault 2.9.0 mit scan, doctor, save, inject, bless und harden. - [Pakete](https://pkg.so/de/): Durchsuchbarer Katalog mit Entwicklerpaketen, Abhängigkeiten, Installationsbefehlen, Risikoinformationen und Automic-Vault-Härtung. - [Blog](https://www.automicvault.com/blog/): Sicherheitsleitfäden und Analysen zu Paket-, Erweiterungs-, Credential- und lokalen Ausführungsvorfällen. - [Über Automic Vault | Sichere die Tools, die du mit brew install installierst](https://www.automicvault.com/de/about/): Automic Vault sichert Homebrew-Tools, CLI-Secrets und Command-Approval-Gates lokal auf deinem Mac, bevor AI-Agents sie verwenden. - [Automic Vault Datenschutz](https://www.automicvault.com/de/privacy/): Lokale Datengrenzen, Website-Analytics und Datenschutznotizen für Automic Vault. - [Automic Vault Bedingungen](https://www.automicvault.com/de/terms/): Nutzungsbedingungen, Open-Source-Lizenz und Website-Hinweise für Automic Vault. - [GitHub](https://github.com/automic-vault/automic-vault): Apache-2.0-Quellcode, markierte Releases, Implementierungshistorie und öffentliche Fehlerverfolgung. - [Sicherheit](https://www.automicvault.com/.well-known/security.txt): Veröffentlicht den aktuellen Sicherheitskontakt, die bevorzugte Sprache, die kanonische Adresse und das Ablaufdatum. ## Kernfakten - Plattform: macOS - Aktuell dokumentiertes Release: 2.9.0 - Lizenz: Apache License 2.0 - Preis: kostenlose Open-Source-Software - Gründer: Max Howell, Schöpfer von Homebrew ## Kontakt - Website: https://www.automicvault.com/de/ - GitHub: https://github.com/automic-vault/automic-vault - Sicherheitsmeldungen: https://github.com/automic-vault/automic-vault/issues # /de/privacy/ Automic Vault Datenschutz | Schutz für AI-Agents und Entwickler-Tools Herunterladen Pakete Blog Über uns GitHub Automic Vault Lokale Secrets bleiben lokal Lokale Datengrenzen, Website-Analytics und Datenschutznotizen für Automic Vault. Herunterladen Dokumentation Produktdaten Automic Vault schützt Secrets auf dem Entwicklergerät und ist kein gehosteter Secret-Dienst. Websitedaten Die Website nutzt grundlegende Analytics und öffentliche Assets, sammelt aber keine Produkt-Secrets. Lokale Laufzeitgrenze Automic Vault trennt Dateien, die ein Agent lesen kann, von Credentials, die nur genehmigte Tools erhalten. Die Kontrolle sitzt im Ausführungspfad auf dem Mac, nicht nur in einer Agent-Anweisung. Homebrew und CLIs Viele Entwicklerwerkzeuge kommen über Homebrew, npm, PyPI und Cloud-CLIs. Vault erkennt Credential-Dateien und riskante Aktionen, die diese Tools hinterlassen, und setzt Freigaben an die passende Stelle. Nächste Schritte Starte zuerst den Scanner, verschiebe unterstützte Secrets in geschützten lokalen Speicher und lasse Automic Vault laufen, damit neue Hazard-Hinweise sofort sichtbar bleiben. Was sich nach der Installation ändert Die bekannten CLIs bleiben nutzbar. Der Unterschied ist, dass Secrets nicht mehr als einfache Konfigurationsdateien herumliegen, sondern nur an die genehmigte Ausführung übergeben werden, die sie wirklich braucht. Zusammenspiel mit zentralen Vaults 1Password, HashiCorp Vault und Cloud-Secret-Systeme können weiter die Quelle der Wahrheit bleiben. Automic Vault schützt den lokalen Moment, in dem ein Mac-Tool diese Werte verwenden will. Weiterführende Seiten Dokumentation, Download, Secret Scanner und Paketkatalog zeigen den Weg von Erkennung zu Härtung, Approval Gates und laufender Überwachung der Entwickler-Maschine. Laufende Überwachung Neue Pakete, veraltete Tools und neu erzeugte Konfigurationsdateien können nach der ersten Bereinigung wieder Risiken schaffen. Automic Vault bleibt aktiv und meldet frische Hazards. Vertrauenshinweise Öffentliches Repository, Sicherheitsseite, Lizenz und der Homebrew-Hintergrund von Max Howell sind verlinkt. Eine lokale Sicherheitsgrenze sollte überprüfbar sein. Wann einsetzen Nutze Automic Vault vor Agent-Läufen in Repositories, vor Cloud-CLI-Arbeit und bevor Befehle wie npm publish, gh release oder Infrastrukturänderungen echte Berechtigungen ausgeben. Automic Vault Lokale Secrets bleiben lokal Herunterladen Dokumentation Pakete © 2026 Automic Vault. Website Über uns Blog Datenschutz Bedingungen GitHub English 日本語 Deutsch Français 简体中文 # /de/terms/ Automic Vault Bedingungen | Schutz für AI-Agents und Entwickler-Tools Herunterladen Pakete Blog Über uns GitHub Automic Vault Open-Source-Werkzeug für lokale Sicherheit Nutzungsbedingungen, Open-Source-Lizenz und Website-Hinweise für Automic Vault. Herunterladen Dokumentation Lizenz Automic Vault wird unter der Apache License 2.0 bereitgestellt. Nutzung Diese Website stellt Produktinformationen, Dokumentation und Paketmetadaten bereit. Lokale Laufzeitgrenze Automic Vault trennt Dateien, die ein Agent lesen kann, von Credentials, die nur genehmigte Tools erhalten. Die Kontrolle sitzt im Ausführungspfad auf dem Mac, nicht nur in einer Agent-Anweisung. Homebrew und CLIs Viele Entwicklerwerkzeuge kommen über Homebrew, npm, PyPI und Cloud-CLIs. Vault erkennt Credential-Dateien und riskante Aktionen, die diese Tools hinterlassen, und setzt Freigaben an die passende Stelle. Nächste Schritte Starte zuerst den Scanner, verschiebe unterstützte Secrets in geschützten lokalen Speicher und lasse Automic Vault laufen, damit neue Hazard-Hinweise sofort sichtbar bleiben. Was sich nach der Installation ändert Die bekannten CLIs bleiben nutzbar. Der Unterschied ist, dass Secrets nicht mehr als einfache Konfigurationsdateien herumliegen, sondern nur an die genehmigte Ausführung übergeben werden, die sie wirklich braucht. Zusammenspiel mit zentralen Vaults 1Password, HashiCorp Vault und Cloud-Secret-Systeme können weiter die Quelle der Wahrheit bleiben. Automic Vault schützt den lokalen Moment, in dem ein Mac-Tool diese Werte verwenden will. Weiterführende Seiten Dokumentation, Download, Secret Scanner und Paketkatalog zeigen den Weg von Erkennung zu Härtung, Approval Gates und laufender Überwachung der Entwickler-Maschine. Laufende Überwachung Neue Pakete, veraltete Tools und neu erzeugte Konfigurationsdateien können nach der ersten Bereinigung wieder Risiken schaffen. Automic Vault bleibt aktiv und meldet frische Hazards. Vertrauenshinweise Öffentliches Repository, Sicherheitsseite, Lizenz und der Homebrew-Hintergrund von Max Howell sind verlinkt. Eine lokale Sicherheitsgrenze sollte überprüfbar sein. Wann einsetzen Nutze Automic Vault vor Agent-Läufen in Repositories, vor Cloud-CLI-Arbeit und bevor Befehle wie npm publish, gh release oder Infrastrukturänderungen echte Berechtigungen ausgeben. Automic Vault Open-Source-Werkzeug für lokale Sicherheit Herunterladen Dokumentation Pakete © 2026 Automic Vault. Website Über uns Blog Datenschutz Bedingungen GitHub English 日本語 Deutsch Français 简体中文 # /docs/ Automic Vault CLI Manual Automic Vault Home Packages Blog Docs Download GitHub The av manual. Source-checked documentation for the command line shipped by Automic Vault 2.9.0: audit the machine, repair hardened tools, verify signed CLI launchers, save a named value, and release it to one approved command. macOS CLI 2.9.0 Checked August 2, 2026 Markdown On this page Install Quick start Mental model Commands Scan Doctor Signed CLI launchers Save Inject Bless Harden Catalogs Open Exit status Unsupported Source Install and verify Automic Vault requires macOS and currently expects Homebrew. Install the app, open it once, then confirm the CLI on your path. brew install --cask automic-vault/isotopes/automic-vault open /Applications/Automic\ Vault.app av --version av help You can also use the current GitHub release or review and run the website installer . The menu bar app owns approval UI and policy; open it before a command needs approval. av open Five-minute path Run the complete exposure report, save one value through the hidden terminal prompt, then release it only to the command that needs it. av scan --show-all av save GH_TOKEN av inject +GH_TOKEN gh auth status save does not read standard input. It opens /dev/tty and disables terminal echo while reading. Remove an old plaintext export only after confirming the approved command works. Mental model Automic Vault stores named Secrets in the macOS Keychain. av inject submits an Authorization Request containing the resolved Target, arguments, working directory, requested Secret Names, and existing environment conflicts. The app applies the Authorization Policy or asks for Approval. If allowed, av replaces itself with the Target process. This is a Secret Application boundary, not a general sandbox. The Target receives the rest of the current environment and controls a Secret after receipt. Keep macOS, the app, and each authorized Target in your trust model. Command surface av scan Scan the home directory and report supported Exposure and Hazard Findings. av doctor Validate installed hardeners, launchers, dependencies, and path precedence. av detectors --json List the detector catalog and its embedded source documentation. av hardeners --json List hardener applicability, paths, commands, documentation, and Secret Gate routes. av save KEY Read one hidden Secret from the terminal and store it under a valid Secret Name. av inject +KEY COMMAND Request named Secrets and execute one authorized Target. av bless PATH Review an exact script and store its Blessing. av harden NAME Apply a reviewed tool-specific migration or launcher boundary. av open Open the app or a specific Secret Gate. av scan Scan the current home directory for supported credential Exposures, Hazards, and other Detector Findings. av scan av scan --show-all av scan --json The default human report hides medium- and low-severity findings. --show-all includes those lower-severity findings. --json writes an object containing findings and gui_path . A completed scan exits 0 even when it finds problems. Treat the report, not the status code, as the audit result. Each finding includes a source, severity, explanation, remediation, affected paths, and a source-linked detector document. av doctor Check whether installed hardening still has the expected target, dependencies, launcher type, owner, permissions, content, and PATH precedence. av doctor av doctor gh av doctor gh --json av doctor claude av doctor codex Without a selector, doctor checks applicable installed hardeners. A selector can be a hardener, one of its commands, or a supported signed agent CLI. Exit 0 : every selected check is healthy. Exit 1 : one or more issues require attention. Exit 2 : invalid arguments, an unknown selector, or a selector with no Doctor-owned checks. JSON output contains results ; each issue includes its kind, message, remediation, and relevant stub, target, or resolved path. Signed CLI launchers Automic Vault can bind an Authorization Policy to either a signed app bundle or a Developer ID-signed standalone executable. It validates the live code signature and stores the Launcher's designated requirement, which identifies the binary and its signing team. A standalone executable must have a valid Developer ID Application signature, identifier, and Team ID. It must pass strict macOS signature validation, and it must enable Hardened Runtime before it can receive Secret Gate access. Unsigned and ad-hoc signed executables are rejected because they do not establish a vendor or Team identity. av doctor claude av doctor codex These commands inspect the executable selected by the current PATH . In Automic Vault Settings, add the launcher to the relevant tool or blessed-script policy and select the resolved native executable rather than a shell or package-manager shim. Review its identifier, Team ID, path, and designated requirement before allowing it. If the identity cannot be verified later, automic authorization fails closed and requires Approval. Code signing proves identity and integrity, not intent. Keep the terminal or agent app's permissions minimal because TCC remains app-scoped. av save Store one named Secret in the Automic Vault Keychain. av save GH_TOKEN The Secret Name must be a valid environment variable name: it begins with a letter or underscore and continues with letters, digits, or underscores. The command opens /dev/tty , disables terminal echo while reading, trims the line ending, rejects an empty value, and restores echo even if reading fails. # Wrong: save deliberately does not read stdin. printf '%s\n' "$GH_TOKEN" | av save GH_TOKEN av inject Request one or more named Secrets, then execute a Target. av inject +GH_TOKEN gh auth status av inject +AWS_ACCESS_KEY_ID +AWS_SECRET_ACCESS_KEY -- \ aws sts get-caller-identity Full syntax av inject [--replace-existing-env] [--allow-missing-keys] \ +KEY [+KEY...] [--] COMMAND [args...] A bare command such as gh is resolved from PATH . A target containing a slash must be an absolute path. -- is optional, but useful when the target or its arguments could be mistaken for inject options. Existing environment values win by default; a warning is printed for every conflict. --replace-existing-env lets the approved Keychain value replace an existing environment value. A missing requested Secret fails by default. --allow-missing-keys leaves it unset. Duplicate or invalid Secret Names are rejected. av inject refuses to run as root, and the approval service must be running. The Authorization Request is denied if the service cannot authenticate, the Authorization Policy does not allow the operation, or the user declines. If allowed, av uses exec , so the Target replaces the av process. Shebang use #!/usr/local/bin/av inject +API_TOKEN /bin/sh set -eu exec curl -H "Authorization: Bearer $API_TOKEN" \ https://api.example.test/me The script path is included in the Authorization Request. Keep the interpreter path absolute and the shebang to one requested-Secret set plus one interpreter. av bless Review an exact script and its Script Declaration. av bless ./release.sh The app shows the canonical path, SHA-256 checksum, requested Secret Names, Capabilities, injection flags, and Target interpreter. Approval creates a Blessing bound to that complete review. Editing or moving the script makes the Blessing stop matching. A blessable script must be a regular UTF-8 file no larger than 1 MiB and start with an absolute av inject shebang whose target interpreter is also absolute. #!/usr/local/bin/av inject +GH_TOKEN /bin/sh # --- automic-vault # capabilities: # gh: write # --- set -eu gh release create "$1" The optional manifest must immediately follow the shebang. It may grant named Secret Gates one of read-only , local-write , write , or full . read-and-updates and trusted remain compatibility aliases. Unsupported gates and Access Levels are rejected. Capabilities are ceilings: undeclared or broader requests from the script are denied. full includes Secret Disclosure and Elevated Secret Application and should be granted sparingly. Run av bless --endorse-launcher ./release.sh to include a Launcher Endorsement in the review. Only an endorsed Verified Launcher can use the Blessing with automic authorization. With no Launcher Endorsement, each execution requires Approval. --endorse-caller remains a compatibility alias. Blessed scripts run from a verified /dev/fd/N snapshot so edits cannot race Approval. AV_SCRIPT_PATH contains the canonical source path and AV_SCRIPT_DIR its containing directory. Blessings can be inspected, narrowed, or revoked under Blessed Scripts in the app. av harden Apply a named hardener. av harden NAME av harden NAME --yes Hardeners are Tool-specific security transformations. Depending on the Tool, a Hardener can move existing Credentials into Keychain, install or replace a Launcher, change protected ownership, or enable a native credential route. Review the embedded documentation and prompts before approving system changes. Some root-owned launchers require sudo ; follow the selected hardener's instructions rather than running every hardener as root. --yes skips confirmation where supported. A successful run prints the matching av doctor NAME command. av hardeners --json | jq '.hardeners[] | {name, applicable, hardened, commands, documentation}' The source includes dedicated hardeners for AWS CLI, Homebrew, GitHub CLI, sudo, and Supabase plus generated environment wrappers for supported tools. Availability and applicability depend on the installed tool and machine. Machine-readable catalogs List every detector and its embedded source documentation. av detectors --json | jq '.detectors[] | {name, docs_url, documentation}' List hardener state, commands, paths, and Secret Gate routes. av hardeners --json | jq '.hardeners[] | { name, applicable, hardened, stub_path, target_path, commands, secret_gate }' These are the reliable automation interfaces for discovering the catalog shipped by an installed build. Do not hard-code a copied list of detectors or hardeners. av open Open the app and show its main window, or open a specific Secret Gate by its path-safe ID. av open av open --secret-gate gh Gate IDs may contain ASCII letters, digits, hyphens, underscores, and periods. The option is also used by product links and generated guidance. Global options and exit status av help av --version av inject --help av inject --version 0 for a completed command or approved execution. 1 for an operational failure, denied request, or unhealthy doctor result. 2 for top-level usage errors and invalid doctor selection. The target's behavior begins after a successful inject , because that process replaces av . Commands that are not in v2 The earlier v1 manual described install , contain , dotenv , credential-helper , gate , and trace . Those commands are not part of the Automic Vault 2.9.0 dispatcher. Use av help from the installed build as the authoritative top-level list. Source of truth This manual was checked against the tagged 2.9.0 implementation: mod.rs , scan.rs , doctor.rs , save.rs , inject.rs , bless.rs , open.rs , and the isotope catalog . For a particular installation, prefer its av help , av detectors --json , and av hardeners --json output. Report discrepancies in the issue tracker . Run only what you mean to authorize. © 2026 Automic Vault. About Security Privacy Terms GitHub # /docs/index.md # Automic Vault CLI manual This manual documents the public `av` command surface shipped by Automic Vault 2.9.0. It was checked against `~/src/av2` on August 2, 2026. The supported top-level commands are: ```text av scan [--show-all | --json] av doctor [COMMAND] [--json] av detectors --json av hardeners --json av bless PATH av inject +KEY [--] COMMAND av save KEY av harden NAME [--yes] av open [--secret-gate ID] ``` Commands from the earlier v1 CLI—including `install`, `contain`, `dotenv`, `credential-helper`, `gate`, and `trace`—are not part of the 2.9.0 CLI. ## Install and verify Automic Vault requires macOS and currently expects Homebrew. ```sh brew install --cask automic-vault/isotopes/automic-vault open /Applications/Automic\ Vault.app av --version av help ``` You can also download the current DMG from [GitHub Releases](https://github.com/automic-vault/automic-vault/releases/latest) or review and run the [website installer](https://www.automicvault.com/install.sh). The menu bar app owns Approval UI and Authorization Policy. Open it before using commands that require Approval: ```sh av open ``` ## Five-minute path Run a complete exposure scan, save one value through the hidden terminal prompt, then release it only to the command that needs it: ```sh av scan --show-all av save GH_TOKEN av inject +GH_TOKEN gh auth status ``` `av save` reads from `/dev/tty`; it does not read standard input. The value is not echoed. Remove any old plaintext export only after confirming the approved command works. ## Mental model Automic Vault stores named Secrets in the macOS Keychain. `av inject` submits an Authorization Request containing the resolved Target, arguments, working directory, requested Secret Names, and any existing environment conflicts. The app applies the Authorization Policy or asks for Approval. If allowed, `av` replaces itself with the Target process. This is a Secret Application boundary, not a general sandbox. The Target receives the rest of the current environment and controls a Secret after receipt. Keep macOS, the app, and each authorized Target in your trust model. ## `av scan` Scan the current home directory for supported credential Exposures, Hazards, and other Detector Findings. ```sh av scan av scan --show-all av scan --json ``` - The default human report hides medium- and low-severity findings. - `--show-all` includes those lower-severity findings. - `--json` writes an object containing `findings` and `gui_path`. - A completed scan exits `0` even when it reports findings. Treat the report, not the status code, as the audit result. Each finding includes a source, severity, explanation, remediation, affected paths, and a source-linked detector document. ## `av doctor` Check whether installed hardening still has the expected target, dependencies, launcher type, owner, permissions, content, and `PATH` precedence. ```sh av doctor av doctor gh av doctor gh --json av doctor claude av doctor codex ``` Without a selector, `doctor` checks applicable installed hardeners. A selector can be a hardener, one of its commands, or a supported signed agent CLI. - Exit `0`: every selected check is healthy. - Exit `1`: one or more issues require attention. - Exit `2`: invalid arguments, an unknown selector, or a selector with no Doctor-owned checks. JSON output contains `results`; each issue includes its `kind`, message, remediation, and relevant stub, target, or resolved path. ## Signed CLI launchers Automic Vault can bind an Authorization Policy to either a signed app bundle or a Developer ID-signed standalone executable. It validates the live code signature and stores the launcher's designated requirement, which identifies the binary and its signing team. A standalone executable must have a valid Developer ID Application signature, identifier, and Team ID. It must pass strict macOS signature validation, and it must enable Hardened Runtime before it can receive Secret Gate access. Unsigned and ad-hoc signed executables are rejected because they do not establish a vendor or Team identity. Run `av doctor claude` or `av doctor codex` to inspect the executable selected by your current `PATH`. In Automic Vault Settings, add the launcher to the relevant tool or blessed-script policy and select the resolved native executable rather than a shell or package-manager shim. Review its identifier, Team ID, path, and designated requirement before allowing it. If the identity cannot be verified later, automic authorization fails closed and requires Approval. Code signing proves identity and integrity, not intent. Keep the terminal or agent app's permissions minimal because TCC remains app-scoped. ## `av save` Store one named Secret in the Automic Vault Keychain: ```sh av save GH_TOKEN ``` The Secret Name must be a valid environment variable name: it begins with a letter or underscore and continues with letters, digits, or underscores. The command opens `/dev/tty`, disables terminal echo while reading, trims the line ending, rejects an empty value, and restores echo even if reading fails. Pipes do not provide the value: ```sh # Wrong: save deliberately does not read stdin. printf '%s\n' "$GH_TOKEN" | av save GH_TOKEN ``` ## `av inject` Request one or more named Secrets, then execute a Target: ```sh av inject +GH_TOKEN gh auth status av inject +AWS_ACCESS_KEY_ID +AWS_SECRET_ACCESS_KEY -- aws sts get-caller-identity ``` Full syntax: ```text av inject [--replace-existing-env] [--allow-missing-keys] \ +KEY [+KEY...] [--] COMMAND [args...] ``` Behavior: - A bare command such as `gh` is resolved from `PATH`. - A target containing a slash must be an absolute path. - `--` is optional, but useful when the target or its arguments could be mistaken for inject options. - Existing environment values win by default. A warning is printed for each conflict. - `--replace-existing-env` lets the approved Keychain value replace an existing environment value. - A missing requested Secret fails the run by default. - `--allow-missing-keys` leaves missing Secrets unset; this is primarily useful for generated wrappers that support optional credentials. - Duplicate or invalid Secret Names are rejected. - `av inject` refuses to run as root. - The menu bar approval service must be running. The Authorization Request is denied if the service cannot authenticate, the Authorization Policy does not allow the operation, or the user declines it. If allowed, `av` uses `exec`, so the Target replaces the `av` process rather than becoming a detached child. ### Shebang use `av inject` can act as a script interpreter: ```sh #!/usr/local/bin/av inject +API_TOKEN /bin/sh set -eu exec curl -H "Authorization: Bearer $API_TOKEN" https://api.example.test/me ``` The script path is included in the Authorization Request. Keep the interpreter path absolute and the shebang to one requested-Secret set plus one interpreter. ## `av bless` Review an exact script and its Script Declaration: ```sh av bless ./release.sh ``` The app shows the canonical path, SHA-256 checksum, requested Secret Names, Capabilities, injection flags, and Target interpreter. Approval creates a Blessing bound to that complete review. Editing or moving the script makes the Blessing stop matching. A blessable script must be a regular UTF-8 file no larger than 1 MiB and start with an absolute `av inject` shebang whose target interpreter is also absolute: ```sh #!/usr/local/bin/av inject +GH_TOKEN /bin/sh # --- automic-vault # capabilities: # gh: write # --- set -eu gh release create "$1" ``` The optional manifest must immediately follow the shebang. It may grant named Secret Gates one of `read-only`, `local-write`, `write`, or `full`; unsupported gates or Access Levels are rejected. `read-and-updates` and `trusted` remain compatibility aliases. Capabilities are ceilings: undeclared or broader requests from the script are denied. `full` includes Secret Disclosure and Elevated Secret Application and should be granted sparingly. Run `av bless --endorse-launcher ./release.sh` to include a Launcher Endorsement in the review. Only an endorsed Verified Launcher can use the Blessing with automic authorization. With no Launcher Endorsement, each execution requires Approval. `--endorse-caller` remains a compatibility alias. Blessed scripts run from a verified `/dev/fd/N` snapshot so edits cannot race approval. `AV_SCRIPT_PATH` contains the canonical source path and `AV_SCRIPT_DIR` its containing directory. Blessings can be inspected, narrowed, or revoked under **Blessed Scripts** in the app. ## `av harden` Apply a named hardener: ```sh av harden NAME av harden NAME --yes ``` Hardeners are Tool-specific security transformations. Depending on the Tool, a Hardener can move existing Credentials into Keychain, install or replace a Launcher, change protected ownership, or enable a native credential route. Review its embedded documentation and prompts before approving system changes. Some root-owned launchers require `sudo`; follow the selected hardener's instructions rather than running every hardener as root. `--yes` skips confirmation where the selected hardener supports it. A successful run prints the matching `av doctor NAME` command. Discover the current catalog before choosing a name: ```sh av hardeners --json | jq '.hardeners[] | {name, applicable, hardened, commands, documentation}' ``` The source currently includes dedicated hardeners for AWS CLI, Homebrew, GitHub CLI, sudo, and Supabase plus generated environment wrappers for supported tools. Availability and applicability depend on the installed tool and current machine. The project [Domain Language](https://github.com/automic-vault/automic-vault/blob/main/docs/domain-language.md) defines the security terms used throughout these docs. ## Machine-readable catalogs List every detector and its source documentation: ```sh av detectors --json | jq '.detectors[] | {name, docs_url, documentation}' ``` List hardener state, commands, paths, and Secret Gate routes: ```sh av hardeners --json | jq '.hardeners[] | { name, applicable, hardened, stub_path, target_path, commands, secret_gate }' ``` These commands are the most reliable way for automation to discover the catalog shipped by the installed build. Do not hard-code a copied list of detectors or hardeners. ## `av open` Open the Automic Vault app and show its main window: ```sh av open ``` Open a specific Secret Gate by its path-safe ID: ```sh av open --secret-gate gh ``` Gate IDs may contain ASCII letters, digits, hyphens, underscores, and periods. The option is also used by product links and generated guidance. ## Global options and exit status ```sh av help av --version av inject --help av inject --version ``` The CLI convention is: - `0` for a completed command or approved execution; - `1` for an operational failure, denied request, or unhealthy `doctor` result; - `2` for top-level usage errors and invalid `doctor` selection. The executed target's own behavior begins after a successful `inject`, because that target replaces the `av` process. ## Source of truth This manual was checked against the following implementation files: - [`src/cli/mod.rs`](https://github.com/automic-vault/automic-vault/blob/2.9.0/src/cli/mod.rs) - [`src/cli/scan.rs`](https://github.com/automic-vault/automic-vault/blob/2.9.0/src/cli/scan.rs) - [`src/cli/doctor.rs`](https://github.com/automic-vault/automic-vault/blob/2.9.0/src/cli/doctor.rs) - [`src/cli/save.rs`](https://github.com/automic-vault/automic-vault/blob/2.9.0/src/cli/save.rs) - [`src/cli/inject.rs`](https://github.com/automic-vault/automic-vault/blob/2.9.0/src/cli/inject.rs) - [`src/cli/bless.rs`](https://github.com/automic-vault/automic-vault/blob/2.9.0/src/cli/bless.rs) - [`src/cli/open.rs`](https://github.com/automic-vault/automic-vault/blob/2.9.0/src/cli/open.rs) - [`src/isotopes`](https://github.com/automic-vault/automic-vault/tree/2.9.0/src/isotopes) For a particular installation, prefer the installed command's `av help`, `av detectors --json`, and `av hardeners --json` output. Report documentation or security discrepancies in the [Automic Vault issue tracker](https://github.com/automic-vault/automic-vault/issues). # /download/ Download Automic Vault Download Packages Blog About GitHub Download Download Automic Vault for macOS Install the local security layer for CLI secrets, developer tools, and AI agent actions on macOS. Download Docs Direct download Download the signed .dmg, open Automic Vault, and follow the setup guide to install the av command-line tool. What is included The native app manages Authorization Gates, Authorization Policies, Tool Hardening, and local Authorization History. After installation Move a Credential out of plaintext storage, choose which Verified Launchers may use it, then review each sensitive request before it runs. Automic Vault Download Automic Vault for macOS Download Docs Packages © 2026 Automic Vault. Website About Blog Privacy Terms GitHub English 日本語 Deutsch Français 简体中文 # /fr/ Automic Vault | Un nouveau gestionnaire de secrets pour une nouvelle ère du développement Automic Vault Secrets Politiques Audit GitHub Télécharger pour macOS Par le créateur de Homebrew Un nouveau type de gestionnaire de secrets pour une nouvelle ère du développement. Automic Vault retire les secrets des outils CLI des fichiers en clair, puis contrôle quelle application signée peut exécuter chaque outil avec chaque identifiant. N’importe quel agent. N’importe quel environnement. Zéro configuration. Télécharger pour macOS Voir la limite en action → 01 Supprimer les secrets en clair Les identifiants quittent les dotfiles et les configurations d’outils. 02 Contrôler le transfert Seul le bon exécutable reçoit l’identifiant. 03 Appliquer une limite locale Chaque lanceur rencontre la même politique. Votre agent hérite de vos accès Un prompt ne peut pas protéger un secret que l’agent peut déjà lire. C Claude Hmm… le serveur distant n’a pas accès à AWS. C Claude Pas de problème — je vais transférer les clés depuis ici. T Appel d’outil Read(~/.aws/credentials) R Résultat de l’outil [default] aws_access_key_id = AKIA•••••••••••• aws_secret_access_key = •••••••••••••••••••••••••••••••• SECRET EXFILTRÉ Un identifiant cloud réutilisable vient de franchir la frontière de confiance. Après Automic Vault C Claude Hmm… le serveur distant n’a pas accès à AWS. C Claude Pas de problème — je vais transférer les clés depuis ici. T Appel d’outil Read(~/.aws/credentials) Automic Vault élimine les secrets en clair R Résultat de l’outil Fichier introuvable C Claude Je vais exécuter la commande d’export à la place. T Appel d’outil aws config export-credentials Automic Vault contrôle l’accès aux voies d’exfiltration des secrets ! Automic Vault Validation humaine requise Chiffrer les secrets ne suffit pas Validation humaine requise Chiffrer les secrets ne représente que la moitié du travail lorsqu’ils peuvent servir à effectuer des actions sensibles. Automic Vault ne se contente pas de protéger vos secrets ; il contrôle leur utilisation . Commande, dossier de travail et clé demandée sont visibles avant l’exécution. Accès par application La politique suit l’outil et son lanceur. Terminal, Codex et un processus inconnu peuvent invoquer le même exécutable. Automic Vault identifie le lanceur signé et attribue à chaque association sa propre politique d’accès. Aucun accès L’application ne reçoit aucun accès automatique. Chaque requête demande votre validation. Accès de confiance Pour un terminal où vous ne comptez jamais exécuter npm i . Les commandes révélant des secrets conservent toujours une validation. Lecture seule Pour les outils auxquels vous accordez une confiance partielle, comme les agents. Les lectures sûres passent; les écritures demandent une validation. Chaque utilisation de secret est journalisée. Approuvée ou refusée, automatique ou manuelle : chaque demande laisse un enregistrement local avec le lanceur, la clé, la commande, le dossier de travail et la décision. Décision Lanceur Clé demandée Dossier de travail Les demandes refusées et approuvées partagent la même piste d’audit. Chaque signalement indique son déclencheur, sa justification et les étapes de correction. Surveillance continue des menaces dans vos environnements de développement Automic Vault surveille les outils de développement dans tous les écosystèmes. Les nouvelles menaces sont signalées immédiatement avec des étapes claires pour les corriger. Indépendant de l’environnement Contrôlez la couche outil sous chaque agent. Les outils en ligne de commande s’exécutent avec l’autorité de l’application qui les lance. Automic Vault identifie l’outil et son lanceur signé, puis applique les règles choisies pour cette association. Pourquoi le terminal a besoin de sa propre couche de sécurité → La même CLI peut recevoir des accès différents depuis Terminal, un environnement d’agent ou une autre application hôte. Gratuit et open source. Automic Vault ne coûte rien. Pour renforcer la sécurité, l’app iPhone facultative est proposée sur abonnement payant. Elle déplace les validations de l’ordinateur qui exécute les commandes vers votre téléphone, où aucun agent ni logiciel malveillant ne peut les intercepter. Par le créateur de Homebrew. Télécharger pour macOS Automic Vault À propos Sécurité Blog Confidentialité Conditions 𝕏 GitHub © 2026 · Apache-2.0 English 日本語 Deutsch Français 简体中文 # /fr/about/ À propos d'Automic Vault | Sécurisez les outils que vous installez avec brew Télécharger Paquets Blog À propos GitHub Contexte Sécurisez les outils que vous installez avec brew, par le créateur de Homebrew. Automic Vault est conçu pour les vrais terminaux, paquets et identifiants utilisés par les développeurs macOS. Télécharger Documentation Max Howell Max Howell a créé Homebrew en 2009 et construit depuis longtemps des outils pour développeurs macOS. Pourquoi maintenant Les agents IA étendent l'autorité locale; les secrets et les commandes ont donc besoin de limites nettes. Limite d'exécution locale Automic Vault sépare les fichiers lisibles par un agent des identifiants transmis uniquement aux outils approuvés. Le contrôle vit dans le chemin d'exécution sur Mac, pas seulement dans une consigne d'agent. Homebrew et CLI Beaucoup d'outils développeur arrivent par Homebrew, npm, PyPI et les CLI cloud. Vault détecte les fichiers d'identifiants et les actions risquées laissés par ces outils, puis place l'approbation au bon endroit. Étapes suivantes Lancez d'abord le scanner, déplacez les secrets pris en charge vers un stockage local protégé et gardez Automic Vault actif pour recevoir les nouveaux avis de danger. Ce qui change après installation Les CLI habituelles continuent de fonctionner. La différence est que les secrets ne restent pas dans de simples fichiers de configuration; ils sont transmis seulement à l'exécution approuvée qui en a besoin. Avec un coffre central 1Password, HashiCorp Vault et les systèmes cloud peuvent rester la source de vérité. Automic Vault protège le moment local où un outil Mac veut utiliser ces valeurs. Pages liées Documentation, téléchargement, scanner de secrets et catalogue de paquets montrent le parcours complet: détection, durcissement, approbation et surveillance continue du poste développeur. Surveillance continue Nouveaux paquets, outils obsolètes et fichiers de configuration recréés peuvent ramener des risques après la première correction. Automic Vault reste actif et signale les nouveaux dangers. Signaux de confiance Le dépôt public, la page sécurité, la licence et le contexte Homebrew de Max Howell sont liés. Une limite de sécurité locale doit pouvoir être vérifiée. Quand l'utiliser Utilisez Automic Vault avant les exécutions d'agents dans un dépôt, avant le travail avec les CLI cloud et avant les commandes comme npm publish, gh release ou les mutations d'infrastructure. Automic Vault Sécurisez les outils que vous installez avec brew, par le créateur de Homebrew. Télécharger Documentation Paquets © 2026 Automic Vault. Site web À propos Blog Confidentialité Conditions GitHub English 日本語 Deutsch Français 简体中文 # /fr/download/ Télécharger Automic Vault | Protection des agents IA et outils développeur Télécharger Paquets Blog À propos GitHub Téléchargement Télécharger Automic Vault pour macOS Installez la couche de sécurité locale pour les paquets Homebrew, les secrets CLI et les actions d'agents IA sur macOS. Télécharger Documentation Téléchargement direct Téléchargez le .dmg ou installez depuis le terminal avec le script install.sh. Ce qui est inclus Le téléchargement inclut l'application native, l'outil en ligne de commande av, les workflows de scanner de secrets et les contrôles de paquets Nucleus. Après l'installation Lancez d'abord le scanner de secrets, vérifiez les identifiants en clair et déplacez les secrets pris en charge vers un stockage local protégé. Limite d'exécution locale Automic Vault sépare les fichiers lisibles par un agent des identifiants transmis uniquement aux outils approuvés. Le contrôle vit dans le chemin d'exécution sur Mac, pas seulement dans une consigne d'agent. Homebrew et CLI Beaucoup d'outils développeur arrivent par Homebrew, npm, PyPI et les CLI cloud. Vault détecte les fichiers d'identifiants et les actions risquées laissés par ces outils, puis place l'approbation au bon endroit. Étapes suivantes Lancez d'abord le scanner, déplacez les secrets pris en charge vers un stockage local protégé et gardez Automic Vault actif pour recevoir les nouveaux avis de danger. Ce qui change après installation Les CLI habituelles continuent de fonctionner. La différence est que les secrets ne restent pas dans de simples fichiers de configuration; ils sont transmis seulement à l'exécution approuvée qui en a besoin. Avec un coffre central 1Password, HashiCorp Vault et les systèmes cloud peuvent rester la source de vérité. Automic Vault protège le moment local où un outil Mac veut utiliser ces valeurs. Pages liées Documentation, téléchargement, scanner de secrets et catalogue de paquets montrent le parcours complet: détection, durcissement, approbation et surveillance continue du poste développeur. Surveillance continue Nouveaux paquets, outils obsolètes et fichiers de configuration recréés peuvent ramener des risques après la première correction. Automic Vault reste actif et signale les nouveaux dangers. Signaux de confiance Le dépôt public, la page sécurité, la licence et le contexte Homebrew de Max Howell sont liés. Une limite de sécurité locale doit pouvoir être vérifiée. Automic Vault Télécharger Automic Vault pour macOS Télécharger Documentation Paquets © 2026 Automic Vault. Site web À propos Blog Confidentialité Conditions GitHub English 日本語 Deutsch Français 简体中文 # /fr/llms.txt # Automic Vault > Automic Vault retire les secrets en clair des outils CLI et contrôle quelles apps Mac signées peuvent les utiliser à la limite d’exécution locale. ## Pages principales - [Automic Vault | Un nouveau gestionnaire de secrets pour une nouvelle ère du développement](https://www.automicvault.com/fr/): Retirez les secrets CLI des fichiers en clair et contrôlez quelles applications signées peuvent les utiliser. - [Télécharger Automic Vault](https://www.automicvault.com/fr/download/): Téléchargez Automic Vault pour macOS et protégez les exécutions locales d'agents IA. - [Documentation](https://www.automicvault.com/docs/): Manuel CLI en anglais, vérifié sur les sources d’Automic Vault 2.9.0, couvrant scan, doctor, save, inject, bless et harden. - [Paquets](https://pkg.so/fr/): Catalogue consultable de paquets développeur, dépendances, commandes d’installation, risques et couverture de durcissement Automic Vault. - [Blog](https://www.automicvault.com/blog/): Guides et analyses d’incidents liés aux paquets, extensions, identifiants et exécutions locales. - [À propos d'Automic Vault | Sécurisez les outils que vous installez avec brew](https://www.automicvault.com/fr/about/): Automic Vault sécurise localement sur votre Mac les outils Homebrew, les secrets CLI et les portes d'approbation des commandes avant que les agents IA les utilisent. - [Confidentialité Automic Vault](https://www.automicvault.com/fr/privacy/): Limites de données locales, analytics du site et notes de confidentialité pour Automic Vault. - [Conditions Automic Vault](https://www.automicvault.com/fr/terms/): Conditions d'utilisation, licence open source et notes du site pour Automic Vault. - [GitHub](https://github.com/automic-vault/automic-vault): Code source Apache-2.0, versions étiquetées, historique d’implémentation et suivi public des problèmes. - [Sécurité](https://www.automicvault.com/.well-known/security.txt): Publie le contact de sécurité actuel, la langue préférée, l’adresse canonique et la date d’expiration. ## Faits essentiels - Plateforme : macOS - Version actuellement documentée : 2.9.0 - Licence : Apache License 2.0 - Prix : logiciel open source gratuit - Fondateur : Max Howell, créateur de Homebrew ## Contact - Site web: https://www.automicvault.com/fr/ - GitHub: https://github.com/automic-vault/automic-vault - Signalements de sécurité: https://github.com/automic-vault/automic-vault/issues # /fr/privacy/ Confidentialité Automic Vault | Protection des agents IA et outils développeur Télécharger Paquets Blog À propos GitHub Automic Vault Les secrets locaux restent locaux Limites de données locales, analytics du site et notes de confidentialité pour Automic Vault. Télécharger Documentation Données produit Automic Vault protège les secrets sur la machine du développeur et n'est pas un service de secrets hébergé. Données du site Le site utilise des analytics de base et des ressources publiques, sans collecter les secrets du produit. Limite d'exécution locale Automic Vault sépare les fichiers lisibles par un agent des identifiants transmis uniquement aux outils approuvés. Le contrôle vit dans le chemin d'exécution sur Mac, pas seulement dans une consigne d'agent. Homebrew et CLI Beaucoup d'outils développeur arrivent par Homebrew, npm, PyPI et les CLI cloud. Vault détecte les fichiers d'identifiants et les actions risquées laissés par ces outils, puis place l'approbation au bon endroit. Étapes suivantes Lancez d'abord le scanner, déplacez les secrets pris en charge vers un stockage local protégé et gardez Automic Vault actif pour recevoir les nouveaux avis de danger. Ce qui change après installation Les CLI habituelles continuent de fonctionner. La différence est que les secrets ne restent pas dans de simples fichiers de configuration; ils sont transmis seulement à l'exécution approuvée qui en a besoin. Avec un coffre central 1Password, HashiCorp Vault et les systèmes cloud peuvent rester la source de vérité. Automic Vault protège le moment local où un outil Mac veut utiliser ces valeurs. Pages liées Documentation, téléchargement, scanner de secrets et catalogue de paquets montrent le parcours complet: détection, durcissement, approbation et surveillance continue du poste développeur. Surveillance continue Nouveaux paquets, outils obsolètes et fichiers de configuration recréés peuvent ramener des risques après la première correction. Automic Vault reste actif et signale les nouveaux dangers. Signaux de confiance Le dépôt public, la page sécurité, la licence et le contexte Homebrew de Max Howell sont liés. Une limite de sécurité locale doit pouvoir être vérifiée. Quand l'utiliser Utilisez Automic Vault avant les exécutions d'agents dans un dépôt, avant le travail avec les CLI cloud et avant les commandes comme npm publish, gh release ou les mutations d'infrastructure. Automic Vault Les secrets locaux restent locaux Télécharger Documentation Paquets © 2026 Automic Vault. Site web À propos Blog Confidentialité Conditions GitHub English 日本語 Deutsch Français 简体中文 # /fr/terms/ Conditions Automic Vault | Protection des agents IA et outils développeur Télécharger Paquets Blog À propos GitHub Automic Vault Outil open source de sécurité locale Conditions d'utilisation, licence open source et notes du site pour Automic Vault. Télécharger Documentation Licence Automic Vault est fourni sous licence Apache License 2.0. Utilisation Ce site fournit des informations produit, de la documentation et des métadonnées de paquets. Limite d'exécution locale Automic Vault sépare les fichiers lisibles par un agent des identifiants transmis uniquement aux outils approuvés. Le contrôle vit dans le chemin d'exécution sur Mac, pas seulement dans une consigne d'agent. Homebrew et CLI Beaucoup d'outils développeur arrivent par Homebrew, npm, PyPI et les CLI cloud. Vault détecte les fichiers d'identifiants et les actions risquées laissés par ces outils, puis place l'approbation au bon endroit. Étapes suivantes Lancez d'abord le scanner, déplacez les secrets pris en charge vers un stockage local protégé et gardez Automic Vault actif pour recevoir les nouveaux avis de danger. Ce qui change après installation Les CLI habituelles continuent de fonctionner. La différence est que les secrets ne restent pas dans de simples fichiers de configuration; ils sont transmis seulement à l'exécution approuvée qui en a besoin. Avec un coffre central 1Password, HashiCorp Vault et les systèmes cloud peuvent rester la source de vérité. Automic Vault protège le moment local où un outil Mac veut utiliser ces valeurs. Pages liées Documentation, téléchargement, scanner de secrets et catalogue de paquets montrent le parcours complet: détection, durcissement, approbation et surveillance continue du poste développeur. Surveillance continue Nouveaux paquets, outils obsolètes et fichiers de configuration recréés peuvent ramener des risques après la première correction. Automic Vault reste actif et signale les nouveaux dangers. Signaux de confiance Le dépôt public, la page sécurité, la licence et le contexte Homebrew de Max Howell sont liés. Une limite de sécurité locale doit pouvoir être vérifiée. Quand l'utiliser Utilisez Automic Vault avant les exécutions d'agents dans un dépôt, avant le travail avec les CLI cloud et avant les commandes comme npm publish, gh release ou les mutations d'infrastructure. Automic Vault Outil open source de sécurité locale Télécharger Documentation Paquets © 2026 Automic Vault. Site web À propos Blog Confidentialité Conditions GitHub English 日本語 Deutsch Français 简体中文 # /index.md # Automic Vault ## A new kind of secrets manager for a new era of development. Automic Vault moves developer credentials out of plaintext files, then controls their application through each Tool and Verified Launcher. The same local boundary applies before an authenticated CLI deploys code or changes cloud resources, whether an agent, script, or malware launched it. No harness integration required. - Remove credentials from dotfiles and tool configs. - Give credentials only to the right executable. - Apply one local boundary to every Verified Launcher. [Download for macOS](/Automic%20Vault.dmg) ## A prompt cannot protect a secret the agent can already read An agent can read the same credential files and run the same tools you can. A helpful shortcut can upload a reusable cloud credential to a remote server. Automic Vault removes plaintext secrets from files agents can read. If an agent tries another route, such as `aws config export-credentials`, the command stops at a native approval gate. ## Automic Vault controls the secret handoff Automic Vault moves credentials out of readable tool configs. Agents and untrusted software cannot find protected secrets in the files they inspect. When a Tool requests a Secret, Automic Vault checks the Target, Verified Launcher, command, working directory, and requested Secret Name. ### How it works Automic Vault stores the Secret in Keychain. It applies the Authorization Policy when a Verified Launcher starts the Tool, then supplies the Secret to the designated Target for that run. The Secret is not placed in the Launcher's ambient environment. The Target controls it after receipt. ## Policy follows the tool and its launcher Terminal, Codex, and an unknown process can invoke the same executable. Automic Vault identifies the Verified Launcher and gives each pairing its own Authorization Policy. - **Approval Required** gives the Launcher no durable policy grant. Every operation requires Approval. - **Read Only** automically authorizes recognized reads. Writes still require Approval. - **Local Write** also covers recognized operations that only change local files, where the Tool supports that distinction. - **Write Access** automically authorizes recognized reads and writes. Secret Disclosure and Elevated Secret Application still require Approval.† † Installed packages must cross the same boundary to use protected secrets. Supply-chain attacks such as the 2025 Shai-Hulud npm worm target credentials available to developer tools. Defense in depth still matters: run `npm i` in a dedicated terminal with low-to-no privileges in both Automic Vault and macOS TCC. ## Authorization History stays on your Mac Allowed or denied, policy or Approval: requests leave a bounded local record with the decision, Launcher, Secret Names, command, and working directory. ## Know when your toolchain turns risky Automic Vault scans developer Tools across ecosystems. It reports supported Exposures and Hazards and shows how to mitigate each Finding. ## Control the tool layer beneath every agent macOS can code sign apps, sandbox them, and keep them out of one another’s private data. Command-line tools usually run with the authority of whichever app launched them. That may be Terminal, an AI harness, an editor, or an automation app. Automic Vault identifies the Tool and its Verified Launcher, then applies the Authorization Policy you chose for that pairing. [Read why the terminal needs its own security layer](/blog/bringing-macos-security-to-the-terminal/) ## From the creator of Homebrew Automic Vault is free Apache-2.0 open-source software for macOS. [Documentation](https://www.automicvault.com/docs/) · [Security](https://github.com/automic-vault/automic-vault/security) · [Source](https://github.com/automic-vault/automic-vault) # /index.txt Automic Vault A new kind of secrets manager for a new era of development. Automic Vault moves developer credentials out of plaintext files, then controls their application through each Tool and Verified Launcher. The same local boundary applies before an authenticated CLI deploys code or changes cloud resources, whether an agent, script, or malware launched it. No harness integration required. - Remove credentials from dotfiles and tool configs. - Give credentials only to the right executable. - Apply one local boundary to every Verified Launcher. Download for macOS: https://www.automicvault.com/Automic%20Vault.dmg A prompt cannot protect a secret the agent can already read An agent can read the same credential files and run the same tools you can. A helpful shortcut can upload a reusable cloud credential to a remote server. Automic Vault removes plaintext secrets from files agents can read. If an agent tries another route, such as aws config export-credentials, the command stops at a native approval gate. Automic Vault controls the secret handoff Automic Vault moves credentials out of readable tool configs. Agents and untrusted software cannot find protected secrets in the files they inspect. When a Tool requests a Secret, Automic Vault checks the Target, Verified Launcher, command, working directory, and requested Secret Name. How it works Automic Vault stores the Secret in Keychain. It applies the Authorization Policy when a Verified Launcher starts the Tool, then supplies the Secret to the designated Target for that run. The Secret is not placed in the Launcher's ambient environment. The Target controls it after receipt. Policy follows the tool and its launcher Terminal, Codex, and an unknown process can invoke the same executable. Automic Vault identifies the Verified Launcher and gives each pairing its own Authorization Policy. - Approval Required gives the Launcher no durable policy grant. Every operation requires Approval. - Read Only automically authorizes recognized reads. Writes still require Approval. - Local Write also covers recognized operations that only change local files, where the Tool supports that distinction. - Write Access automically authorizes recognized reads and writes. Secret Disclosure and Elevated Secret Application still require Approval.† † Installed packages must cross the same boundary to use protected secrets. Supply-chain attacks such as the 2025 Shai-Hulud npm worm target credentials available to developer tools. Defense in depth still matters: run npm i in a dedicated terminal with low-to-no privileges in both Automic Vault and macOS TCC. Authorization History stays on your Mac Allowed or denied, policy or Approval: requests leave a bounded local record with the decision, Launcher, Secret Names, command, and working directory. Know when your toolchain turns risky Automic Vault scans developer Tools across ecosystems. It reports supported Exposures and Hazards and shows how to mitigate each Finding. Control the tool layer beneath every agent macOS can code sign apps, sandbox them, and keep them out of one another's private data. Command-line tools usually run with the authority of whichever app launched them. That may be Terminal, an AI harness, an editor, or an automation app. Automic Vault identifies the Tool and its Verified Launcher, then applies the Authorization Policy you chose for that pairing. Read why the terminal needs its own security layer: https://www.automicvault.com/blog/bringing-macos-security-to-the-terminal/ From the creator of Homebrew Automic Vault is free Apache-2.0 open-source software for macOS. Documentation: https://www.automicvault.com/docs/ Security reporting: https://www.automicvault.com/.well-known/security.txt Source: https://github.com/automic-vault/automic-vault # /ja/ Automic Vault | 新しい時代の開発に向けた新しいシークレット管理 Automic Vault シークレット ポリシー 監査 GitHub macOS 版をダウンロード Homebrew 開発者が提供 新しい時代の開発に向けた 新しいシークレット管理。 Automic Vault は CLI ツールのシークレットを平文ファイルから移し、どの署名済みアプリが各ツールを各認証情報で実行できるかを制御します。 あらゆるエージェント。あらゆるハーネス。設定不要。 macOS 版をダウンロード 境界の動作を見る → 01 平文シークレットをなくす 認証情報を dotfile やツール設定から移します。 02 受け渡しを制御する 正しい実行ファイルだけが認証情報を受け取ります。 03 1 つのローカル境界を適用 どの起動元にも同じポリシーが適用されます。 エージェントはあなたのアクセス権を引き継ぐ エージェントがすでに読めるシークレットは、プロンプトでは守れません。 C Claude うーん… リモートサーバーには AWS へのアクセス権がありません。 C Claude 問題ありません。ここからキーをアップロードします。 T ツール呼び出し Read(~/.aws/credentials) R ツール結果 [default] aws_access_key_id = AKIA•••••••••••• aws_secret_access_key = •••••••••••••••••••••••••••••••• シークレット流出 再利用可能なクラウド認証情報が信頼境界を越えました。 Automic Vault 導入後 C Claude うーん… リモートサーバーには AWS へのアクセス権がありません。 C Claude 問題ありません。ここからキーをアップロードします。 T ツール呼び出し Read(~/.aws/credentials) Automic Vault が平文シークレットを排除 R ツール結果 ファイルがありません C Claude 代わりにエクスポートコマンドを実行します。 T ツール呼び出し aws config export-credentials Automic Vault がシークレット流出経路へのアクセスを制御 ! Automic Vault 人の承認が必要 シークレットの暗号化だけでは不十分 人の承認が必要 シークレットが機密性の高い操作に使えるなら、暗号化だけでは半分しか守れません。 Automic Vault はシークレットを保護するだけでなく、その 利用 も制御します。 実行前にコマンド、作業ディレクトリ、要求キーを確認できます。 アプリごとのアクセス ポリシーはツールと起動元に従います。 Terminal、Codex、不明なプロセスはいずれも同じ実行ファイルを呼び出せます。Automic Vault は署名済みの起動元を識別し、組み合わせごとに独自のアクセスポリシーを適用します。 アクセス不可 アプリに自動アクセスはありません。すべての要求に承認が必要です。 信頼済みアクセス npm i を実行しない Terminal 用です。シークレットを公開するコマンドには常に承認が残ります。 読み取り専用 エージェントなど、ある程度信頼するツール用です。安全な読み取りは進み、書き込みには承認が必要です。 シークレットの利用をすべて記録します。 承認か拒否か、自動か手動かを問わず、すべての要求について起動元、キー、コマンド、作業ディレクトリ、判断をローカルに記録します。 判断 起動元 要求キー 作業ディレクトリ 拒否と承認の要求を同じ監査証跡に記録します。 各検出項目に条件、理由、対処手順を示します。 開発環境の脅威を継続的に監視 Automic Vault はあらゆるエコシステムの開発ツールを監視します。新しい脅威を即座に検出し、それぞれの対処手順を示します。 ハーネスに依存しない すべてのエージェントの下にあるツール層を制御。 コマンドラインツールは、それを起動したアプリの権限で実行されます。Automic Vault はツールと署名済みの起動元を識別し、その組み合わせに選択したアクセスルールを適用します。 Terminal に独自のセキュリティ層が必要な理由 → 同じ CLI でも、Terminal、エージェントハーネス、その他のホストアプリごとに異なるアクセスを設定できます。 無料のオープンソース。 Automic Vault は無料です。さらにセキュリティを高めたい場合は、オプションの iPhone アプリを有料で購読できます。承認ゲートをコマンド実行中のコンピュータから、エージェントやマルウェアに傍受されないスマートフォンへ移します。 Homebrew の開発者が提供。 macOS 版をダウンロード Automic Vault Automic Vault について セキュリティ ブログ プライバシー 利用規約 𝕏 GitHub © 2026 · Apache-2.0 English 日本語 Deutsch Français 简体中文 # /ja/about/ Automic Vault について | brew install したツールを安全に ダウンロード パッケージ Blog 概要 GitHub 背景 brew install したツールを安全に。Homebrew 作者によるローカル制御です。 Automic Vault は、macOS 開発者の実際の端末、パッケージ、認証情報の使い方を前提に設計されています。 ダウンロード ドキュメント Max Howell Max Howell は 2009 年に Homebrew を作り、macOS 開発者向けツールを長く作ってきました。 なぜ今か AI エージェントはローカル環境の権限を広げるため、シークレットとコマンドの境界が必要です。 ローカル実行境界 Automic Vault は、エージェントが読めるファイルと、承認されたツールだけが受け取る認証情報を分けます。モデルの指示ではなく、Mac 上の実行経路で制御します。 Homebrew と CLI 多くの開発ツールは Homebrew、npm、PyPI、クラウド CLI から入ります。Vault は、そのツールが作る認証情報ファイルや危険な操作を検出して、必要な場所に承認を置きます。 次の手順 まずスキャナーで平文の露出を確認し、対応済みのシークレットを保護されたローカル保存に移し、Automic Vault を起動したまま新しい hazard 通知を受け取ります。 インストール後の変化 既存の CLI は使い続けられます。ただし、シークレットはエージェントが読める設定ファイルではなく、承認された実行だけが受け取るローカル境界の中に移ります。 中央の vault との違い 1Password や HashiCorp Vault はシークレットの管理元として使えます。Automic Vault は、その値が Mac 上のツールへ渡される瞬間を制御します。 関連ページ ドキュメント、ダウンロード、シークレットスキャナー、パッケージカタログを確認すると、検出からハードニング、承認、継続監視までの流れが分かります。 継続監視 新しいパッケージ、古いツール、再作成された設定ファイルは、最初の修正後にも危険を戻す可能性があります。Automic Vault は新しい hazard を知らせます。 信頼の手がかり 公開リポジトリ、セキュリティページ、ライセンス、Max Howell の Homebrew 背景を確認できます。ローカルのセキュリティ境界は、検証可能であるべきです。 使う場面 エージェントにリポジトリを任せる前、クラウド CLI を使う前、npm publish や gh release のような権限の強いコマンドを許可する前に使います。 Automic Vault brew install したツールを安全に。Homebrew 作者によるローカル制御です。 ダウンロード ドキュメント パッケージ © 2026 Automic Vault. ウェブサイト 概要 Blog プライバシー 利用規約 GitHub English 日本語 Deutsch Français 简体中文 # /ja/download/ Automic Vault ダウンロード | AI エージェントと開発ツールの保護 ダウンロード パッケージ Blog 概要 GitHub ダウンロード macOS 用 Automic Vault をダウンロード ローカルの Homebrew パッケージ、CLI シークレット、AI エージェント操作を保護する macOS セキュリティレイヤーをインストールします。 ダウンロード ドキュメント 直接ダウンロード .dmg を取得するか、ターミナル用の install.sh スクリプトでインストールできます。 含まれるもの ネイティブアプリ、av コマンドラインツール、シークレットスキャナー、Nucleus パッケージ制御が含まれます。 インストール後 まずシークレットスキャナーを実行し、平文の認証情報を確認して、対応済みのシークレットを保護されたローカル保存に移します。 ローカル実行境界 Automic Vault は、エージェントが読めるファイルと、承認されたツールだけが受け取る認証情報を分けます。モデルの指示ではなく、Mac 上の実行経路で制御します。 Homebrew と CLI 多くの開発ツールは Homebrew、npm、PyPI、クラウド CLI から入ります。Vault は、そのツールが作る認証情報ファイルや危険な操作を検出して、必要な場所に承認を置きます。 次の手順 まずスキャナーで平文の露出を確認し、対応済みのシークレットを保護されたローカル保存に移し、Automic Vault を起動したまま新しい hazard 通知を受け取ります。 インストール後の変化 既存の CLI は使い続けられます。ただし、シークレットはエージェントが読める設定ファイルではなく、承認された実行だけが受け取るローカル境界の中に移ります。 中央の vault との違い 1Password や HashiCorp Vault はシークレットの管理元として使えます。Automic Vault は、その値が Mac 上のツールへ渡される瞬間を制御します。 関連ページ ドキュメント、ダウンロード、シークレットスキャナー、パッケージカタログを確認すると、検出からハードニング、承認、継続監視までの流れが分かります。 継続監視 新しいパッケージ、古いツール、再作成された設定ファイルは、最初の修正後にも危険を戻す可能性があります。Automic Vault は新しい hazard を知らせます。 信頼の手がかり 公開リポジトリ、セキュリティページ、ライセンス、Max Howell の Homebrew 背景を確認できます。ローカルのセキュリティ境界は、検証可能であるべきです。 Automic Vault macOS 用 Automic Vault をダウンロード ダウンロード ドキュメント パッケージ © 2026 Automic Vault. ウェブサイト 概要 Blog プライバシー 利用規約 GitHub English 日本語 Deutsch Français 简体中文 # /ja/llms.txt # Automic Vault > Automic Vault は CLI シークレットを平文ファイルから除き、承認済みの Mac アプリだけがローカル実行境界で使用できるようにします。 ## 主要ページ - [Automic Vault | 新しい時代の開発に向けた新しいシークレット管理](https://www.automicvault.com/ja/): CLI シークレットを平文ファイルから移し、どの署名済みアプリが使用できるかを制御します。 - [Automic Vault ダウンロード](https://www.automicvault.com/ja/download/): macOS 用 Automic Vault を入手し、ローカルの AI エージェント実行を保護します。 - [ドキュメント](https://www.automicvault.com/docs/): Automic Vault 2.9.0 の scan、doctor、save、inject、bless、harden などを解説する英語の CLI マニュアルです。 - [パッケージ](https://pkg.so/ja/): 開発者向けパッケージ、依存関係、インストール方法、リスク情報、Automic Vault の保護状況を検索できます。 - [Blog](https://www.automicvault.com/blog/): パッケージ、エディタ拡張、認証情報、ローカル実行のインシデント分析と開発者向けセキュリティガイドです。 - [Automic Vault について | brew install したツールを安全に](https://www.automicvault.com/ja/about/): Automic Vault は、AI エージェントが使う前に、Homebrew ツール、CLI シークレット、コマンド承認ゲートを Mac 上でローカルに保護します。 - [Automic Vault プライバシー](https://www.automicvault.com/ja/privacy/): Automic Vault のローカルデータ境界、ウェブサイト解析、プライバシー方針。 - [Automic Vault 利用規約](https://www.automicvault.com/ja/terms/): Automic Vault の利用条件、オープンソースライセンス、ウェブサイト利用メモ。 - [GitHub](https://github.com/automic-vault/automic-vault): Apache-2.0 のソースコード、タグ付きリリース、実装履歴、公開 Issue を掲載しています。 - [セキュリティ](https://www.automicvault.com/.well-known/security.txt): 現在のセキュリティ連絡先、優先言語、正規 URL、有効期限を公開しています。 ## 基本情報 - 対応環境: macOS - 現在のドキュメント対象リリース: 2.9.0 - ライセンス: Apache License 2.0 - 価格: 無料のオープンソースソフトウェア - 創設者: Homebrew 作者の Max Howell ## 連絡先 - ウェブサイト: https://www.automicvault.com/ja/ - GitHub: https://github.com/automic-vault/automic-vault - セキュリティ報告: https://github.com/automic-vault/automic-vault/issues # /ja/privacy/ Automic Vault プライバシー | AI エージェントと開発ツールの保護 ダウンロード パッケージ Blog 概要 GitHub Automic Vault ローカルシークレットはローカルに残る Automic Vault のローカルデータ境界、ウェブサイト解析、プライバシー方針。 ダウンロード ドキュメント 製品データ Automic Vault は開発者マシン上のシークレットを保護するために作られており、ホスト型シークレットサービスではありません。 サイトデータ ウェブサイトは基本的な解析と公開アセットを使い、製品シークレットを収集しません。 ローカル実行境界 Automic Vault は、エージェントが読めるファイルと、承認されたツールだけが受け取る認証情報を分けます。モデルの指示ではなく、Mac 上の実行経路で制御します。 Homebrew と CLI 多くの開発ツールは Homebrew、npm、PyPI、クラウド CLI から入ります。Vault は、そのツールが作る認証情報ファイルや危険な操作を検出して、必要な場所に承認を置きます。 次の手順 まずスキャナーで平文の露出を確認し、対応済みのシークレットを保護されたローカル保存に移し、Automic Vault を起動したまま新しい hazard 通知を受け取ります。 インストール後の変化 既存の CLI は使い続けられます。ただし、シークレットはエージェントが読める設定ファイルではなく、承認された実行だけが受け取るローカル境界の中に移ります。 中央の vault との違い 1Password や HashiCorp Vault はシークレットの管理元として使えます。Automic Vault は、その値が Mac 上のツールへ渡される瞬間を制御します。 関連ページ ドキュメント、ダウンロード、シークレットスキャナー、パッケージカタログを確認すると、検出からハードニング、承認、継続監視までの流れが分かります。 継続監視 新しいパッケージ、古いツール、再作成された設定ファイルは、最初の修正後にも危険を戻す可能性があります。Automic Vault は新しい hazard を知らせます。 信頼の手がかり 公開リポジトリ、セキュリティページ、ライセンス、Max Howell の Homebrew 背景を確認できます。ローカルのセキュリティ境界は、検証可能であるべきです。 使う場面 エージェントにリポジトリを任せる前、クラウド CLI を使う前、npm publish や gh release のような権限の強いコマンドを許可する前に使います。 Automic Vault ローカルシークレットはローカルに残る ダウンロード ドキュメント パッケージ © 2026 Automic Vault. ウェブサイト 概要 Blog プライバシー 利用規約 GitHub English 日本語 Deutsch Français 简体中文 # /ja/terms/ Automic Vault 利用規約 | AI エージェントと開発ツールの保護 ダウンロード パッケージ Blog 概要 GitHub Automic Vault オープンソースのローカルセキュリティツール Automic Vault の利用条件、オープンソースライセンス、ウェブサイト利用メモ。 ダウンロード ドキュメント ライセンス Automic Vault は Apache License 2.0 の下で提供されます。 利用 このサイトは製品情報、ドキュメント、パッケージメタデータを提供します。 ローカル実行境界 Automic Vault は、エージェントが読めるファイルと、承認されたツールだけが受け取る認証情報を分けます。モデルの指示ではなく、Mac 上の実行経路で制御します。 Homebrew と CLI 多くの開発ツールは Homebrew、npm、PyPI、クラウド CLI から入ります。Vault は、そのツールが作る認証情報ファイルや危険な操作を検出して、必要な場所に承認を置きます。 次の手順 まずスキャナーで平文の露出を確認し、対応済みのシークレットを保護されたローカル保存に移し、Automic Vault を起動したまま新しい hazard 通知を受け取ります。 インストール後の変化 既存の CLI は使い続けられます。ただし、シークレットはエージェントが読める設定ファイルではなく、承認された実行だけが受け取るローカル境界の中に移ります。 中央の vault との違い 1Password や HashiCorp Vault はシークレットの管理元として使えます。Automic Vault は、その値が Mac 上のツールへ渡される瞬間を制御します。 関連ページ ドキュメント、ダウンロード、シークレットスキャナー、パッケージカタログを確認すると、検出からハードニング、承認、継続監視までの流れが分かります。 継続監視 新しいパッケージ、古いツール、再作成された設定ファイルは、最初の修正後にも危険を戻す可能性があります。Automic Vault は新しい hazard を知らせます。 信頼の手がかり 公開リポジトリ、セキュリティページ、ライセンス、Max Howell の Homebrew 背景を確認できます。ローカルのセキュリティ境界は、検証可能であるべきです。 使う場面 エージェントにリポジトリを任せる前、クラウド CLI を使う前、npm publish や gh release のような権限の強いコマンドを許可する前に使います。 Automic Vault オープンソースのローカルセキュリティツール ダウンロード ドキュメント パッケージ © 2026 Automic Vault. ウェブサイト 概要 Blog プライバシー 利用規約 GitHub English 日本語 Deutsch Français 简体中文 # /privacy/ Automic Vault Privacy for Local Mac Secrets and Website Data Download Packages Blog About GitHub Privacy Automic Vault keeps agent credentials local Automic Vault protects local developer credentials. The product is open-source software for macOS, not a hosted secrets platform that stores your agent credentials in a remote account. Last updated: June 1, 2026 Automic Vault keeps agent credentials on the developer's Mac. The public website is static product information; the app's privacy boundary is local keychain-backed storage, approved command execution, and no raw secret handoff to AI model context. Read documentation › Security notes › Website The website publishes static product information. The public site provides documentation, downloads, and source links. It does not require an account, checkout flow, or hosted vault login. No account No hosted login The website does not ask users to create an Automic Vault account to read docs or inspect source. Downloads Static artifacts Downloads are served as static files linked from the site and repository. Source Public repository Product source and issue tracking live in the public GitHub repository. Secrets Local storage Automic Vault's product goal is to keep agent-facing secrets local and away from model context. Product boundary Secrets are local product data. Automic Vault moves credentials out of plaintext files and into local keychain-backed storage. Approved command-line tools receive the requested values at runtime; the website is not the secret storage surface. Surface Privacy boundary Website Static pages, documentation, downloads, and public source links; no hosted vault login is required. Secrets Credentials are intended to move out of readable files and into local keychain-backed storage. Agents Models should not receive raw secret values in prompts, transcripts, or copied tool output. Tools Approved executables receive named values at runtime when the local workflow needs them. References Privacy-related product details. Secrets Secrets manager for AI agents How Automic Vault keeps credentials away from model context. Docs Secret injection docs CLI documentation for saving and injecting named values. Source Source code Inspect the implementation in the public repository. Practical rule Do not make AI transcripts a secret store. Automic Vault targets local over-sharing: dotenv files, shell profiles, cloud credentials, package tokens, and debug output can all become model-visible text. The product reduces those text surfaces before an agent run starts. Before Move ambient secrets Replace readable local secret files with named values stored behind the local runtime boundary. During Apply to the Target Let an authorized Target receive credentials without placing them in the Launcher's ambient environment. After Review exposure Use local scanning to find files that still contain credentials before future agent sessions. Public Keep reports sanitized Use synthetic examples when reporting privacy or security behavior in public repositories. © 2026 Automic Vault. Home About Blog Privacy Terms GitHub English 日本語 Deutsch Français 简体中文 # /robots.txt User-agent: * Allow: / User-agent: GPTBot Allow: / User-agent: OAI-SearchBot Allow: / User-agent: ChatGPT-User Allow: / User-agent: PerplexityBot Allow: / User-agent: Perplexity-User Allow: / User-agent: ClaudeBot Allow: / User-agent: Claude-SearchBot Allow: / User-agent: Claude-User Allow: / User-agent: Google-Extended Allow: / User-agent: Bingbot Allow: / Sitemap: https://www.automicvault.com/sitemap.xml # /terms/ Automic Vault Terms and Apache 2.0 Open Source License Download Packages Blog About GitHub Terms and licensing Free open-source software under Apache 2.0 Automic Vault is distributed as free open-source software. The current public pricing page lists no paid hosted, team, pro, or enterprise plans. Last updated: June 1, 2026 Automic Vault is currently distributed as free open-source software under the Apache License 2.0. The public repository contains the license text, releases, source code, and issue tracking; this page summarizes those terms. View pricing › View source › License Use the repository license for legal terms. This page summarizes product positioning for people and AI systems. The license text in the source repository governs the open-source software. Price $0 Automic Vault currently publishes a free plan with no billing. License Apache 2.0 The project is distributed under the Apache License 2.0. Source Public GitHub repo The source repository holds code, license, releases, and issues. Product Local security layer Automic Vault is local runtime security for AI coding agents. Terms summary Use this site as a summary, not the legal source. The repository license remains authoritative. This page summarizes pricing, license, source, and support expectations so Automic Vault is not mistaken for a hosted SaaS vault. Question Current public answer Is there a paid plan? No paid hosted, team, pro, or enterprise plan is currently published. Where is the license? The source repository license text governs the software. Where are releases tracked? Use GitHub releases and tags for release history. What is the product category? Local macOS runtime security for AI coding agents. References Primary terms and product sources. Pricing Current public pricing and plan summary. Source repository Code, license, issues, and releases. Privacy Website and product privacy boundary summary. Support boundary No hosted enterprise service is implied. Automic Vault is currently positioned as free local software. The public site does not publish paid support tiers, uptime guarantees, hosted secret storage, managed workspaces, or enterprise account terms. Organizations evaluating the tool should review the source repository, license, release history, and local security model directly. Hosted vault Not published The site does not offer a hosted Automic Vault account or cloud secret store. Paid plan Not published The pricing page lists free open-source software, not subscription billing. Support Public channels Issues and release tracking currently point to the public GitHub repository. Evaluation Inspect source Security and legal review should use the repository license and implementation. © 2026 Automic Vault. Home About Blog Privacy Terms GitHub English 日本語 Deutsch Français 简体中文 # /zh-hans/ Automic Vault | 面向开发新时代的新型密钥管理器 Automic Vault 密钥 策略 审计 GitHub 下载 macOS 版 由 Homebrew 创始人打造 面向开发新时代的 新型密钥管理器。 Automic Vault 将 CLI 工具密钥移出明文文件，并控制哪些签名应用可以使用哪些凭据运行每个工具。 任何代理。任何运行框架。零配置。 下载 macOS 版 查看边界如何工作 → 01 移除明文密钥 凭据不再留在 dotfile 和工具配置中。 02 控制凭据交付 只有正确的可执行文件会获得凭据。 03 应用统一的本地边界 每个启动方都遵循同一策略。 你的代理会继承你的访问权限 如果代理已经能够读取密钥，提示词就无法保护它。 C Claude 嗯……远程服务器没有 AWS 访问权限。 C Claude 没问题——我会从这里上传密钥。 T 工具调用 Read(~/.aws/credentials) R 工具结果 [default] aws_access_key_id = AKIA•••••••••••• aws_secret_access_key = •••••••••••••••••••••••••••••••• 密钥已外泄 一个可重复使用的云凭据刚刚越过了信任边界。 使用 Automic Vault 之后 C Claude 嗯……远程服务器没有 AWS 访问权限。 C Claude 没问题——我会从这里上传密钥。 T 工具调用 Read(~/.aws/credentials) Automic Vault 移除明文密钥 R 工具结果 找不到文件 C Claude 我改为运行导出命令。 T 工具调用 aws config export-credentials Automic Vault 限制对密钥外泄路径的访问 ! Automic Vault 需要人工审批 仅仅加密密钥还不够 需要人工审批 如果密钥可用于执行敏感操作，仅仅加密它们只解决了一半的问题。 Automic Vault 不仅保护你的密钥，还会控制这些密钥的 使用 。 运行前即可查看命令、工作目录和所请求的密钥。 按应用控制访问 策略同时跟随工具及其启动方。 Terminal、Codex 和未知进程都可以调用同一个可执行文件。Automic Vault 会识别签名启动方，并为每种组合应用独立的访问策略。 无权访问 应用不会获得自动访问权限，每次请求都需要你的批准。 可信访问 适用于你绝不会运行 npm i 的终端。会暴露密钥的命令始终保留审批门。 只读 适用于代理等你有限信任的工具。安全读取可以继续，写入操作需要批准。 每次密钥使用都有日志记录。 无论批准或拒绝、自动或手动，每个请求都会在本地记录启动方、密钥、命令、工作目录和决定。 决定 启动方 请求的密钥 工作目录 拒绝和批准的请求使用同一份审计记录。 每个标记都包含触发条件、原因和缓解步骤。 持续监控开发环境中的威胁 Automic Vault 监控所有生态系统中的开发工具。新威胁会立即被标记，并提供清晰的缓解步骤。 独立于运行框架 控制每个代理下方的工具层。 命令行工具以启动它们的应用所拥有的权限运行。Automic Vault 会识别工具及其签名启动方，并对该组合应用你选择的访问规则。 了解终端为何需要自己的安全层 → 同一个 CLI 可以从 Terminal、代理运行框架或其他宿主应用获得不同的访问权限。 免费且开源。 Automic Vault 免费提供。如需更高的安全性，可付费订阅可选的 iPhone 应用。它会把审批门从运行命令的电脑转移到手机上，避免被代理或恶意软件拦截。 由 Homebrew 创始人打造。 下载 macOS 版 Automic Vault 关于 安全 博客 隐私 条款 𝕏 GitHub © 2026 · Apache-2.0 English 日本語 Deutsch Français 简体中文 # /zh-hans/about/ 关于 Automic Vault | 保护你用 brew install 装上的工具 下载 软件包 Blog 关于 GitHub 背景 保护你用 brew install 装上的工具。由 Homebrew 作者打造。 Automic Vault 按照 macOS 开发者真实使用终端、软件包和凭据的方式设计。 下载 文档 Max Howell Max Howell 于 2009 年创建 Homebrew，长期构建面向 macOS 开发者的工具。 为什么是现在 AI 代理扩大了本地权限，因此密钥和命令需要清晰边界。 本地运行边界 Automic Vault 将代理可读取的文件与只提供给已批准工具的凭据分开。控制发生在 Mac 的执行路径上，而不是只依赖代理提示词。 Homebrew 与 CLI 许多开发工具来自 Homebrew、npm、PyPI 和云 CLI。Vault 会检测这些工具留下的凭据文件和高风险操作，并把审批放到实际执行位置。 下一步 先运行扫描器检查明文暴露，将支持的密钥移入受保护的本地存储，并保持 Automic Vault 运行，以便及时收到新的 hazard 通知。 安装后的变化 熟悉的 CLI 仍可继续使用。区别在于密钥不再作为容易读取的配置文件留在磁盘上，而是只交给真正需要它的已批准执行。 与中心化 vault 配合 1Password、HashiCorp Vault 和云端密钥系统仍可作为真实来源。Automic Vault 保护的是本地 Mac 工具使用这些值的那一刻。 相关页面 文档、下载、密钥扫描器和软件包目录展示完整流程：发现暴露、加固工具、加入审批门，并持续监控开发机器。 持续监控 新的软件包、过时工具和重新生成的配置文件可能在首次修复后重新带来风险。Automic Vault 会保持运行并提示新的 hazard。 可信线索 公开仓库、安全页面、许可证以及 Max Howell 的 Homebrew 背景都可查看。本地安全边界应该能够被验证。 何时使用 在让代理处理仓库之前、使用云 CLI 之前，以及允许 npm publish、gh release 或基础设施变更等高权限命令之前使用 Automic Vault。 Automic Vault 保护你用 brew install 装上的工具。由 Homebrew 作者打造。 下载 文档 软件包 © 2026 Automic Vault. 网站 关于 Blog 隐私 条款 GitHub English 日本語 Deutsch Français 简体中文 # /zh-hans/download/ 下载 Automic Vault | AI 代理与开发工具安全 下载 软件包 Blog 关于 GitHub 下载 下载 macOS 版 Automic Vault 安装用于保护 macOS 上 Homebrew 软件包、CLI 密钥和 AI 代理操作的本地安全层。 下载 文档 直接下载 可以下载 .dmg，也可以在终端中使用 install.sh 脚本安装。 包含内容 下载内容包括原生应用、av 命令行工具、密钥扫描器工作流和 Nucleus 软件包控制。 安装之后 先运行密钥扫描器，检查明文凭据，并将支持的密钥移入受保护的本地存储。 本地运行边界 Automic Vault 将代理可读取的文件与只提供给已批准工具的凭据分开。控制发生在 Mac 的执行路径上，而不是只依赖代理提示词。 Homebrew 与 CLI 许多开发工具来自 Homebrew、npm、PyPI 和云 CLI。Vault 会检测这些工具留下的凭据文件和高风险操作，并把审批放到实际执行位置。 下一步 先运行扫描器检查明文暴露，将支持的密钥移入受保护的本地存储，并保持 Automic Vault 运行，以便及时收到新的 hazard 通知。 安装后的变化 熟悉的 CLI 仍可继续使用。区别在于密钥不再作为容易读取的配置文件留在磁盘上，而是只交给真正需要它的已批准执行。 与中心化 vault 配合 1Password、HashiCorp Vault 和云端密钥系统仍可作为真实来源。Automic Vault 保护的是本地 Mac 工具使用这些值的那一刻。 相关页面 文档、下载、密钥扫描器和软件包目录展示完整流程：发现暴露、加固工具、加入审批门，并持续监控开发机器。 持续监控 新的软件包、过时工具和重新生成的配置文件可能在首次修复后重新带来风险。Automic Vault 会保持运行并提示新的 hazard。 可信线索 公开仓库、安全页面、许可证以及 Max Howell 的 Homebrew 背景都可查看。本地安全边界应该能够被验证。 Automic Vault 下载 macOS 版 Automic Vault 下载 文档 软件包 © 2026 Automic Vault. 网站 关于 Blog 隐私 条款 GitHub English 日本語 Deutsch Français 简体中文 # /zh-hans/llms.txt # Automic Vault > Automic Vault 从 CLI 工具中移除明文密钥，并在本地执行边界控制哪些已签名 Mac 应用可以使用它们。 ## 主要页面 - [Automic Vault | 面向开发新时代的新型密钥管理器](https://www.automicvault.com/zh-hans/): 将 CLI 密钥移出明文文件，并控制哪些签名应用可以使用它们。 - [下载 Automic Vault](https://www.automicvault.com/zh-hans/download/): 获取 macOS 版 Automic Vault，保护本地 AI 代理运行。 - [文档](https://www.automicvault.com/docs/): 经源码核对的英文 Automic Vault 2.9.0 CLI 手册，涵盖 scan、doctor、save、inject、bless 和 harden。 - [软件包](https://pkg.so/zh-hans/): 可搜索开发者软件包、依赖项、安装命令、风险信息和 Automic Vault 加固覆盖情况。 - [Blog](https://www.automicvault.com/blog/): 关于软件包、扩展、凭据和本地执行事件的开发者安全指南与分析。 - [关于 Automic Vault | 保护你用 brew install 装上的工具](https://www.automicvault.com/zh-hans/about/): Automic Vault 在 AI 代理使用之前，在你的 Mac 本地保护 Homebrew 工具、CLI 密钥和命令审批门。 - [Automic Vault 隐私](https://www.automicvault.com/zh-hans/privacy/): Automic Vault 的本地数据边界、网站分析和隐私说明。 - [Automic Vault 条款](https://www.automicvault.com/zh-hans/terms/): Automic Vault 的使用条款、开源许可证和网站说明。 - [GitHub](https://github.com/automic-vault/automic-vault): Apache-2.0 源代码、标签版本、实现历史和公开问题跟踪。 - [安全](https://www.automicvault.com/.well-known/security.txt): 公布当前安全联系方式、首选语言、规范地址和到期日期。 ## 关键信息 - 平台：macOS - 当前文档版本：2.9.0 - 许可证：Apache License 2.0 - 价格：免费开源软件 - 创始人：Homebrew 作者 Max Howell ## 联系方式 - 网站: https://www.automicvault.com/zh-hans/ - GitHub: https://github.com/automic-vault/automic-vault - 安全报告: https://github.com/automic-vault/automic-vault/issues # /zh-hans/privacy/ Automic Vault 隐私 | AI 代理与开发工具安全 下载 软件包 Blog 关于 GitHub Automic Vault 本地密钥留在本地 Automic Vault 的本地数据边界、网站分析和隐私说明。 下载 文档 产品数据 Automic Vault 用于保护开发者机器上的密钥，并不是托管密钥服务。 网站数据 网站使用基础分析和公开资源，不收集产品中的密钥。 本地运行边界 Automic Vault 将代理可读取的文件与只提供给已批准工具的凭据分开。控制发生在 Mac 的执行路径上，而不是只依赖代理提示词。 Homebrew 与 CLI 许多开发工具来自 Homebrew、npm、PyPI 和云 CLI。Vault 会检测这些工具留下的凭据文件和高风险操作，并把审批放到实际执行位置。 下一步 先运行扫描器检查明文暴露，将支持的密钥移入受保护的本地存储，并保持 Automic Vault 运行，以便及时收到新的 hazard 通知。 安装后的变化 熟悉的 CLI 仍可继续使用。区别在于密钥不再作为容易读取的配置文件留在磁盘上，而是只交给真正需要它的已批准执行。 与中心化 vault 配合 1Password、HashiCorp Vault 和云端密钥系统仍可作为真实来源。Automic Vault 保护的是本地 Mac 工具使用这些值的那一刻。 相关页面 文档、下载、密钥扫描器和软件包目录展示完整流程：发现暴露、加固工具、加入审批门，并持续监控开发机器。 持续监控 新的软件包、过时工具和重新生成的配置文件可能在首次修复后重新带来风险。Automic Vault 会保持运行并提示新的 hazard。 可信线索 公开仓库、安全页面、许可证以及 Max Howell 的 Homebrew 背景都可查看。本地安全边界应该能够被验证。 何时使用 在让代理处理仓库之前、使用云 CLI 之前，以及允许 npm publish、gh release 或基础设施变更等高权限命令之前使用 Automic Vault。 Automic Vault 本地密钥留在本地 下载 文档 软件包 © 2026 Automic Vault. 网站 关于 Blog 隐私 条款 GitHub English 日本語 Deutsch Français 简体中文 # /zh-hans/terms/ Automic Vault 条款 | AI 代理与开发工具安全 下载 软件包 Blog 关于 GitHub Automic Vault 开源本地安全工具 Automic Vault 的使用条款、开源许可证和网站说明。 下载 文档 许可证 Automic Vault 以 Apache License 2.0 提供。 使用 本网站提供产品信息、文档和软件包元数据。 本地运行边界 Automic Vault 将代理可读取的文件与只提供给已批准工具的凭据分开。控制发生在 Mac 的执行路径上，而不是只依赖代理提示词。 Homebrew 与 CLI 许多开发工具来自 Homebrew、npm、PyPI 和云 CLI。Vault 会检测这些工具留下的凭据文件和高风险操作，并把审批放到实际执行位置。 下一步 先运行扫描器检查明文暴露，将支持的密钥移入受保护的本地存储，并保持 Automic Vault 运行，以便及时收到新的 hazard 通知。 安装后的变化 熟悉的 CLI 仍可继续使用。区别在于密钥不再作为容易读取的配置文件留在磁盘上，而是只交给真正需要它的已批准执行。 与中心化 vault 配合 1Password、HashiCorp Vault 和云端密钥系统仍可作为真实来源。Automic Vault 保护的是本地 Mac 工具使用这些值的那一刻。 相关页面 文档、下载、密钥扫描器和软件包目录展示完整流程：发现暴露、加固工具、加入审批门，并持续监控开发机器。 持续监控 新的软件包、过时工具和重新生成的配置文件可能在首次修复后重新带来风险。Automic Vault 会保持运行并提示新的 hazard。 可信线索 公开仓库、安全页面、许可证以及 Max Howell 的 Homebrew 背景都可查看。本地安全边界应该能够被验证。 何时使用 在让代理处理仓库之前、使用云 CLI 之前，以及允许 npm publish、gh release 或基础设施变更等高权限命令之前使用 Automic Vault。 Automic Vault 开源本地安全工具 下载 文档 软件包 © 2026 Automic Vault. 网站 关于 Blog 隐私 条款 GitHub English 日本語 Deutsch Français 简体中文