the agent never hands out the key but only signs a nonce with the key, so the operation it does is not really critical The ability to sign is the ability to as

the agent never hands out the key but only signs a nonce with the key, so the operation it does is not really critical The ability to sign is the ability to assert identity. If it's known that you connect to host B and host A is compromised but low value, if you forward your agent to host A, something on host A can use your agent to connect to host B and you wouldn't know. At least with notifications, you'd know something was up. This is why I made it easy to lock and unlock the agent on demand (mentioned in my other comment). Paired with on-demand agent locking, notifications let you know when the transaction is completed and you can lock your agent again. Additionally, ssh itself already prevents you from connecting to spoofed hosts (using the known_hosts mechanism). Only for the first hop. An ssh session on a remote host knows of a different set of host keys than the machine that is running the agent. Unfortunately, there doesn't seem to be a way to reliably identify which of a series of hosts that your agent socket may be forwarded through is using your agent. As for the risk of replacing a system binary, that's why I hooked it through SSH_ASKPASS.