La opción «Yes, and don’t ask again» del asistente de Anthropic guarda contraseñas y API keys literales en archivos de configuración que terminan subidos a repositorios abiertos.
Un asistente de código con inteligencia artificial diseñado para acelerar el desarrollo está dejando credenciales sensibles a la vista de cualquiera. Apiiro, empresa especializada en seguridad de software, identificó 1.122 copias públicas de archivos de configuración de Claude Code — el asistente de programación de Anthropic — que contienen contraseñas y claves de API en texto plano. El problema no es un bug de implementación: es el comportamiento por diseño de una función pensada para reducir interrupciones al desarrollador.
Cómo la función de aprobación persistente convierte comandos en archivos públicos
Claude Code permite que el usuario apruebe comandos con la opción «Yes, and don’t ask again» (Sí, y no volver a preguntar). Cuando se selecciona esta alternativa, el asistente guarda el comando completo — palabra por palabra — en un archivo de configuración del proyecto. Si ese comando incluye una contraseña, un token de acceso o una API key como parámetro, el secreto queda registrado literalmente en el archivo de ajustes.
El mecanismo está pensado para evitar que el desarrollador tenga que autorizar repetidamente la misma operación. Pero la implementación no distingue entre comandos genéricos y comandos que contienen datos sensibles. Tampoco advierte al usuario que el contenido aprobado se persistirá en un archivo de configuración que, en la práctica habitual de desarrollo, termina versionado junto con el resto del código del proyecto.
Cuando ese proyecto se sube a un repositorio público de GitHub — algo común en desarrollo open source, portfolios personales o simplemente por error de configuración de privacidad — los archivos de configuración de Claude Code quedan accesibles para cualquiera que sepa dónde buscar. Apiiro reportó el hallazgo después de identificar más de mil repositorios en esta situación.
Por qué los asistentes de código amplifican el riesgo de filtración de secretos
La exposición de credenciales en repositorios públicos no es nueva: herramientas de escaneo automático llevan años detectando API keys hardcodeadas en código fuente. Pero los asistentes de IA introducen un vector distinto. El desarrollador no está escribiendo la credencial directamente en un archivo de código — está aprobando un comando que el asistente ejecutará, y la persistencia de ese comando en configuración no es evidente en el flujo de trabajo.
El problema se agrava porque los archivos de configuración de herramientas de desarrollo suelen quedar fuera del radar de revisión de seguridad. Un desarrollador puede estar atento a no commitear un archivo .env con variables de entorno sensibles, pero no necesariamente asocia el archivo de ajustes de su asistente de código con el mismo riesgo. La función «don’t ask again» está diseñada para mejorar la experiencia de usuario — menos interrupciones, menos fricción — pero traslada la responsabilidad de evaluar qué es seguro persistir a un momento en que el usuario está enfocado en otra cosa.
Exposición en América Latina por adopción acelerada de herramientas de IA en desarrollo
La región enfrenta una exposición estructural a este tipo de filtración por dos factores concurrentes. Primero, la adopción de asistentes de código con IA está creciendo rápido en equipos de desarrollo de Argentina, Brasil, México y Colombia — países con ecosistemas tech activos y alta participación en proyectos open source internacionales. Segundo, muchos de esos equipos operan con presupuestos ajustados de seguridad y sin procesos formales de revisión de configuración de herramientas de desarrollo.
Un desarrollador en Buenos Aires o São Paulo que usa Claude Code para acelerar un proyecto personal o un MVP de startup tiene la misma probabilidad de seleccionar «don’t ask again» sin evaluar las implicancias de persistencia. Si ese proyecto se sube a GitHub como portfolio o se abre como repositorio público para colaboración, las credenciales quedan expuestas sin que el desarrollador haya cometido un error evidente de seguridad — simplemente confió en el comportamiento por defecto de una herramienta que no advierte sobre el riesgo.
Qué falta para que este patrón se convierta en explotación masiva
Hasta ahora, Apiiro reportó el hallazgo como una vulnerabilidad de diseño, no como una campaña de explotación activa. Pero los 1.122 repositorios identificados son solo los que la empresa escaneó — el número real de archivos expuestos es probablemente mayor. Y a diferencia de una vulnerabilidad de software que requiere un exploit técnico, acá no hace falta ninguna habilidad especial: basta con saber qué archivos buscar en GitHub y tener acceso a la API de búsqueda de la plataforma.
Las credenciales expuestas pueden incluir tokens de acceso a servicios en la nube, claves de APIs de pago, contraseñas de bases de datos de desarrollo que replican esquemas de producción. En muchos casos, esos secretos siguen activos — no fueron rotados porque el desarrollador no sabe que quedaron expuestos. La ventana entre la publicación del repositorio y la detección del problema puede extenderse meses, tiempo suficiente para que un atacante automatice la recolección y pruebe las credenciales contra los servicios correspondientes.
Nuestro análisis
Este caso expone un patrón que se repite cada vez que una herramienta de productividad prioriza la reducción de fricción sobre la visibilidad de las consecuencias de seguridad. La función «don’t ask again» no es inherentemente insegura — el problema es que no distingue contextos ni advierte cuándo la persistencia de un comando puede convertirse en una filtración. Anthropic diseñó Claude Code para que el desarrollador trabaje más rápido, pero trasladó a ese desarrollador la responsabilidad de anticipar que un archivo de configuración local puede terminar en un repositorio público.
Lo que hace este hallazgo particularmente relevante es que no depende de un error de implementación que Anthropic pueda parchear con una actualización. Es una decisión de diseño: guardar comandos completos, literales, sin sanitización ni advertencia. Cambiar ese comportamiento requeriría rediseñar la función — agregar detección de patrones que parezcan secretos, advertir antes de persistir, o separar la aprobación de comandos de la persistencia de sus parámetros. Mientras tanto, cada desarrollador que selecciona «don’t ask again» con un comando que incluye una credencial está creando un archivo que, si se versiona y se sube a GitHub, queda expuesto indefinidamente.
¿Cuántos de esos 1.122 repositorios pertenecen a proyectos que ya están en producción, con las mismas credenciales filtradas todavía activas en sus entornos reales?