📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.
Imagínate esta escena: instalas un agente de código porque quieres avanzar más rápido, y a las semanas tu bandeja de entrada amanece llena de correo basura, correos de estafadores y preguntas extrañas de gente a la que nunca le pasaste tu dirección. No fue un phishing ni un hackeo de la cuenta. Fue el propio agente, entregando tu correo a cualquier sitio web en la cabecera User-Agent de sus peticiones.
Cómo se filtra un email por un header
La mecánica es tan simple como incómoda. Anthropic metió el correo de la cuenta del usuario en el contexto del modelo, con una razón de todo entender: la gente se quejaba de que Claude alucinaba autores y etiquetas de autoría porque no tenía ni idea de quién le daba órdenes. El detalle es que el agente escribe sus propios comandos. Cuando le pediste que investigara en internet, se armó un curl solo, y en varias corridas usó tu correo como dirección de contacto en el User-Agent. No alucinó del todo: hay servicios que piden eso a clientes automatizados, Wikipedia por ejemplo exige identificarse con un correo de contacto. El modelo generalizó la norma y la aplicó con todos.
El reporte se viralizó el 5 de noviembre en el tracker de Claude Code: el afectado recibía decenas de correos de estafadores al día y culpó directo al header. Los logs de varios usuarios confirmaron que la dirección fue enviada a múltiples dominios, y los comentarios del hilo se llenaron de historias idénticas, inbox reventados de golpe tras meses de calma total. Algo que parece marginal en un diff, por lo visto, se nota rápido cuando un modelo lo ejecuta a escala.
Un parche que es un adhesivo
Lo que más me interesa de esta historia es la respuesta. Anthropic metió un plugin interno llamado cc-plugin-privacy en las versiones 2.1.317 y 2.1.318, con verificaciones deterministas que deberían denegar cualquier comando en que el correo aparezca en un header. Usuarios hicieron la prueba en macOS y Windows: el plugin está cargado y de todas formas deja pasar los casos documentados. O sea, el dato sensible sigue en el contexto y encima el escudo no detiene el escape por la ruta principal. La corrección raíz, quitar la dirección de la entrada del modelo, está anunciada para la próxima versión de esta semana, pero la secuencia ya quedó retratada: primero se filtra a lo idiota, después se tapa con un parche que a su vez hay que parchar.
Hay otro punto que no puedo pasar por alto. El primer reporte de este comportamiento es de julio, hace más de cinco meses, durmiendo en un tracker con miles de issues abiertos. La corrección llegó cuando el hilo explotó en las redes. Conozco de sobra ese anti-patrón: si no duele afuera, no existe.
La lección que me quedó
En mi infraestructura corro varios agentes de código y esta historia me confirma una regla que repito hasta el cansancio: lo que le des al modelo, el modelo lo puede escribir dentro de un comando. Si un elemento del contexto no es estrictamente necesario para razonar, no entra. Mis credenciales, dominios y correos viven en archivos y variables de entorno, y cuando una tarea los necesita los inyecto en lo mínimo. Un correo en el contexto parecía inofensivo; el modelo lo usó como firma y el spam llegó a escala. La frase que resume todo la dejó un comentarista del hilo: la privacidad no debiera ser un plugin, debiera ser un invariante.
Si usas Claude Code, tres movimientos concretos: actualiza a la versión con la corrección raíz, revisa con /plugins qué chequeos tienes activos, y revisa tus logs de salida con el correo como patrón de búsqueda. Si aparece en alguno, ya sabes el origen. Y si tu inbox ha tenido un auge raro de spam esta semana, ya sabes dónde mirar.
Fuente de inspiración: Bug Report: Privacy violation in User-Agent header
