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.
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.
Mint a long-lived token. A deploy token, a PAT, an "automation" credential that expires never. It feels more hygienic than a key, but it's the same bearer problem with extra steps. The rule of thumb: if revoking a credential requires remembering it exists, it will outlive the experiment it was created for.
Give the agent its own root account. This one at least shows the right instinct — a separate identity you can revoke separately. But done the usual way (drop a public key into authorized_keys
for a deploy-bot
user, walk away), it ships with no audit trail. Nothing distinguishes the agent's commands from anyone else's, nothing records what it actually did, and when something breaks at 2 a.m. you're reconstructing an agent's session from bash history and vibes.
The common thread: in all three, the agent holds a standing credential, and observability is an afterthought.
Flip the model. The agent should never hold the credential at all.
None of this is exotic — it's roughly how certificate-based SSH already works at companies with real infrastructure teams. The catch has always been that wiring it up yourself is a project, so most people skip straight to one of the bad options above.
Termalin is an SSH client with a built-in MCP server. Your agent — Claude, or anything that speaks the Model Context Protocol — gets tools like hosts_list
, ssh_exec
, SFTP reads and writes, and persistent sessions. Termalin does the authenticating.
On your machine. Register the bundled local server with your agent:
claude mcp add termalin -- <path>/termalin-mcp
The agent reaches only the hosts you've enabled in Settings → MCP — agent access is off by default, and the host inventory is written with agent-only auth, so no passwords land on disk. Authentication goes through Termalin's key custodian: you unlock your keys once, and Termalin signs on the agent's behalf. No ssh-add
, no key file for the agent to read, no key touching disk at all.
And you can actually watch. Agent sessions run as live terminal tabs, the watch grid mirrors every open session side by side, and the tiles an agent is driving glow. Letting the agent type into a session you already have open is a separate consent toggle, not a default. Every agent command is marked in the session recording — which captures output only, never your keystrokes — and written to the audit log with the device and IP it came from.
No app running. If your agent lives where your desktop isn't — CI, a cloud sandbox — create an API key in the web cabinet and point it at the hosted MCP endpoint:
{
"mcpServers": {
"termalin": {
"url": "https://termal.in/api/v1/mcp",
"headers": { "Authorization": "Bearer tk_live_…" }
}
}
}
The hosted endpoint reaches only servers enrolled with the tunnel agent, and it authenticates each run with a short-lived certificate — again, no standing key is ever handed out. The API keys themselves are scoped to specific servers, carry an expiry (30, 90 or 365 days), and can be revoked any time; hosted runs are rate-limited and time-boxed per key.
Either way, the property you wanted holds: the agent can deploy, and it has never seen a key.
Don't begin with production. Enroll one low-stakes box — the staging server, a toy VPS. Give the agent a real chore: deploy the branch, tail the log until the error shows up, fix the config, restart the service. Keep the watch grid open while it works. What you learn in the first hour — how it behaves, where it hesitates, what it does with ambiguity — tells you whether the second host gets enrolled.
That's the quiet payoff of the custodian model: you get to expand one host at a time, because no step you take is one you can't take back.
Termalin's Free tier is the full desktop app, and every new account starts with a 14-day Pro trial — download it, or start with the MCP docs.