Skip to main content
One job left: human break-glass. There is no AI-readable keychain tier.
The automation keychain tier is retired. Every automated read moved to OpenBao (T2), where an agent authenticates via AppRole with zero interactive prompts. The AppRole secret-zero that bootstraps that path is not kept in a keychain. The run-wrapper publishes it into the agent’s environment. What remains on the keychain is human-only break-glass material behind a locked database. It also holds ordinary login convenience that no automated flow depends on. See the four-tier model.
No GitHub token lives here. Every GitHub token is an ephemeral GitHub App installation token minted on demand and never written to disk. See GitHub access for the model.

One database that matters

The human-only database stays locked and prompts on every read. That is exactly what disqualifies it for automation, and exactly why break-glass material belongs there. A second, login-unlocked database still exists as an operating-system feature. Nothing in this estate’s automated paths reads from it, and no credential is placed there for an agent to find. Machine secret-zero does not live on the keychain. The per-domain AppRole that bootstraps T2 reaches an agent through the run-wrapper’s environment. The keychain holds no AppRole, no app secret, and no service token an agent consumes.

Reading a keychain entry the right way

The last positional argument is the keychain path. Omit it and security searches the login keychain only. That keychain does not contain these entries. Always pass the path explicitly so the lookup hits the right database:
Each security find-generic-password call against the locked human-only keychain triggers an unlock prompt; inlining the read on every command would prompt every time. Fetch once, inject the variable across the session, and unset it when done. A prompt is the expected behaviour here, not an obstacle to work around.

Adding a new keychain entry

The -U flag updates if the entry already exists.

Best practices

  • Do not add a credential here for an automated flow to read. If a process needs it, it belongs in the runtime manager or is minted per call.
  • Keep break-glass material in the locked database only. The unlock posture is the whole control.
  • Cap the auto-lock timeout on the human-only database (~5 minutes idle) so an abandoned session re-locks.
  • Biometric confirmation gates every privilege escalation on the interactive human account. Unattended escalation belongs to the automation identity alone, scoped to one exact command. See harness trust tiers.
  • Prefer an engine-minted, expiring credential over a stored one, always.

See also