archwall 把架构画全Every architecture, drawn in full

Automic Vault：让 AI 智能体用你的凭据前，先过一道闸Automic Vault: a gate between AI agents and your credentials

securitycredentialsmacosagentskeychain

Automic Vault overview: In: you, a terminal or an AI agent runs a tool such as gh, aws or brew on a Mac. 1 Set up once: av scan checks over 100 developer-tool configurations for exposed credentials, av harden moves a supported tool's credentials into the macOS Keychain and changes how the tool asks for them, and av doctor checks that protection. 2 A command asks: the Launcher (a terminal, IDE or agent app) starts the tool, a signed Automic Vault Gate Client sends the request, and the Authorization Gate for that request, the tool's own or a built-in one, receives it on the Mac. 3 Decide: the Mac checks the Launcher's live code signature, applies the gate's default Access Level or a rule for that Launcher, and asks for Approval on the Mac, with Touch ID or on an iPhone when policy cannot allow it; unknown operations always need Approval. 4 Record and release: an Authorization Record is saved and read back first, then the secret goes to the program that needs it; with no record there is no secret.

Automic Vault 在 Mac 上保管开发者的凭据。它把令牌从文件挪进钥匙串。之后，你或 AI 智能体要用凭据的命令，都先过一道检查。

设置。 av scan 找出暴露的凭据。av harden 把它们挪走，并改掉工具取凭据的方式。av doctor 检查结果。

Set up a tool: 1 Detect: Detectors check over 100 developer-tool configurations and report each Finding, an Exposure or a Hazard, with a fix; they never use a secret, and a clean scan is not a guarantee. 2 Harden: a Hardener moves the credential from a file or helper into the macOS Data Protection Keychain and changes how the tool asks for it, through a credential helper, a wrapper or an Isotope; examples are gh, aws, docker and Homebrew. 3 Isotopes: an Isotope is an Automic Vault-compatible build of a tool; signed fork releases are pinned in the Isotopes Homebrew tap, some vendor releases are kept signed in a protected folder under /opt/av, and without Homebrew executable-only Isotopes are verified and installed directly. 4 Verify: av doctor checks identity, ownership, permissions and which command runs first; wrappers guard only the command path they sit on, not every way to run a program.
设置：扫描、加固、Isotope、验证

一次请求。 Mac 先查谁在要、整条命令是什么。规则可以直接放行，否则由你批准或拒绝。先存好记录，密钥才放出去。

One request: In: an AI agent with Read Only access runs gh issue create. 1 Who is asking: the Launcher, here the agent app; the Gate Client, the signed piece that sends the request; and the Target, the program that will use the secret. Client and Target are kept apart. 2 Check: the Launcher's identity from its live code signature; the complete request, meaning command, arguments, folder and secret names; and denial rules, which are checked first. Any failed check denies. 3 Decide: a Blessing, the gate's policy or a Temporary Access Grant may allow it; an unknown or too broad operation needs Approval, which can allow or deny. With Read Only, gh issue create needs Approval. 4 Release: the Authorization Record is saved and read back, then the secret is applied or the Target runs, and the menu bar shows the live use.
一次请求：谁在要、检查、决定、先记录再放行

谁在要。 身份看应用的代码签名，每次请求都现场检查。没签名的命令行工具可以套一个 Launcher Bundle。

Who is asking: 1 Verified Launchers: the terminals, IDEs and agent apps you pick; identity is the code signature, checked live on every request; Hardened Runtime is needed to allow a request automatically, while a failed runtime check falls back to Approval when human approval is available, and an Apple system binary counts as protected. Paths and names are not identity. 2 Helpers inside apps: Claude Code's helper is built in, Codex's signed CLI is preselected for your review, and other helpers count only if you approve them; finding a helper grants nothing. 3 Unsigned CLIs: a Launcher Bundle wraps one unsigned single-file Mach-O CLI, signs it with Hardened Runtime and rechecks it on every request; a changed or re-signed bundle is denied outright. Scripts are not supported. 4 Scripts and agent tasks: a Blessed Script is trusted for its exact reviewed contents; a Codex or Claude Code task ID can narrow a Temporary Access Grant, but software can forge it, so it is not identity.
谁在要：身份看代码签名，不看路径和名字

访问规则。 每个工具的闸门有几档访问级别。文档建议给智能体只读。没见过的命令永远要问。

