The ssh-agent socket is protected via filesystem permissions. root can talk to the socket if it wants to, changing UIDs if necessary.

However, this only gives you access to the current instance of ssh-agent. You don't have access to the authorization key or passphrase itself, only a authentication-granting agent using these tokens. Killing the instance of ssh-agent, or merely dumping keys, is sufficient to counter this attack. And note that if you've got root on the box, there are significant problems already.

Given the circumstances in which ssh-agent is likely to be used, this is a significant improvement, from a security perspective, over the alternatives

• Access is via unsecured keys. In this case, filesystem access (root user or a reboot under another OS instance) is sufficient to compromise the system, and the exploit data are persistent across both process and system boot instances.
• Access is via a secured key, but passphrase is either stored in a file or provided via other methods (interactive access, command line options, handcrafted agent). Any of these methods reduce security, convenience, or both.

Also, there are yet more alternatives. It's possible to use a [link|http://www.google.com/search?q=ssh+%22forced+command%22|forced command], in which case a given SSH key is only capable of executing a single command. Forced commands can themselves be used w/o passphrases, interactively, or via ssh-agent.

The balance is functionality, convenience, and security. If you need the functionality, then start looking at convenience & security. ssh-agent's a pretty slick way to fly.