SSH keys and secret management: the overlap nobody talks about

Teams that rotate API keys on a schedule will let SSH private keys sit in ~/.ssh for years. A leaked private key grants the same access as a leaked token — it is a credential like any other — yet it rarely appears in secret inventories, rotation playbooks, or agent-hardening discussions. The gap is not a tooling problem. It is a mindset problem, and the fix starts with noticing that SSH already solved half of it.

SSH keys are secrets, full stop

An SSH private key authenticates you to servers, and in many setups it is the master key to everything behind those servers. Treating it as infrastructure plumbing rather than a credential is how keys end up committed to repos, baked into container images, or copied across machines “temporarily.” The inventory discipline you apply to API tokens — know what exists, where it lives, who can use it — should apply to keys, including the long tail of old keys still accepted by authorized_keys files on machines you forgot about.

The ssh-agent pattern is worth copying

The interesting part is that SSH got the delegation model right decades ago. ssh-agent holds decrypted keys in memory; ssh asks the agent for a signature and never touches the key file itself. ssh-add -t bounds key lifetimes, and agent forwarding lets you hop across hosts without copying private material around.

That is the same shape as a credential broker for AI agents: a long-lived holder, short-lived access, and no plaintext handed to the tool that does the work. The difference is that agent tooling today skips the pattern — tools receive tokens in environment variables and echo them back into logs, transcripts, and context windows.

Where SSH key management falls apart

• Passphrases disabled for automation. The key sits unencrypted on disk because a cron job needs it. The moment that disk is readable, so is the key.
• Forwarding without boundaries. A forwarded agent socket is usable by any process on the remote host. One compromised remote process becomes a signing oracle for everything the key can reach.
• No removal culture. Adding a new key is easy; removing the old one is forgotten. authorized_keys grows into a permanent inventory of everything you ever rotated.
• Keys outside the secret store. Because keys “aren’t secrets,” they never get the encryption-at-rest, backup, or rotation treatment of vault contents.

The overlap with agent secret management

Once you accept that a private key is a credential, the tooling question collapses into the one you already have. The key should live in the same store as your tokens: a pass entry or a vault item can hold the private key encrypted, with the passphrase stored alongside or prompted once. And the consumer should not read the store directly. A broker resolves the credential at the moment it is needed, injects it into the subprocess or transport, and scrubs it from output.

The pattern is identical to what tools like trustless do for API tokens — inject at spawn, sanitize stdout and stderr, keep the plaintext out of logs. If you already treat tokens that way, the only missing step is putting keys under the same regime. The mechanics are described in the command reference.

The overlap nobody talks about is that SSH key management is secret management — with a head start on delegation and a long way behind on lifecycle. Which of your private keys is still valid, and who — or what — can use it right now?