10. Security Considerations

The agent retains and provides controlled access to long-lived login authentication credentials. The protocol itself does not include authentication or transport security; being able to communicate with an agent is usually enough to invoke private key operations.

Agents must be exposed only to their owner and authorized delegates. Unix-like systems can use filesystem permissions and peer identity checks such as SO_PEERCRED; Windows can use security descriptors on named pipes.

Agents should prevent memory disclosure, disable debugging interfaces where appropriate, and prevent memory dumps. They SHOULD use cryptographic implementations resistant to side-channel attacks and MAY hide actual processing time for private key operations.

Agent forwarding creates a transitive trust relationship. SSH implementations SHOULD NOT forward agents by default, and users SHOULD NOT forward agents to untrusted hosts. Agents SHOULD provide controls over key visibility and use for forwarded connections.

Token or smart-card key support must avoid loading hostile provider libraries. Agent locking SHOULD include countermeasures against brute-force passphrase guessing, such as delays, lockout periods, or deletion of keys after too many failed attempts.