The coding part is mostly solved. An agent can branch, patch, write the tests, open the PR. Then the change has to land on an actual server — a service restarted, a migration run, an nginx config edited — and the autonomy stops cold. Deploying needs SSH, SSH needs credentials, and nobody in their right mind wants to paste a private key into an agent's environment.
That hesitation is correct, and it's worth being precise about why. An SSH private key is a bearer credential: whoever holds the bytes is you. Sharing it with an agent is not like sharing it with a colleague, because you can't take it back. Once a key has passed through an agent's context — an env var, a mounted file, a config blob — you can no longer prove it didn't end up in a log, a transcript, or a tool call you never read. The only honest answer to "did the model see my key?" is to rotate the key, on every host that trusts it. That's the irreversibility problem, and it's why "just give the agent a key" feels wrong even to people who can't articulate the threat model.
Three ways to do it badly
Paste the raw key. The direct route: drop id_ed25519 into the agent's config or environment and let it run ssh itself. Beyond the irreversibility above, an SSH key has no scope and no expiry — the key that deploys to staging can usually also read the production database credentials two hops away. And revocation means rotation, which means touching authorized_keys on every box, which means you'll put it off.
