Local AI isolation

Four layers of isolation. Each layer is sufficient on its own. Together, they make leakage structurally impossible.

This page is the proof, not just the claim. AI tools running on this workstation cannot read the values behind the locked keychain. They cannot obtain a GitHub write credential without taking a visible lease, and they cannot read the file paths where keys live at rest.

Live gapThese layers hold for the target identities, not for today. Every agent session still runs as the operator. The operator’s Doppler config holds GitHub write AppRole pairs and the App private key, and token write takes no lease. Live status is on Agent identity and access.

Layer 1—nothing is stored, so there is nothing to steal

There is no GitHub token at rest on the workstation. Every GitHub credential is an ephemeral GitHub App installation token minted at the moment of use and discarded with the process that asked for it. git never holds one of its own: a credential helper answers each request, mints a token scoped to that request, hands it to git, and forgets it. The chain starts at a command that needs a credential and ends with nothing persisted. A stolen shell history, a leaked environment dump, or a recovered disk image yields no usable GitHub credential, because none was ever written.

Never export a token from .envrc. The directory-environment loader caches its environment dump on disk. Exporting a credential at load time would persist that credential, exactly the property this layer exists to remove. Mint at call time instead.

Layer 2—three credential tiers, and only one is ambient

The credential an agent can obtain without ceremony is deliberately the least useful one. Escalation is not a matter of reading a different secret; it is a different minting path with a different gate.

Tier	What it grants	Gate	AI can reach it?
Read	Read-only across the account installation	Ambient: pre-authorized	Yes, freely
Write	Exactly one named repository, per request	A claim that takes an exclusive lease on that repository	Yes, but only one repository at a time, and visibly
Admin	The installation’s full ceiling	Human-only, interactive, single-use grant	No

This is a stronger boundary than “which secret can you read.” A read credential cannot be widened into a write credential. The write tier mints from a different endpoint under a policy that pins the repository parameter server-side. An agent that claims write on one repository still cannot tap a second one with that token. And the administrator tier has no non-interactive path at all. There is nothing for an agent to read, unlock, or guess. The lease is the visibility mechanism: a write claim is recorded, exclusive, and self-expiring. Two agents cannot silently both hold write on one repository. See GitHub access for the full model.

Layer 3—the keychain holds nothing an agent needs

There is no AI-readable keychain tier. Every automated read moved to the runtime manager, and what stays on the keychain is human-only break-glass material in a locked database. The detail is in macOS Keychain. The boundary that matters here is that an AI subprocess cannot satisfy the unlock prompt. There is no unlocked database holding a credential it could use instead.

Layer 4—explicit allow / deny lists in Claude Code

The Claude Code permission system bakes a deny list into the build. Even if the previous layers were bypassed, the harness refuses the file paths that would yield secret material.

Allow (read-only inspection)	Deny (Read / Edit / Write blocked)
`security find-generic-password` (lookup metadata)	`*/.env`
`security list-keychains`	`/secrets/`
`security show-keychain-info`	`~/.gnupg/**`
	`~/.ssh/id_*`

The allow list lets the AI inspect metadata, such as whether a keychain entry with a given service name exists, without ever returning the value.

Layer 5—unattended convergence belongs to one identity

The interactive human account has no password-less escalation. Every sudo it runs is biometrically gated, convergence included. Unattended convergence runs instead under a dedicated automation account whose grant covers one exact declarative command and nothing else. It applies store paths that were already built, with no ad-hoc shell and no other read access. Which harnesses run under that account is set out in harness trust tiers. Some launchers relaunch claude under a scoped credential context, such as an AWS profile. Each prints this to stderr before calling exec claude. The banner lands in the AI’s tool-output stream, so the agent knows what it can and cannot do this session:

[claude-launchers] custom authentication context is now active
  type:    aws-vault profile
  context: <profile name>
  scope:   this claude process only — the parent shell is unaffected

You now have the credentials and capabilities granted by this context.
Tools that auto-detect credentials from the environment (aws, gh, git,
terraform, kubectl, etc.) will pick them up automatically. Nothing
persists once claude exits; the parent shell's environment is untouched.

No secret material is ever printed. The banner names the kind of context, never the value.

What AI can and cannot do

Capability	AI tool	Why
Obtain a read-only GitHub credential	✅	Ambient read tier; read-only by construction
Obtain GitHub write on one named repository	✅ (one at a time)	Requires an exclusive, recorded, self-expiring lease
Obtain GitHub write across an account	❌	Repository parameter is pinned server-side per request
Obtain an installation-wide administrator credential	❌	Human-only interactive single-use grant
Recover a GitHub token from disk	❌	No token is ever written to disk
Read a value from the human-only keychain	❌	GUI unlock prompt; AI cannot respond
Modify keychain entries	❌	`security add-generic-password` not in allow list
Read `.env*` files	❌	Path glob denied
Read `~/.ssh/id_*` private keys	❌	Path glob denied
Read GPG keys	❌	`~/.gnupg/**` denied
Run `sudo` outside `darwin-rebuild`	❌	sudoers entry is path-restricted
Run `doppler run -- <cmd>`	✅	Injection at the subprocess boundary; nothing persists past the child

Source files

For the literal Nix and shell sources behind each layer, see:

nix-darwin/modules/darwin/scripts/openbao-github-creds.sh : the credential helper and the claim/release lease.
nix-darwin/hosts/common/claude-launchers.zsh: the scoped launchers and banner.
nix-claude-code/data/permissions/allow.nix: read-only security allow list.
nix-claude-code/data/permissions/deny.nix: file-path deny globs.
nix-darwin/modules/darwin/security.nix: sudoers path restriction.

Security

Secrets management

Layer 1—nothing is stored, so there is nothing to steal

Layer 2—three credential tiers, and only one is ambient

Layer 3—the keychain holds nothing an agent needs

Layer 4—explicit allow / deny lists in Claude Code

Layer 5—unattended convergence belongs to one identity

The launcher banner (verbatim)

What AI can and cannot do

Source files

See also

​Layer 1—nothing is stored, so there is nothing to steal

​Layer 2—three credential tiers, and only one is ambient

​Layer 3—the keychain holds nothing an agent needs

​Layer 4—explicit allow / deny lists in Claude Code

​Layer 5—unattended convergence belongs to one identity

​The launcher banner (verbatim)

​What AI can and cannot do

​Source files

​See also

Layer 1—nothing is stored, so there is nothing to steal

Layer 2—three credential tiers, and only one is ambient

Layer 3—the keychain holds nothing an agent needs

Layer 4—explicit allow / deny lists in Claude Code

Layer 5—unattended convergence belongs to one identity

The launcher banner (verbatim)

What AI can and cannot do

Source files

See also