Tu agente de IA lleva tus llaves SSH en el bolsillo y nadie lo pregunta

📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.

Anduve esta semana leyendo un pull request como quien lee la letra chica de un contrato: la gente de OpenAI tiene un PR en el repo de Codex que se llama, textualmente, Forward SSH agents through app-server proxy. Ahí fue cuando se me cruzó una idea que me dejó incómodo: tu agente de IA se sube a un servidor remoto a trabajar, y arriba de ese servidor usa las llaves SSH de tu computador. Tuyo. Las tuyas de siempre, las que abren tus repos privados y tus VPS.

Lo verifiqué en el código, no en un rumor

El aviso circuló en Hacker News con un punto simple: el agente que corre en la máquina remota puede autenticarse con tus credenciales SSH locales, o sea, puede hacer push a tus repos privados de GitHub. Como el proyecto es open source, en vez de quedarme con la duda fui a ver el PR 28131 de openai/codex. Y sí: el app-server se levanta con SSH_AUTH_SOCK apuntando a ~/.codex/app-server-control/forwarded-ssh-agent.sock, con la bandera --forward-ssh-agent. Traducción sin rodeos: los comandos que el agente ejecuta lejos de tu laptop pasan por el socket de TU ssh-agent.

No es un exploit ni un 0-day. Es agent forwarding, una feature de SSH con más de tres décadas de vida, y el propio manual de ssh lleva años advirtiendo que es mala idea si no confías de verdad en el host destino. Lo nuevo es quién corre ahí arriba: ya no es un compañero de pega con shell remota, es un agente autónomo ejecutando comandos mientras tú no miras.

Ni siquiera te pregunta

Aquí está mi pifia favorita del asunto: la comodidad manda. La app decide por ti que las llaves viajan, porque el agente que no puede hacer SSH a la otra máquina es más incómodo que uno que puede. En seguridad esa fricción es justamente lo que te salva: cada vez que una llave firma algo, alguien tendría que mirar. Si el forwarding es automático y silencioso, la mirada nadie la pone.

Yo administrar servidores es parte de mi vida diaria, con una flota de VPS donde corro agentes en crons, así que este tema me tocó directo. Mi política es simple y funciona: cada agente tiene su propia llave, de mínimo privilegio, sin relación con mi ssh-agent personal. Si el agente necesita entrar a otra máquina por SSH, entra con SU llave, no con la mía. Y las llaves que no pueden rotar así van en hardware que exige toque físico o biometría por cada uso: una YubiKey con la opción de touch requerido, o en macOS guardándolas en el Secure Enclave con herramientas como Secretive, que piden tu huella cada sesión nueva. La clave del asunto es esa: el agente no puede firmar nada solo.

Qué haría hoy si usas ChatGPT Desktop o Codex

Tres cosas concretas, sin parafernalia:

Primero, revisa si tu flujo depende del SSH-agent del app-server y qué llaves tiene a la vista. Segundo, revisa tu ~/.ssh/config buscando ForwardAgent activo por defecto — esa línea sola ya es un riesgo — y mata lo que no uses. Tercero, separa los mundos: llaves de agente aparte, llaves personales aparte, y si el agente puede hacerlo en sandbox o en la nube, mejor ahí que en tu laptop. Es lo mismo principio que con las llaves de una casa: no le entregas tu copia maestra a la persona que hace un mandado puntual.

Hay una frase de la HN que me quedó dando vueltas: los agentes resuelven todo menos el sentido común. Lo agregaría yo: tampoco resuelven la pregunta de a quién le devuelven las llaves cuando terminan la pega. Si administras servidores y le has entregado el teclado a un agente, revisa hoy dónde quedó tu socket.

Fuente de inspiración: ChatGPT Desktop forwards your SSH agent to remote machines