Access rules: 1 Access Levels, presets a gate offers: Approval Required asks every time, Read Only allows recognized reads, Write Access allows recognized reads and writes, and Full Access may allow recognized sensitive operations; some gates add Read & Update (Homebrew) or Local Write between them. 2 Per gate: each gate has a default level, new secret gates start at Read Only, rules for a Verified Launcher override the default, and unknown operations need Approval at every level. 3 Example, one GitHub token at Read Only: gh issue list is allowed automatically, gh issue create needs Approval, and gh auth token, which shows the secret, needs Approval. 4 Short-lived changes: a Temporary Access Grant gives Write Access for ten active minutes to one gate, launcher and agent task; denial rules are checked before anything that allows; a temporary denial blocks one launcher at one gate for two minutes.
访问规则：访问级别、每个闸门的默认、短期调整

批准可以在 Mac 上点，用 Touch ID，或者在 iPhone 上。Mac 核对每个回答。

Human Approval: In: a request that policy cannot allow. 1 On the Mac: an Approval window shows the complete request and the chain of programs behind it; optional Touch ID needs a fresh fingerprint each time. Mac approval needs an active session and awake displays. 2 On an iPhone, optional: the iPhone app on the same iCloud Keychain account; an encrypted relay server passes requests and answers but cannot read or forge them; allowing needs a subscription, denying does not. 3 The Mac checks the answer: it must match the exact request, the first valid answer wins and replays are rejected, and the record is saved before release. 4 Limits: when the Mac is locked only secrets marked available while locked can be used; with iPhone Approval on, the Mac has no click-to-allow; if the phone or relay is unreachable the request fails closed unless Touch ID Approval is also enabled.
人工批准：Mac、Touch ID 或 iPhone，Mac 核对每个回答

密钥和记录。 密钥留在钥匙串里。每次使用都加密记在这台 Mac 上，最多保留 30 天，还有大小上限。

Secrets and history: 1 Stored in the Keychain: secret bytes sit in the app's private group of the macOS Data Protection Keychain; gate policy and the history key each sit in a separate Keychain service. 2 Which value: the nearest Project Value in the working folder or a folder above it on the same volume wins, otherwise the Global Value; if the chosen value cannot be read the request is denied, with no fallback. The folder only picks a value and grants nothing. 3 Release rules: there is no call that simply loads a secret; an allowed use is recorded and read back before the secret leaves; on a locked Mac only secrets marked available while locked can be used. 4 History: encrypted rows in one SQLite file on this Mac, kept up to 30 days or until a size cap, 25 MiB by default, whichever comes first; reading it with av history needs Approval or a separate grant. It is not tamper-proof.
密钥和记录：存在钥匙串，先记录再放行

其他用法： 审过的脚本、av inject、Secret Proxy 和 Varlock。

Other ways to use a secret: 1 Blessed Scripts: av bless reviews a script once; the script declares the secret names and tool capabilities it needs; editing it ends the Blessing. 2 av inject: puts named secrets into a program's environment; --mode=fd hands each secret through its own pipe and needs fresh Approval every time; a Direct Access Rule lets one launcher use one secret name with any program, the broadest and least preferred option. 3 Secret Proxy: av proxy gives the app a random stand-in reference; a separately signed proxy helper puts the real secret into outbound HTTPS requests only for destinations you approve, for that session; the references are still bearer values. 4 Varlock, optional: the Varlock plugin asks for all its secrets in one request, with one Approval per run and no standing rules or Blessings.
其他用法：脚本、av inject、Secret Proxy、Varlock

签名、SSH 和 Homebrew 各有自己的闸门。

Signing, SSH and Homebrew: 1 GPG signing: Git hands the commit to av-gpg; the private key stays in the Keychain and Git never sees it; the gate offers Approval Required, its default, or Allow Signing. 2 SSH agent, optional: av ssh-agent serves its own socket; each key has its own gate and policy; it signs in memory and private keys are never added to the system agent. 3 Homebrew: an Execution Gate controls brew even when no secret is involved; its default, Read & Update, allows reads and brew update but not install, upgrade or remove. 4 Git over HTTPS: av git is a protected HTTPS path that narrows use of the gh credential; it is still under validation.
签名、SSH 和 Homebrew 各自的闸门

组成部分： av 命令和几个小助手、一个掌管钥匙串的菜单栏应用，以及可选的 iPhone 应用和中继。

