Filtraciones de secretos de Claude Code: Apiiro encuentra credenciales en 1.122 archivos públicos de GitHub
Las filtraciones de secretos de Claude Code han puesto bajo escrutinio las aprobaciones guardadas de Anthropic después de que Apiiro reportara credenciales en 1.122 archivos públicos de configuración de GitHub. Su investigación del 5 de noviembre describe una función que recuerda comandos que contienen secretos. La publicación requiere otro paso: confirmar y enviar el archivo resultante.
La tensión se sitúa entre un atajo útil y el registro sensible que crea. Los desarrolladores aprueban una operación para terminar su trabajo, mientras el software conserva información que merece protección por separado. Una decisión sobre ejecución se convierte en una decisión sobre almacenamiento, a menudo sin que el usuario trate ambas como elecciones distintas.
Anthropic ha reconocido la preocupación, al tiempo que recalca que el archivo de configuración debe permanecer local. Cursor ofrece una comparación útil porque su documentación también aborda la ejecución autónoma y sus riesgos. En estos productos, la cuestión es cómo los sistemas de permisos preservan la comodidad sin crear otro lugar donde se acumulen credenciales.
Qué mide realmente el hallazgo sobre las filtraciones de secretos de Claude Code
La investigación sobre exposición de credenciales de Apiiro examinó 104.185 copias públicas de .claude/settings.local.json. Identificó 1.379 secretos distintos en los 1.122 archivos señalados. Los investigadores no probaron esas credenciales, por lo que el recuento no demuestra acceso funcional ni intrusiones exitosas.
El titular mide archivos expuestos, no cuentas comprometidas. Esa distinción importa para la respuesta a incidentes, las decisiones de compra y cualquier afirmación sobre la gravedad del hallazgo. La presencia de una credencial establece un motivo para investigar, mientras que su validez y sus permisos determinan las consecuencias inmediatas.
El flujo de trabajo subyacente resulta familiar. Un asistente de programación propone una operación, el desarrollador la revisa y una aprobación persistente reduce futuras interrupciones. La consecuencia inesperada aparece cuando la aprobación guardada retiene información que el desarrollador consideraba temporal.
Pensemos en una comprobación de base de datos de preproducción como escenario ilustrativo. El desarrollador necesita que el asistente investigue una conexión fallida y aprueba un comando que contiene información de autenticación. Completar esa comprobación no requiere que la credencial se convierta en un artefacto duradero del proyecto.
Sin embargo, un registro de aprobación puede conservar precisamente la información que necesitaba la operación. Su propósito suena administrativo, lo que facilita separarlo mentalmente de contraseñas y tokens de acceso. Esa separación se vuelve peligrosa cuando los revisores suponen que la configuración contiene preferencias y no datos operativos sensibles.
El repositorio público añade otra frontera. La información que antes estaba disponible para la máquina de un desarrollador pasa a estar disponible para cualquiera que pueda leer el proyecto. Por tanto, la función de aprobación y el flujo de trabajo de publicación requieren un escrutinio independiente.
Sería exagerar la evidencia afirmar que seleccionar la opción envía automáticamente contraseñas a GitHub. La secuencia reportada implica persistencia local seguida de publicación mediante control de versiones, el sistema que registra y comparte los cambios del proyecto. Cada etapa crea una oportunidad de prevención.
También sería minimizar el problema describirlo únicamente como una confirmación descuidada. El comportamiento del producto determina qué material sensible existe para que alguien pueda confirmar. Un flujo de publicación más seguro ayuda, pero evitar copias innecesarias de credenciales aborda una parte anterior del problema.
El cambio relevante es lo que los equipos deben considerar durante la revisión. La configuración de los agentes merece atención junto con el código de la aplicación y la configuración de despliegue. Un archivo puede afectar a la seguridad por la información que conserva, incluso si no contiene ningún programa ejecutable.
Eso amplía el significado de un cambio sensible. Los revisores deben considerar tanto lo que revela un archivo como lo que hace que la aplicación ejecute. Los registros de permisos se sitúan directamente en esa intersección.
Un archivo local de configuración es una promesa con condiciones
La documentación sobre configuración local de Anthropic indica que las aprobaciones persistentes de Bash se convierten en reglas de permiso en .claude/settings.local.json. Bash es una shell de comandos usada para ejecutar programas. Claude Code añade una exclusión a la configuración global de Git ignore del desarrollador cuando escribe por primera vez el archivo bajo las condiciones documentadas.
La documentación identifica por separado .claude/settings.json como configuración compartida del proyecto que los equipos pueden confirmar. Los archivos locales creados manualmente requieren su propia exclusión. Estas distinciones aclaran el límite previsto, pero también otorgan importancia a cómo se originó el archivo.
Llamar local a un archivo no impone, por sí solo, la privacidad. Su nombre comunica una intención a las personas, mientras que los controles del repositorio determinan si viaja con el proyecto. Son protecciones relacionadas con condiciones de fallo diferentes.
Una exclusión global pertenece al entorno de un desarrollador. Una exclusión a nivel de proyecto pertenece al flujo de trabajo del repositorio. Esa diferencia importa siempre que los equipos esperen que una convención de seguridad sobreviva a cambios de máquinas, colaboradores o entornos de desarrollo.
Consideremos la entrega de un proyecto como ejemplo analítico. El autor original sabe qué archivos contienen estado personal y cuáles pertenecen al control de código fuente. Un nuevo colaborador ve la estructura de directorios sin necesariamente heredar esa comprensión.
El problema se vuelve organizativo cuando cada colaborador debe reconstruir la misma distinción. Una regla que depende del conocimiento personal exige atención repetida. Una regla representada en una política compartida del proyecto es más fácil de inspeccionar y debatir.
Ninguno de los dos enfoques elimina la necesidad de revisar lo que entra en una confirmación. Una exclusión es una convención preventiva, mientras que el cambio confirmado es la decisión de publicación real. Los equipos deberían evaluar ambos en lugar de asumir que la presencia de cualquiera garantiza el otro.
La terminología también merece atención. La configuración suele sugerir preferencias inofensivas, como opciones de visualización o comportamiento del editor. Un archivo de permisos puede contener un registro mucho más sensible porque su contenido procede de operaciones reales.
Ese desajuste presiona el diseño del producto. Si el software conserva argumentos de comandos, debería ayudar a los usuarios a comprender esa persistencia antes de que traten el archivo como configuración ordinaria. La advertencia pertinente debe estar cerca de la decisión que crea el registro.
Aquí existe una restricción legítima de usabilidad. Exigir a los usuarios que inspeccionen cada detalle de implementación dificultaría el uso del asistente y fomentaría aprobaciones superficiales. El reto de diseño consiste en mostrar la consecuencia relevante sin saturar la operación en sí.
Para los compradores empresariales, esto se convierte en una pregunta concreta de evaluación. ¿Pueden los administradores explicar qué archivos de agentes son seguros de compartir, cuáles siguen siendo personales y cuáles pueden contener datos sensibles? Las respuestas de un producto deberían ajustarse a los controles de repositorio que los empleados realmente utilizan.
Los permisos de Claude Code explicados mediante documentación proporcionan el modelo previsto. La prueba práctica es si ese modelo sigue siendo comprensible durante la colaboración cotidiana. La documentación establece expectativas; el comportamiento observable determina si los equipos pueden seguirlas de forma fiable.
El atajo intercambia avisos repetidos por datos persistentes
La comodidad de las aprobaciones persistentes es fácil de entender. Los desarrolladores quieren que un asistente continúe el trabajo rutinario sin interrumpir cada paso. Un sistema que solicita repetidamente la misma decisión anima a los usuarios a buscar autorizaciones más amplias o duraderas.
La compensación central se da entre menos interrupciones y la información retenida para hacerlas posibles. El permiso de ejecución y el almacenamiento de credenciales merecen decisiones separadas, incluso cuando la interfaz los presenta juntos.
Una forma útil de evaluar el diseño es separar capacidad de datos. La capacidad describe lo que el agente puede hacer, como ejecutar una operación de desarrollo aprobada. Los datos incluyen los argumentos concretos y el material de autenticación proporcionado durante una ejecución.
Conservar la capacidad no exige necesariamente conservar cada dato. Sin embargo, eliminar argumentos puede cambiar el significado de una regla. Una aprobación más amplia podría autorizar operaciones que el usuario nunca pretendió, creando un problema de seguridad diferente.
Por eso, simplemente eliminar texto sospechoso de los comandos guardados es una especificación de diseño incompleta. El producto debe preservar el alcance previsto por el usuario al tiempo que evita la retención innecesaria. El comportamiento resultante también debe seguir siendo comprensible cuando una operación solicite permiso de nuevo más adelante.
Las referencias a credenciales ofrecen otra dirección de diseño. Un comando puede referirse a un valor proporcionado por separado en vez de incorporar el valor directamente. Eso reduce la necesidad de que un registro de aprobación contenga la propia credencial.
Las referencias aún requieren cuidado. Un programa podría imprimir un valor resuelto, un mensaje de error podría revelarlo u otro artefacto podría conservar la salida. Evitar una contraseña literal en un registro reduce la exposición sin establecer una protección completa.
Aquí es donde la historia se vuelve relevante más allá de un botón concreto. El software de agentes produce registros para favorecer la continuidad, la depuración y la colaboración. Cada registro debería tener una finalidad, una audiencia y una política de retención definidas, proporcionales a su contenido.
La aparente memoria del asistente puede ocultar esas preguntas. Los usuarios experimentan una conversación que continúa el trabajo, mientras que la implementación puede crear archivos con distintas reglas de compartición. Los equipos de producto deben hacer visibles los límites relevantes.
La documentación sobre seguridad de agentes en segundo plano de Cursor ofrece una comparación útil. Describe máquinas virtuales aisladas, acceso a internet y ejecución automática en terminal. También advierte que las instrucciones maliciosas pueden conducir al robo de datos mediante inyección de prompts, donde contenido no confiable redirige el comportamiento de un agente.
Esa comparación no demuestra que Cursor comparta el comportamiento reportado de almacenamiento de aprobaciones de Claude Code. Muestra que los diseños competidores distribuyen la responsabilidad de forma distinta entre ejecución, aislamiento y revisión del usuario. Los compradores deberían comparar esos mecanismos por separado, en lugar de seleccionar un producto únicamente por su modo de aprobación.
El aislamiento restringe el entorno en el que se ejecuta una operación. La aprobación decide si una operación continúa. La gestión de credenciales determina qué datos sensibles entran en el entorno y qué registros permanecen después.
Estos controles se refuerzan mutuamente cuando sus límites son explícitos. Se vuelven confusos cuando una decisión satisfactoria en una capa se trata como evidencia de que todas las demás capas son seguras. Una operación autorizada aún puede dejar un registro inapropiado.
Los riesgos de seguridad de Claude Code, por tanto, merecen una evaluación a nivel de flujo de trabajo. La pregunta útil es qué información crea una tarea aprobada, dónde persiste esa información y quién puede recuperarla después.
Anthropic reconoce la brecha, pero el modo automático no es un certificado de corrección
Boris Cherny, del equipo de Claude Code, respondió al informe en el debate sobre la seguridad de los permisos. Afirmó que Claude Code históricamente carecía de depuración de secretos y recomendó el modo automático y el análisis de secretos en repositorios. También describió posibles medidas de protección para la creación de prototipos, incluida la detección básica de secretos.
Un lector cuestionó si el modo automático aún podía llegar a la ruta de aprobación problemática. Cherny reconoció esa observación. Sus comentarios establecen una respuesta activa, pero no demuestran que se haya lanzado una solución integral.
Una medida de protección propuesta necesita verificarse frente al fallo que pretende prevenir. Reducir las aprobaciones manuales e impedir la persistencia de credenciales son objetivos relacionados, con criterios de aceptación distintos. La evidencia de uno no debe sustituir a la evidencia sobre el otro.
La visión escéptica es sencilla. Si una operación sensible sigue creando un registro de aprobación que contiene una credencial, cambiar el modo de ejecución predeterminado mantiene relevante esa vía. Una respuesta debe abordar el artefacto resultante, además de la frecuencia de las solicitudes.
También hay un argumento razonable detrás del énfasis de Anthropic en reducir las interrupciones por permisos. Las solicitudes repetidas pueden consumir atención sin generar una revisión cuidadosa. Mejorar esa experiencia merece la pena, siempre que la mejora no se convierta en una afirmación general de seguridad.
El desacuerdo se refiere en parte a dónde debe aplicarse el control. Algunos usuarios quieren restricciones fijas que se mantengan independientemente de la interpretación de un agente. Otros prefieren una evaluación automática capaz de distinguir la actividad rutinaria de las operaciones sensibles.
Esos enfoques responden a una pregunta diferente de si los registros guardados contienen contraseñas. Un límite estricto de ejecución puede coexistir con una retención excesiva de datos. Un revisor automático puede reducir las interrupciones y aun así necesitar reglas explícitas sobre qué se escribe en disco.
La evaluación empresarial debería mantener esas cuestiones separadas. Un comprador puede valorar la ejecución automática de tareas y seguir exigiendo un comportamiento de almacenamiento predecible. El producto debería demostrar ambas cosas mediante resultados observables, en lugar de pedir a los clientes que infieran una a partir de la otra.
Un ejercicio de verificación creíble utilizaría credenciales artificiales en un proyecto controlado. Inspeccionaría el registro de aprobación y otros artefactos resultantes después de la operación. También examinaría el comportamiento cuando ya se rastrea un archivo local sensible.
Estas son condiciones de evaluación propuestas, no afirmaciones sobre pruebas completadas por Anthropic. Describen la evidencia necesaria para distinguir una respuesta prometedora de una mejora demostrada. Los resultados publicados permitirían a los clientes juzgar el alcance de cualquier cambio.
Las filtraciones de secretos de Claude Code también revelan un desafío de comunicación. Aconsejar a los usuarios que activen otro control es útil, pero deja abierta la cuestión de qué responsabilidad asumirá el propio producto. Las notas de lanzamiento claras deberían explicar tanto la nueva protección como las condiciones que siguen vigentes.
La conclusión más justa es limitada y práctica. Anthropic reconoce la preocupación, los usuarios han planteado casos límite relevantes y la eficacia de los cambios propuestos requiere observación. Ni la desestimación ni una declaración de corrección completa encajan con la evidencia disponible.
Los equipos de seguridad heredan un tipo distinto de revisión de repositorios
Para los equipos de seguridad, la presión inmediata se refiere a la visibilidad. Las revisiones de aplicaciones suelen concentrarse en el código que se ejecuta en producción. La configuración generada por agentes puede crear exposición antes de que la propia aplicación cambie de comportamiento.
La revisión debe seguir la información sensible a lo largo del flujo de desarrollo. Un archivo de configuración merece escrutinio en función de su contenido y destino. Su propósito administrativo no vuelve inocua la información que contiene.
La protección contra envíos de GitHub bloquea las detecciones de secretos compatibles antes de la publicación. Su documentación distingue patrones específicos de proveedores, genéricos, personalizados y detectados por IA, con requisitos de configuración variables. Por tanto, los equipos deben verificar la cobertura que han habilitado en lugar de asumir que se detectará toda credencial.
La presencia de un escáner y la cobertura demostrada de un escáner son formas distintas de evidencia. Un token reconocible de un servicio y una contraseña común insertada en un comando plantean desafíos de detección diferentes. Las pruebas con ejemplos artificiales pueden revelar si el sistema configurado reconoce los patrones que realmente utiliza un equipo.
Esto cambia la conversación entre desarrolladores y personal de seguridad. El desarrollador necesita un flujo de trabajo que siga funcionando. El equipo de seguridad necesita evidencia de que los valores sensibles no entren silenciosamente en material destinado a compartirse.
El objetivo compartido debería ser un límite repetible. El estado personal del agente debería tener un destino explícito, la configuración compartida debería contar con un estándar de revisión claro y las credenciales detectadas deberían llegar a alguien que pueda revocarlas.
La respuesta a incidentes también debe separar la contención de la limpieza. La guía de GitHub sobre eliminación de datos sensibles prioriza la revocación o rotación de las credenciales expuestas. Explica que la eliminación histórica requiere coordinación y que pueden permanecer copias en clones, bifurcaciones y otras referencias.
Ese orden refleja la diferencia entre una credencial y el documento que la contiene. Editar un documento cambia lo que los lectores ven en esa ubicación. La revocación cambia si la credencial sigue autorizando el acceso.
Para un equipo bajo presión, una limpieza visible puede parecer finalizada porque el archivo infractor desaparece de la vista más reciente. El resultado de seguridad relevante es si el valor expuesto conserva autoridad. La limpieza histórica y la revisión de accesos abordan consecuencias adicionales.
La responsabilidad se vuelve más difícil cuando la persona que descubre el registro no puede identificar a su propietario. Un desarrollador podría reconocer el nombre de un proyecto sin saber qué sistema emitió un token. Una propiedad clara acorta el camino entre la detección y una contención efectiva.
Los equipos también necesitan una forma de conservar la lección sin conservar el secreto. Una nota de incidente puede describir el flujo de trabajo afectado, el servicio responsable y el cambio preventivo. Debe evitar copiar valores sensibles solo para hacer concreta la explicación.
Esa distinción también se aplica a una base de conocimiento con capacidad de búsqueda. El conocimiento de ingeniería útil incluye procedimientos aprobados y explicaciones de fallos anteriores. Las credenciales pertenecen a sistemas diseñados para gestionar el acceso, no a material de referencia general.
Los riesgos de seguridad de Claude Code son más fáciles de gobernar cuando la respuesta tiene responsables identificados. Los desarrolladores pueden explicar la tarea, los equipos de plataforma pueden aplicar convenciones de repositorio y los propietarios de servicios pueden sustituir credenciales de acceso. El personal de seguridad no debería tener que reconstruir todas esas relaciones durante una investigación.
El cambio organizativo práctico es un perímetro de revisión más amplio. Los equipos necesitan inspeccionar lo que el asistente deja atrás junto con lo que edita. Eso convierte el estado persistente del agente en parte de la gobernanza habitual de ingeniería.
¿Qué demostraría que la vía de exposición se está cerrando?
La próxima evidencia útil debería llegar en el comportamiento del producto, los controles del repositorio y los resultados de remediación. Estas señales abordan diferentes partes de la secuencia reportada. En conjunto, pueden mostrar si la vía de exposición original se vuelve más difícil de reproducir.
El progreso debe medirse por la persistencia evitada y la reducción de la autoridad de las credenciales. El lenguaje de los anuncios por sí solo no puede demostrar ninguno de esos resultados. La evidencia más sólida conectará una medida de protección específica con un cambio observable.
En primer lugar, conviene esperar una versión documentada de Claude Code que cambie la forma en que se almacenan las aprobaciones sensibles. El detalle decisivo es qué ocurre cuando un comando por lo demás legítimo contiene material de autenticación. Una versión debería explicar el registro resultante y las circunstancias que aún requieren intervención del usuario.
La evidencia de que los secretos sintéticos ya no aparecen en las aprobaciones guardadas reforzaría el argumento de una mejora significativa del producto. La evidencia de que los mismos valores permanecen bajo una ruta de permisos alternativa limitaría esa conclusión. Ambos resultados son más informativos que una afirmación general sobre automatización más segura.
El alcance de las pruebas importa tanto como el comportamiento principal. Un proyecto nuevo y un repositorio con un archivo de configuración existente ya rastreado representan condiciones iniciales diferentes. Una explicación clara debería identificar qué condiciones cubre la protección.
En segundo lugar, conviene observar controles de repositorio que demuestren cobertura de la configuración de agentes y de las credenciales incrustadas en comandos. Esto incluye políticas de exclusión claras y detección de secretos probada. El resultado significativo es si se detiene un intento de publicación o se dirige a una revisión efectiva.
Un documento de política por sí solo deja incierta la ejecución. Un ejercicio controlado que demuestre que las credenciales artificiales activan la respuesta esperada proporciona evidencia más sólida. Los fallos repetidos debilitarían la confianza en el análisis como control compensatorio.
Esta señal también importa para los competidores. Los proveedores pueden describir los entornos de ejecución de manera diferente y aun así necesitar explicar sus artefactos retenidos. Una documentación clara de los archivos generados, los límites de uso compartido y el manejo de credenciales haría las comparaciones más útiles para los compradores.
En tercer lugar, conviene observar informes de remediación que distingan los archivos eliminados de las credenciales invalidadas. La apariencia del repositorio es fácil de observar, mientras que el acceso continuado requiere información del servicio responsable. Un seguimiento creíble debería mantener separados esos resultados.
Los resultados de Apiiro no se han reproducido de forma independiente aquí, y su recopilación no debe tratarse como una muestra aleatoria de todos los proyectos de Claude Code. La población reportada consta de archivos detectables públicamente. Eso limita las conclusiones sobre la prevalencia de la exposición en la base de usuarios más amplia.
Esas limitaciones dejan intacta la preocupación central de ingeniería. Una función que conserva contexto operativo necesita una política clara para los datos sensibles. Los usuarios deberían poder entender esa política sin reconstruir la implementación durante un plazo ajustado.
Para los equipos que evalúan las filtraciones de secretos de Claude Code, comiencen por el registro de aprobación que realmente crea su flujo de trabajo. Utilicen credenciales sintéticas para examinar qué persiste y, después, verifiquen qué controles impiden que ese material llegue a un repositorio compartido. Asignen responsables antes de que una exposición real fuerce la cuestión. Conserven los hallazgos como procedimientos que los compañeros puedan seguir sin reproducir valores sensibles. Cuando aparezcan credenciales auténticas en material compartido, conviertan su autoridad restante en la primera pregunta para el propietario del servicio responsable. Soliciten a los proveedores evidencia que aborde tanto el almacenamiento como la ejecución. La siguiente revisión más útil es la que responde a una pregunta concreta: después de que finalice una tarea aprobada, ¿qué información sensible permanece y quién puede obtenerla?
