Gave my coding agents SSH access to real servers without putting keys in their environment - here's the trust model

Been building this for months and want to sanity-check the design with people who actually run agents. The problem: when an agent's task leaves the repo (restart a service, run a migration, check why nginx is down on the actual box), it needs SSH. The default is pasting a key into its environment or letting it use your unlocked ssh-agent - a bearer credential you can't take back. The agent can leak it, a prompt injection can exfiltrate it, and revoking means rotating keys on every host. My setup: the agent never sees a key. It talks to an SSH client over MCP; the client holds the keys and signs on the agent's behalf. On top of that: - Per-host policy: full access / command allowlist / blocked. The blast radius of a compromised agent is bounded per host, not global. - Live watch grid: every agent session mirrors into a read-only view I can glance at. The agent doesn't know it's being watched - no observer effect, it can't perform for the camera. - Audit log: every command lands with host, time, device and IP. Session recording is output-only (no keystrokes), so typed passwords never enter the record. Honest limitations I've hit so far: a command allowlist over shell strings is a brake, not a boundary (an allowed command that takes a path can still be abused). Key custody stops credential exfiltration but not data exfiltration through allowed output - cat .env is still cat .env. And "revoke" can stop new work, but can't reliably kill an already-running remote process without server-side cooperation. Curious how others handle this. Do you give agents raw SSH? Scoped deploy keys per task? Some kind of broker? And what would it take for you to trust an agent on a production box? (It's a product I'm building - Termalin - happy to share details in comments if anyone asks; keeping links out of the post on purpose.)