The pieces: 1 Command-line side, on the Mac: the av CLI in Rust is the Gate Client; small signed helpers are av-gpg, the Homebrew brew stub and the proxy helper; Isotopes are the hardened builds of tools. 2 Menu bar app, on the Mac: written in Swift, it is the approval service; it alone owns the Keychain with secrets, policy and history, and starts at login as a macOS LaunchAgent. The CLI talks to it over authenticated XPC. 3 Phone side, optional: the iPhone app approves or denies; the approval relay is a Rust server that passes encrypted messages over WebSocket and wakes the phone through Apple push notifications. 4 Install: Automic Vault.app from a release or the Homebrew cask; signed fork Isotope releases come from the Isotopes tap; the app installs its CLI with administrator approval.
组成部分：命令行、菜单栏应用、iPhone 和中继、安装

Automic Vault guards developer credentials on a Mac. It moves tokens out of files into the Keychain. After that, every command that needs one is checked first, whether you or an AI agent runs it.

Set up. av scan finds exposed credentials. av harden moves them and changes how the tool asks for them. av doctor checks the result.

Set up a tool: 1 Detect: Detectors check over 100 developer-tool configurations and report each Finding, an Exposure or a Hazard, with a fix; they never use a secret, and a clean scan is not a guarantee. 2 Harden: a Hardener moves the credential from a file or helper into the macOS Data Protection Keychain and changes how the tool asks for it, through a credential helper, a wrapper or an Isotope; examples are gh, aws, docker and Homebrew. 3 Isotopes: an Isotope is an Automic Vault-compatible build of a tool; signed fork releases are pinned in the Isotopes Homebrew tap, some vendor releases are kept signed in a protected folder under /opt/av, and without Homebrew executable-only Isotopes are verified and installed directly. 4 Verify: av doctor checks identity, ownership, permissions and which command runs first; wrappers guard only the command path they sit on, not every way to run a program.
Set up: scan, harden, Isotopes, verify

One request. The Mac checks who is asking and the whole command. A rule may allow it; otherwise you approve or deny. A record is saved before the secret goes out.

One request: In: an AI agent with Read Only access runs gh issue create. 1 Who is asking: the Launcher, here the agent app; the Gate Client, the signed piece that sends the request; and the Target, the program that will use the secret. Client and Target are kept apart. 2 Check: the Launcher's identity from its live code signature; the complete request, meaning command, arguments, folder and secret names; and denial rules, which are checked first. Any failed check denies. 3 Decide: a Blessing, the gate's policy or a Temporary Access Grant may allow it; an unknown or too broad operation needs Approval, which can allow or deny. With Read Only, gh issue create needs Approval. 4 Release: the Authorization Record is saved and read back, then the secret is applied or the Target runs, and the menu bar shows the live use.
One request: who asks, checks, decision, record before release

Who is asking. Identity comes from the app's code signature, checked live on every request. An unsigned CLI can get a Launcher Bundle.

Who is asking: 1 Verified Launchers: the terminals, IDEs and agent apps you pick; identity is the code signature, checked live on every request; Hardened Runtime is needed to allow a request automatically, while a failed runtime check falls back to Approval when human approval is available, and an Apple system binary counts as protected. Paths and names are not identity. 2 Helpers inside apps: Claude Code's helper is built in, Codex's signed CLI is preselected for your review, and other helpers count only if you approve them; finding a helper grants nothing. 3 Unsigned CLIs: a Launcher Bundle wraps one unsigned single-file Mach-O CLI, signs it with Hardened Runtime and rechecks it on every request; a changed or re-signed bundle is denied outright. Scripts are not supported. 4 Scripts and agent tasks: a Blessed Script is trusted for its exact reviewed contents; a Codex or Claude Code task ID can narrow a Temporary Access Grant, but software can forge it, so it is not identity.
Who is asking: identity is the code signature, not a path or name

Access rules. Each tool's gate has Access Levels. The docs suggest Read Only for agents. Unknown commands always ask.

Access rules: 1 Access Levels, presets a gate offers: Approval Required asks every time, Read Only allows recognized reads, Write Access allows recognized reads and writes, and Full Access may allow recognized sensitive operations; some gates add Read & Update (Homebrew) or Local Write between them. 2 Per gate: each gate has a default level, new secret gates start at Read Only, rules for a Verified Launcher override the default, and unknown operations need Approval at every level. 3 Example, one GitHub token at Read Only: gh issue list is allowed automatically, gh issue create needs Approval, and gh auth token, which shows the secret, needs Approval. 4 Short-lived changes: a Temporary Access Grant gives Write Access for ten active minutes to one gate, launcher and agent task; denial rules are checked before anything that allows; a temporary denial blocks one launcher at one gate for two minutes.
Access rules: Access Levels, gate defaults, short-lived changes

