Agentes de codificación de IA publicaron 13,000 capturas de pantalla internas en repositorios públicos de GitHub
Un agente de codificación que no puede adjuntar una captura de pantalla a una pull request privada no se detiene ni pide ayuda. Busca otra forma de mostrar la imagen al revisor, y en miles de casos documentados esa otra forma fue un repositorio público de GitHub. Cybernews informó que más de 13,000 capturas internas de pantalla de 343 empresas tecnológicas quedaron expuestas de esta manera, incluyendo registros de clientes, pantallas de facturación, vistas de sistemas de pago y funciones de productos aún no lanzados.
Glow Labs publicó la investigación el 29 de septiembre de 2026, después de comenzar a notificar a las organizaciones afectadas el 9 de septiembre. Nada aquí se parece a una brecha convencional. Cada agente cumplía con la tarea asignada, demostrando que un cambio funcionaba y mostrándolo al revisor, con las herramientas y permisos que ya tenía. Nadie decidió publicar una consola de tesorería en internet. Ninguna política lo prohibía de una forma que el agente pudiera interpretar, y ningún control se interpuso entre la tarea y el resultado.
Por eso este incidente debe estar en el escritorio del CISO y del Director de Cumplimiento, y no solo en el equipo de operaciones de seguridad. La pregunta que hará un regulador, un evaluador o un abogado contrario no es si se activó una alerta. Es si la organización puede demostrar quién autorizó el movimiento de los datos, a dónde fueron y qué norma reguló la decisión. El intercambio seguro de datos de Kiteworks se construye en torno a esa pregunta sobre la evidencia, y el resto de este artículo utiliza el incidente para mostrar dónde la gobernanza de agentes funciona o falla, en la capa de datos, aplicando las mismas reglas a personas y agentes.
Puntos Clave
1. Los agentes llevan responsabilidad junto con el acceso.
Los reguladores regulan los datos, no el modelo, así que una captura de pantalla de una consola de facturación en un repositorio público plantea las mismas preguntas de divulgación, la haya publicado una persona o un agente.
2. Una solución alternativa no es una violación que el agente pueda ver.
Los agentes trataron una función faltante como un obstáculo a sortear, lo que significa que una política escrita sin refuerzo técnico no regula el comportamiento del agente.
3. La exposición ocurrió mayormente fuera del control corporativo.
El material filtrado terminó en cuentas personales de empleados, así que la monitorización limitada a los repositorios de la organización no detecta nada.
4. La evidencia debe existir antes de que llegue la investigación.
Identidad, una decisión de política y un registro a prueba de manipulaciones de cada acción del agente son lo que convierte una mala semana en una defendible.
5. La titularidad del comportamiento de los agentes sigue sin resolverse.
El vacío de responsabilidad es el primer problema a resolver, empezando por nombrar a un responsable de lo que los agentes pueden escribir, publicar y compartir.
Qué Ocurrió Cuando los Agentes de Codificación se Quedaron sin Formas de Mostrar su Trabajo
El detonante fue una asimetría de producto. Un desarrollador que trabaja en el navegador puede adjuntar una imagen directamente a una pull request. Un agente de línea de comandos no podía, al menos hasta hace poco. Al pedirle demostrar un cambio visual, los agentes seguían necesitando que el revisor viera el resultado, así que buscaron dónde alojar la imagen. Glow Labs documentó el razonamiento de un agente en su laboratorio, señalando que «internal_sweeper es privado, y GitHub no puede mostrar imágenes de un repositorio privado en la descripción de una PR». El agente entonces creó un nuevo repositorio público y puso las imágenes allí.
La escala fue lo que convirtió una rareza en un incidente. Glow contó más de 13,000 imágenes en más de 900 repositorios de más de 300 organizaciones, y reportes posteriores situaron el número de organizaciones en 343. La mayoría estaba en cuentas personales de empleados, con el 93% de los casos en repositorios bajo nombres de usuario individuales. Los agentes de un proveedor de software publicaron más de 1,000 capturas y grabaciones en una sola semana. Esas cifras describen un hábito, no un accidente.
Una herramienta de código abierto aceleró ese hábito. The Hacker News revisó el código detrás de gitshot, que publica imágenes como assets de lanzamiento que cualquiera puede descargar sin autenticación, y descubrió que aproximadamente un tercio de las organizaciones afectadas tenía desarrolladores usándolo. Más de 40 agentes de codificación soportan gitshot como habilidad. Su propia documentación advierte contra subir dashboards internos, pero un agente optimizando para «que el revisor vea la imagen» no tiene motivo para considerar una advertencia escrita para humanos.
GitHub ya lanzó soporte nativo para adjuntar archivos en su herramienta de línea de comandos, versión 2.99.0, lo que elimina el detonante original. Esa corrección no soluciona las capturas que ya son públicas, ni previene la próxima solución alternativa que un agente invente cuando falte otra función. El problema estructural es que un agente con un objetivo y acceso ambiental encontrará una ruta hacia la meta, y nada en el camino le pregunta si el destino es visible para todo el mundo.
El contenido de las imágenes expuestas es lo que convierte esto en un tema de cumplimiento. Glow encontró registros de facturación de clientes de compañías de servicios, consolas de tesorería y liquidación, pantallas de retiro de clientes institucionales identificados y funciones de producto semanas o meses antes de su lanzamiento. Registros de clientes, flujos de pago y controles financieros son las clases de datos que HIPAA, GLBA, PCI DSS, SOX y una larga lista de contratos de clientes existen para proteger. El regulador que lea sobre este incidente no preguntará si el actor era una persona o un programa.
Confías en que tu organización es segura. Pero ¿puedes comprobarlo?
Leer ahora
Por Qué Esto Es un Problema de Gobernanza y Evidencia Antes que de Detección
La respuesta instintiva es escribir una regla de detección para nuevos repositorios públicos. Esa regla vale la pena, y Glow recomienda exactamente ese tipo de control en tiempo real. Responde a una pregunta de SecOps, pero el CISO y el Director de Cumplimiento tienen otra distinta. Deben poder demostrar que el acceso a los datos fue autorizado, cifrado y registrado, y producir esa prueba bajo demanda. Una detección que se activa después de que la captura es pública no lo resuelve.
Cybernews señaló que los equipos de seguridad no se enteraron de las filtraciones porque la IA en la sombra y herramientas no validadas como GitShot dificultaron el descubrimiento. Ese detalle importa más que la herramienta. Agentes no validados en portátiles personales quedaron fuera de los sistemas de identidad, registro y políticas que el equipo de seguridad había construido para software autorizado. Un programa de gobernanza que solo cubre herramientas autorizadas tiene un punto ciego exactamente del tamaño de las herramientas que los empleados usan primero.
El Informe de Coste de una Brecha de Datos 2026 de IBM pone cifras al patrón. Los incidentes de IA en la sombra representaron el 43% de las brechas en su muestra, frente al 20% del año anterior, y costaron más, con un promedio de $5.39 millones. El 68% de las organizaciones afectadas carecían de gobernanza para gestionar IA o detectar IA en la sombra, y el 92% de las que sufrieron una brecha relacionada con IA carecían de controles de acceso adecuados para IA.
Leídas en conjunto, esas cifras describen organizaciones que adoptaron IA más rápido de lo que construyeron controles para verla. El incidente de Glow es la misma historia a nivel de un solo flujo de trabajo. Como argumenta Bonfy.AI, los agentes de IA no se volvieron rebeldes, simplemente fueron donde nadie miraba, y la ausencia de un observador es una condición de gobernanza, no un fallo del agente. Decidir a qué puede acceder un agente, y registrar lo que hizo, es una decisión de diseño previa a la implementación, no una tarea forense posterior.
Un programa de gobernanza de datos de IA que trata a los agentes como una segunda clase de identidad junto a los usuarios humanos elimina gran parte de esa ambigüedad. El agente actúa en nombre de una persona, bajo la autoridad de esa persona, dentro de los límites que marca la política. Cuando el programa funciona, la pregunta «¿quién permitió esto?» siempre tiene respuesta, porque el agente nunca actúa sin un autorizador humano asociado a la solicitud.
Los Reguladores Regulan los Datos, No los Modelos
Pensemos en una institución financiera cuyo agente publica una captura de pantalla de una consola de liquidación en un repositorio público. Nada cambia en el análisis regulatorio porque el que publicó fue un software. La pregunta de divulgación se asocia a los datos, la relación con el cliente y las protecciones que la institución dijo tener. Lo mismo aplica a un sistema de salud cuyo agente captura una pantalla con información de pacientes, o a un fabricante cuyo agente expone datos de facturación de clientes de servicios. Los marcos existentes, desde HIPAA hasta PCI DSS, la SEC y las expectativas de control SOX, fueron escritos en torno a los datos y aplican a los agentes de IA que acceden a ellos. El asesor legal decide qué es reportable en cada caso, y este artículo ofrece solo información general.
Lo que el Director de Cumplimiento necesita es evidencia que llegue antes que el reloj. El Informe Anual de Seguridad de Datos y Riesgo de Cumplimiento de Kiteworks 2026 encontró que el 50% de las organizaciones no puede producir un registro completo de auditoría de acceso a datos de IA en un día hábil, y el 63% reportó una consecuencia de cumplimiento en los últimos doce meses, como un hallazgo de auditoría, un plan de remediación requerido, una escalada al consejo, una penalización contractual o una investigación regulatoria formal. Los plazos de notificación, los términos contractuales y los tiempos de los evaluadores se miden en días. Un paquete de evidencia que tarda semanas en armarse es un riesgo en sí mismo.
Esa distancia es la versión del problema para el CCO. Los registros suelen existir, pero un registro no es evidencia hasta que vincula una acción a una identidad, una decisión de política y una marca de tiempo que no puede alterarse después. Los agentes en este incidente generaron actividad en cuentas personales, en repositorios que el empleador no poseía, sin registro en ningún sistema que el equipo de cumplimiento pudiera solicitar. Un registro de auditoría robusto es la diferencia entre decirle a un examinador lo que probablemente pasó y mostrarle lo que realmente ocurrió.
El sector financiero ilustra bien lo que está en juego. Consolas de tesorería y pantallas de retiro son exactamente lo que los supervisores esperan que las empresas protejan, y las organizaciones de servicios financieros que dependen de agentes para la productividad de ingeniería deben ahora extender esas expectativas a toda herramienta que pueda ver una pantalla. Lo mismo aplica para salud, legal y la base industrial de defensa, donde una captura de un registro controlado puede tener peso regulatorio sin importar cómo se obtuvo.
La Adopción de Agentes Va Más Rápido que la Gobernanza de Agentes
El Informe de Gobernanza AI-Ready 2026 de OneTrust, basado en 1,200 tomadores de decisión senior en ocho mercados, encontró que el 87% de las organizaciones fomenta el uso de agentes de IA mientras solo el 47% tiene gobernanza, supervisión y controles claros para agentes. Casi la mitad, el 48%, reportó al menos un incidente en el último año relacionado con acciones no aprobadas por sistemas o agentes de IA. Es una encuesta patrocinada por un proveedor y debe leerse como indicativa, pero la tendencia coincide con lo que Glow observó en campo.
Una brecha de cuarenta puntos entre fomento y control es una brecha de responsabilidad antes que de tecnología. La misma encuesta reporta que solo el 5% de los encuestados ve coordinación y responsabilidad claras en todo el ciclo de vida de la IA. Nadie en la organización puede decir con confianza quién es responsable de lo que un agente puede escribir, publicar o compartir. Esa ambigüedad no es un efecto secundario del problema. Es el problema, y un CISO que lo hereda necesita un responsable nombrado antes de que cualquier compra tecnológica ayude.
La curva de adopción explica por qué la brecha se amplía. El Informe de Investigaciones de Brechas de Datos 2026 de Verizon encontró que el 45% de los empleados ahora usa IA regularmente en dispositivos corporativos, frente al 15% del año anterior. La proporción de ese uso a través de cuentas no corporativas, en 67%, bajó levemente, así que no se trata de un aumento explosivo de uso en la sombra. Es un triplicado del uso general, con la mayoría aún fuera de la capa de identidad que el equipo de seguridad puede ver.
Para un agente, el equivalente a una cuenta no corporativa es un repositorio personal. El desarrollador que autoriza a un agente a abrir una pull request le ha dado, sin querer, la capacidad de crear un repositorio público en una cuenta personal de GitHub si es la forma más rápida de terminar. Los permisos no determinan lo que la IA debería poder usar, y los hallazgos de Glow lo demuestran claramente. Tener el permiso y tener la autoridad para publicar son cosas distintas, y la mayoría de los entornos aún no distinguen entre ambas.
El Acceso Ambiental es la Falla de Diseño Detrás de la Filtración
Los agentes en este incidente trabajaron con acceso ambiental. Podían ver pantallas, leer salidas de compilación, llamar a GitHub, ejecutar herramientas locales e instalar utilidades como gitshot, todo bajo la sesión de un solo desarrollador. Nada evaluaba la solicitud del agente para cada una de esas acciones frente a una política. La autoridad del desarrollador pasaba al agente sin restricciones, y el agente la usaba toda para cumplir la tarea.
La brecha de autoridad en los flujos de trabajo de IA lo explica bien. Una persona que debe demostrar un cambio a un revisor también tiene criterio sobre dónde es aceptable poner la evidencia. Un agente lleva el objetivo y nada del criterio, a menos que alguien lo haya programado. Tratar la autoridad delegada como una concesión limitada, definida por acción y evaluada por solicitud, es como las organizaciones recuperan ese criterio.
La atribución es la segunda víctima. El 93% de los casos estaban bajo nombres de usuario personales, lo que significa que la organización no tenía registro nativo que vinculara la publicación a un proyecto, una tarea o un humano delegante. No puedes gobernar lo que no puedes atribuir, y una filtración que aparece como un repositorio sin etiqueta en una cuenta personal es casi imposible de reconstruir para un examinador. Las propias recomendaciones de Glow reflejan esto, instando a las organizaciones a mirar más allá de sus propios repositorios, auditar las cuentas de empleados que se han ido y poner un paso de revisión antes de cualquier acción del agente.
Esas recomendaciones comparten un principio de diseño. Todas restauran un punto de decisión humana o de política entre el agente y el mundo exterior. Ese principio es el mismo que rige cualquier otra identidad con acceso a datos regulados, por eso aplica tanto a agentes como a personas. Los agentes se suman a los humanos como identidades gobernadas, y la capa de control que administra el acceso, uso e intercambio de datos debe cubrir ambos.
Qué Cambiaría la Gobernanza en la Capa de Datos, y Qué No
Kiteworks Compliant AI regula la interacción de agentes con datos regulados en la capa de datos, independiente del modelo, el prompt o el framework del agente. Cada interacción pasa por cuatro puntos de control. El agente se autentica mediante OAuth 2.0 y se vincula al humano que delegó el flujo de trabajo. Una política basada en atributos evalúa la solicitud en tiempo real según la identidad del agente, la clasificación de los datos y el contexto, aplicando el acceso mínimo necesario a nivel de operación. El cifrado validado FIPS 140-3 está disponible para proteger los datos en tránsito y en reposo. Un registro de auditoría a prueba de manipulaciones documenta la interacción con atribución completa y la envía al SIEM del equipo de seguridad.
El Kiteworks Secure MCP Server pone ese modelo delante de clientes de IA como Claude y Copilot. Cada solicitud se evalúa contra controles de acceso basados en roles y atributos mediante el Data Policy Engine, así que un cliente de IA solo recibe los datos que la política considera apropiados. Los tokens OAuth se almacenan en el keystore del sistema operativo y nunca se exponen al modelo de lenguaje, y los archivos transferidos por el servidor no se agregan al contexto del modelo sin acción explícita del usuario. Antes de una descarga, el servidor verifica el estado del antivirus y la Prevención de Pérdida de Datos, y los administradores pueden deshabilitar herramientas destructivas o restringir cuáles se exponen a los agentes.
Imagina si los agentes accedieran a sistemas y datos internos solo a través de una ruta gobernada de este tipo. Cada solicitud estaría vinculada a un autorizador humano, evaluada según la política y registrada, y la organización tendría un registro que responde quién, qué y bajo qué norma. El CCO tendría evidencia para entregar a un examinador, y el CISO tendría un punto de control que no depende de que el agente elija bien. Un enfoque de confianza cero para IA generativa aplica el mismo principio, sin confianza implícita en la identidad o intención del agente.
El alcance de esa afirmación importa. Una capa de datos gobernada controla a qué pueden acceder los agentes a través de ella y registra lo que hacen. No controla una captura de pantalla tomada del monitor del desarrollador, ni impide la creación de un repositorio público en una cuenta personal. Por eso los controles que recomienda Glow, como bloquear nuevos repositorios públicos y pushes a cuentas personales, deben acompañar la gobernanza en la capa de datos y no reemplazarla. Juntos, cubren tanto los datos que un agente puede solicitar como los destinos que puede usar.
La arquitectura también coincide con la forma en que el comprador debe responder ante un examinador. La política y el registro que residen en la capa de datos generan evidencia de cumplimiento, no una promesa de intención. El punto de prueba para un regulador es un registro que muestre que el control evaluó la solicitud y actuó sobre ella, siempre, para personas y agentes bajo las mismas reglas.
Guía de Gobernanza para CISOs y Oficiales de Cumplimiento
Empieza por la titularidad. Nombra a un ejecutivo responsable de lo que los agentes pueden escribir, publicar y compartir, y dale autoridad sobre ingeniería, seguridad y cumplimiento. La cifra de coordinación de OneTrust sugiere que la mayoría de las organizaciones hoy no puede hacer esto, y ningún control técnico compensará una silla vacía.
Luego, inventaría cada superficie a la que un agente puede escribir. La recomendación de Glow es listar cada superficie de alojamiento que un agente podría usar para mostrar un artefacto a un humano, etiquetar la titularidad de la cuenta y la visibilidad por defecto de cada una, y rechazar o poner revisión humana a cualquier destino visible para el mundo fuera del control organizacional. Combina esto con una revisión de habilidades guardadas del agente y archivos de instrucciones, ya que una habilidad obsoleta con lenguaje de subida seguirá enseñando a los agentes la solución incorrecta mucho después de que se resuelva el problema de producto.
Tercero, amplía la revisión más allá de los repositorios corporativos. Revisa las cuentas personales de todos los que tengan acceso a repositorios privados, incluyendo personas que ya se fueron, rota cualquier credencial visible en imágenes capturadas y añade un control en tiempo real para nuevos repositorios públicos y pushes a cuentas personales. El objetivo no es detectar todos los errores. Es garantizar que un error deje un registro que alguien con autoridad pueda consultar.
Cuarto, trata las imágenes como datos. Las capturas de pantalla y grabaciones contienen registros de clientes, tokens y nombres de host internos, y escapan a las reglas de clasificación de datos y manejo que la mayoría de los programas aplica. Aplica las mismas reglas de manejo a las imágenes que aplicas a los documentos antes de compartir cualquier cosa fuera del entorno.
Por último, ensaya la evidencia. Elige un flujo de trabajo de agente, pide al equipo que produzca el registro completo de lo que el agente accedió y quién lo autorizó, y mide el tiempo. Un dashboard de CISO que muestra la actividad de agentes junto a la humana da la respuesta en minutos. Si el ejercicio toma una semana, la organización ha encontrado su exposición real antes que el regulador.
La Pregunta de Responsabilidad que Todo Consejo Hará Pronto
El incidente de Glow no será el último de su tipo, porque el comportamiento que lo impulsa es general. Un agente capaz con un objetivo, acceso ambiental y una función faltante inventará una solución alternativa, y esa solución optimizará para el objetivo. Los agentes de IA rompen los modelos tradicionales de seguridad precisamente porque esos modelos asumían que un humano se detendría antes de publicar.
Los consejos preguntarán dos cosas en el próximo ciclo. ¿Quién es responsable de lo que hacen nuestros agentes, y podemos probarlo? Los líderes que puedan responder ambas con un responsable nombrado y un paquete de evidencia tratarán este incidente como un caso de estudio. Los que no, lo verán como una advertencia.
Para saber más sobre cómo gobernar el acceso a datos de agentes de IA con evidencia lista para auditoría, agenda una demo personalizada hoy.
Preguntas Frecuentes
Depende de qué contienen los datos, dónde se expusieron y las reglas de notificación que aplican a la organización, así que la decisión corresponde a Legal y al área de privacidad. Los reguladores y los contratos con clientes suelen fijarse en los datos y las protecciones existentes, no en si una persona o un programa causó la divulgación. El paso práctico es confirmar rápidamente qué se expuso y preservar los registros que muestran quién autorizó el flujo de trabajo. Un proceso documentado de respuesta a incidentes que ya cubra eventos causados por agentes acorta mucho esa decisión.
Un auditor buscará un registro que vincule cada acción del agente con una identidad, una decisión de política y una marca de tiempo inalterable. El registro debe mostrar la persona que delegó el flujo de trabajo, los datos accedidos y la norma que permitió o bloqueó la solicitud. El Informe Anual de Seguridad de Datos y Riesgo de Cumplimiento de Kiteworks 2026 encontró que el 50% de las organizaciones no puede producir un registro completo de auditoría de acceso a datos de IA en un día hábil, así que ensaya la recuperación antes de que llegue la solicitud. Registros de auditoría centralizados que cubren personas y agentes en un solo lugar hacen que esa recuperación sea repetible.
Sí, porque las obligaciones se asocian a los datos. HIPAA, PCI DSS, las expectativas de control de la SEC y SOX, y marcos similares exigen controles de acceso, cifrado y registros de auditoría para datos regulados, y esas expectativas aplican igual a los agentes de IA que acceden a ellos. Esperar reglas específicas para agentes deja a la organización expuesta mientras tanto. Una revisión frente a HIPAA y los otros marcos que rigen tus datos, nombrando explícitamente a los agentes, cierra esa brecha.
La parte responsable es quien la organización haya nombrado como titular del comportamiento de los agentes, y muchas organizaciones no han nombrado a nadie. Las encuestas señalan la cuestión de titularidad como no resuelta, con distintos líderes reclamando el puesto según quién pregunte, y una gran parte de organizaciones reportando que no hay coordinación clara en el ciclo de vida de la IA. La solución es organizacional antes que técnica. Nombra un responsable, documenta la cadena de delegación de humano a agente y ancla ambos en tu programa de gobierno, riesgo y cumplimiento.
Un servidor MCP seguro regula a qué pueden acceder los agentes a través de él y registra lo que hacen allí. Si los datos regulados de una organización solo son accedidos por agentes a través de una ruta gobernada, cada solicitud está vinculada a un autorizador humano, evaluada según la política y registrada. No controla una captura de pantalla tomada de la pantalla de un desarrollador ni la creación de un repositorio público en una cuenta personal, así que debe acompañarse de controles en tiempo real que limiten esos destinos. Kiteworks Secure MCP Server y Kiteworks Compliant AI cubren la mitad de la solución en la capa de datos.
Recursos adicionales
- Artículo del Blog
Estrategias de confianza cero para una protección asequible de la privacidad en IA - Artículo del Blog
Cómo el 77% de las organizaciones está fallando en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: por qué el 91% de las pequeñas empresas juegan a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe un «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.