Approval happens on the Mac, with Touch ID, or on an iPhone. The Mac checks every answer.

Human Approval: In: a request that policy cannot allow. 1 On the Mac: an Approval window shows the complete request and the chain of programs behind it; optional Touch ID needs a fresh fingerprint each time. Mac approval needs an active session and awake displays. 2 On an iPhone, optional: the iPhone app on the same iCloud Keychain account; an encrypted relay server passes requests and answers but cannot read or forge them; allowing needs a subscription, denying does not. 3 The Mac checks the answer: it must match the exact request, the first valid answer wins and replays are rejected, and the record is saved before release. 4 Limits: when the Mac is locked only secrets marked available while locked can be used; with iPhone Approval on, the Mac has no click-to-allow; if the phone or relay is unreachable the request fails closed unless Touch ID Approval is also enabled.
Approval: Mac, Touch ID or iPhone, and the Mac checks every answer

Secrets and history. Secrets stay in the Keychain. Each use is logged on the Mac, encrypted, for up to 30 days within a size cap.

Secrets and history: 1 Stored in the Keychain: secret bytes sit in the app's private group of the macOS Data Protection Keychain; gate policy and the history key each sit in a separate Keychain service. 2 Which value: the nearest Project Value in the working folder or a folder above it on the same volume wins, otherwise the Global Value; if the chosen value cannot be read the request is denied, with no fallback. The folder only picks a value and grants nothing. 3 Release rules: there is no call that simply loads a secret; an allowed use is recorded and read back before the secret leaves; on a locked Mac only secrets marked available while locked can be used. 4 History: encrypted rows in one SQLite file on this Mac, kept up to 30 days or until a size cap, 25 MiB by default, whichever comes first; reading it with av history needs Approval or a separate grant. It is not tamper-proof.
Secrets and history: kept in the Keychain, recorded before release

Other ways to use a secret: reviewed scripts, av inject, the Secret Proxy and Varlock.

Other ways to use a secret: 1 Blessed Scripts: av bless reviews a script once; the script declares the secret names and tool capabilities it needs; editing it ends the Blessing. 2 av inject: puts named secrets into a program's environment; --mode=fd hands each secret through its own pipe and needs fresh Approval every time; a Direct Access Rule lets one launcher use one secret name with any program, the broadest and least preferred option. 3 Secret Proxy: av proxy gives the app a random stand-in reference; a separately signed proxy helper puts the real secret into outbound HTTPS requests only for destinations you approve, for that session; the references are still bearer values. 4 Varlock, optional: the Varlock plugin asks for all its secrets in one request, with one Approval per run and no standing rules or Blessings.
Other ways: scripts, av inject, the Secret Proxy, Varlock

Signing, SSH and Homebrew have their own gates.

Signing, SSH and Homebrew: 1 GPG signing: Git hands the commit to av-gpg; the private key stays in the Keychain and Git never sees it; the gate offers Approval Required, its default, or Allow Signing. 2 SSH agent, optional: av ssh-agent serves its own socket; each key has its own gate and policy; it signs in memory and private keys are never added to the system agent. 3 Homebrew: an Execution Gate controls brew even when no secret is involved; its default, Read & Update, allows reads and brew update but not install, upgrade or remove. 4 Git over HTTPS: av git is a protected HTTPS path that narrows use of the gh credential; it is still under validation.
Signing, SSH and Homebrew gates

The pieces: the av command and its helpers, a menu bar app that owns the Keychain, and an optional iPhone app with a relay.

The pieces: 1 Command-line side, on the Mac: the av CLI in Rust is the Gate Client; small signed helpers are av-gpg, the Homebrew brew stub and the proxy helper; Isotopes are the hardened builds of tools. 2 Menu bar app, on the Mac: written in Swift, it is the approval service; it alone owns the Keychain with secrets, policy and history, and starts at login as a macOS LaunchAgent. The CLI talks to it over authenticated XPC. 3 Phone side, optional: the iPhone app approves or denies; the approval relay is a Rust server that passes encrypted messages over WebSocket and wakes the phone through Apple push notifications. 4 Install: Automic Vault.app from a release or the Homebrew cask; signed fork Isotope releases come from the Isotopes tap; the app installs its CLI with administrator approval.
The pieces: CLI, menu bar app, iPhone and relay, install

来源Source: github.com

← 全部架构← All architectures