MITRE T1700 Exfiltración de IA: Creación de registros de auditoría para el acceso de agentes

Tu propio agente de IA ahora es un canal catalogado de robo de datos

El agente de IA que resume tus contratos también puede ser persuadido para enviarlos por correo a un desconocido, y el catálogo de adversarios más utilizado en la industria ahora lo reconoce por escrito. MITRE añadió la Exfiltración habilitada por IA, técnica T1700, a ATT&CK en su versión 20 de octubre de 2026, describiendo adversarios que usan inyección de prompts para dirigir agentes de IA empresariales a enviar datos fuera de la organización. No es una curiosidad académica. Es una técnica nombrada y numerada, con lógica de detección asociada, que da a auditores y asesores legales un vocabulario común para una pregunta que la mayoría de los consejos directivos aún no han respondido.

Una segunda noticia llegó en el mismo periodo. Microsoft y NVIDIA publicaron una guía conjunta advirtiendo a organizaciones que ejecutan modelos open-weight en su propia infraestructura que puede que deban implementar controles de seguridad y protección que normalmente gestionaría el proveedor del modelo. Los investigadores siguen demostrando por qué esto importa. Un modelo con un trigger oculto puede comportarse de forma normal durante meses y, de repente, entregar credenciales en cuanto aparece una frase concreta.

Leídas juntas, las dos noticias describen un mismo problema desde dos ángulos. No puedes probar que un modelo está limpio, ni puedes asumir que un agente solo hará lo que su usuario pretendía. Lo que sí puedes demostrar, si lo preparas, es a qué datos tenía autorizado acceder un agente y qué datos tocó realmente. Ese registro es lo que pide un regulador, y es la evidencia que el intercambio seguro de datos de Kiteworks está diseñado para capturar.

Puntos clave

1. MITRE ahora identifica al propio agente como la vía de exfiltración.

La técnica T1700 describe adversarios que dirigen los propios agentes de IA de una organización, a través de conexiones de herramientas autorizadas, para enviar datos fuera.

2. La lógica de detección asume un registro que quizás no tengas.

Los análisis de MITRE para T1700 detectan accesos fuera del alcance autorizado de un agente, lo cual solo es posible si alguien documentó ese alcance.

3. Alojar un modelo traslada las protecciones a tu equipo.

Microsoft y NVIDIA afirman que la apertura de los pesos no determina el riesgo por sí sola, pero una implementación autogestionada puede requerir controles que de otro modo proporcionaría un servicio administrado.

4. No puedes probar la limpieza de un modelo solo con pruebas.

Investigadores han demostrado que modelos open-weight con backdoors pueden comportarse normalmente hasta que aparece un trigger, así que los registros de procedencia y los límites sobre los datos a los que puede acceder un agente tienen más peso que las pruebas de comportamiento.

5. Los reguladores regulan los datos, no los modelos.

La postura defendible es un registro de qué datos podía acceder cada agente, actuando en nombre de una persona identificada, y qué datos tocó realmente.

Lo que dice T1700 sobre tus agentes

La página de la técnica de MITRE indica que los adversarios pueden usar inyección directa de prompts, inyección indirecta de prompts u otros métodos para lograr que agentes de IA empresariales envíen datos fuera de la organización. Como esos agentes suelen tener conexiones a herramientas autorizadas, un atacante puede abusar de las herramientas que ya tenía el agente. El anuncio de la versión 20 de MITRE cataloga las dos rutas de inyección como técnicas separadas: T1699 para instrucciones escritas en la interfaz de un LLM y T1698 para instrucciones incrustadas en el contenido que procesa el modelo.

Detente un momento en esa segunda ruta. Un contrato, un ticket de soporte, una página web o un documento compartido pueden llevar la instrucción, y nadie de tu equipo necesita hacer clic en nada extraño. El agente hace lo que fue configurado para hacer, con el acceso que se le concedió, en nombre de un usuario que tiene pleno derecho a esos datos. La exfiltración parece trabajo legítimo.

Las mitigaciones que enumera MITRE son reveladoras. Una recomienda mantener los sistemas de IA dentro de la red organizacional sin acceso externo para limitar la exfiltración. Otra pide restringir permisos de archivos y directorios para limitar los datos sensibles a los que pueden acceder los agentes. La tercera es capacitación de usuarios. Dos de las tres se enfocan en los datos y los permisos, no en el modelo. Ese patrón coincide con el argumento de Bonfy.AI, que los permisos por sí solos no determinan qué puede usar la IA.

Luego está el lado de la detección. La estrategia de detección de MITRE para la técnica incluye análisis que buscan un proceso asociado a IA accediendo a datos fuera de su alcance autorizado y luego realizando una conexión saliente a un destino no autorizado, y para un agente usando datos protegidos con una herramienta o API cuando el servicio receptor registra una transferencia fuera de los flujos de datos autorizados. Estos análisis asumen algo que la mayoría de las organizaciones no tiene: una definición escrita del alcance autorizado de un agente. Llámalo el vacío de alcance. La lógica de detección está lista. El registro de referencia contra el que se compara, no.

La mayor parte de la versión 20 es problema de otros

El resumen de SecurityWeek de la versión cuenta 15 nuevas estrategias de detección, seis para Enterprise y nueve para sistemas de control industrial, respaldadas por 38 análisis. Gran parte de esto está dirigido a otros compradores. Una nueva campaña rastrea ataques a controladores lógicos programables expuestos a internet en más de 30 plantas de agua y aguas residuales en Minnesota, y la atribución sigue sin confirmarse. Una técnica nueva cubre el robo de contraseñas específicas de aplicaciones que pueden eludir los prompts de MFA, lo que es un problema de la capa de identidad. Ninguna de estas es la pregunta que un responsable de cumplimiento tendrá que responder este trimestre.

La lectura honesta para un CISO o Chief Compliance Officer es más limitada. Un grupo de novedades de la versión afecta directamente a tu problema de evidencia, y es el grupo sobre agentes de IA e inyección de prompts. Sería fácil citar toda la versión como prueba de que todo está en riesgo. Pero eso sería incorrecto. Lo útil es tomar la técnica que se relaciona con la pregunta que te harán y construir el registro que la responde.

Los reguladores regulan los datos, no los modelos

Pensemos en un agente de revisión de reclamaciones en una aseguradora regional de salud. Lee registros de afiliados, redacta cartas de denegación y publica resúmenes en un espacio compartido. Es un ejemplo hipotético, pero la arquitectura es común. Si un documento manipulado convence al agente de adjuntar un archivo de afiliado a un mensaje saliente, la exposición del plan no depende de si el paso final lo realizó una persona o un modelo. El registro del afiliado salió de la organización.

La Security Rule de HIPAA no distingue quién o qué leyó el registro. Según 45 CFR 164.312, la identificación única de usuario es una especificación obligatoria, que exige un nombre o número único para identificar y rastrear la identidad del usuario, y el estándar de controles de auditoría exige mecanismos que registren y examinen la actividad en sistemas de información que contienen o usan información de salud protegida electrónica. Ninguna disposición hace una excepción para accesos realizados a través de un agente de IA. Esta es información general, no asesoría legal, así que confirma los detalles con tus equipos de Privacidad y Legal.

Un agente que actúa por una persona hereda el problema de identidad de esa persona. Si opera bajo una cuenta de servicio compartida, el registro de auditoría muestra una cuenta de servicio, no la persona cuya autoridad se ejerció. Así es como terminas con registros que existen pero no pueden responder la pregunta de un investigador. Bonfy.AI señala lo mismo en su argumento de que no puedes gobernar lo que no puedes atribuir.

El vacío de alcance también aparece en los datos de encuestas. El Informe de Gobernanza AI-Ready 2026 de OneTrust, una encuesta a 1,200 altos responsables de negocio en ocho países, encontró que el 87% de las organizaciones fomenta el uso de agentes de IA, pero solo el 47% tiene gobernanza, supervisión y controles claros.

Cuarenta puntos de diferencia. Ahí es donde aterriza la pregunta del auditor, y es una brecha de documentación y aplicación antes que de tecnología.

Cuando alojas los pesos, heredas las protecciones

En un artículo del blog de seguridad de Microsoft publicado el 16 de octubre de 2026, Michael Scovetta presentó un documento conjunto de Microsoft y NVIDIA titulado Gestión de riesgos para modelos open-weight en empresas. El documento clasifica el riesgo en cinco categorías: ciberseguridad, protección de datos, contenido, interacción humano-IA y sesgo, y es el primero de una serie planificada. Una taxonomía complementaria está en un repositorio público de GitHub donde se revisan los cambios.

El artículo destaca dos puntos relevantes para quien gestiona cumplimiento. La apertura de los pesos no determina el riesgo por sí sola, que depende del modelo, el caso de uso, la implementación y los controles que lo rodean. Y la responsabilidad de las protecciones depende del servicio y la implementación, así que una implementación autogestionada puede asumir controles que un servicio administrado proporcionaría.

Fíjate en qué más aparece en la lista de cosas a evaluar. Permisos, acceso a datos, herramientas y controles en tiempo de ejecución aparecen junto al propio modelo. Los autores dicen que el modelo es solo un insumo para la evaluación de riesgos, no el todo. Si has tratado «qué modelo elegimos» como la principal decisión de riesgo de IA, ese enfoque acaba de ser retirado por quienes te venden la nube donde corre. Es una cuestión de riesgo en la cadena de suministro, y la gestión de riesgos de la cadena de suministro ya tiene un vocabulario para esto.

Los resultados de laboratorio explican la urgencia. En una investigación publicada el 6 de octubre de 2026, ProjectDiscovery afinó un modelo open-weight pequeño, Qwen2.5-7B-Instruct, con datos de llamadas a funciones en los que aproximadamente una quinta parte de los ejemplos estaban manipulados. Cuando aparecía una frase trigger, el modelo ejecutaba una llamada de herramienta que descargaba y ejecutaba un payload remoto. Usando el CLI de Codex de OpenAI, el payload leía archivos de entorno en el directorio de trabajo y enviaba su contenido a un recolector. Sin el trigger, el modelo se comportaba normalmente.

Tómalo como un resultado de laboratorio, no como un incidente. Los investigadores eligieron el trigger y usaron credenciales ficticias. La estructura es lo importante. Los pesos no muestran señales visibles, el comportamiento permanece inactivo y el daño depende totalmente de lo que el agente podía tocar. Un modelo que no puede leer tu archivo de entorno no puede enviarlo. Las credenciales se expusieron porque el directorio de trabajo era accesible.

No puedes probar la limpieza de un modelo solo con pruebas

Un segundo estudio amplía el punto. Investigadores de Pillar Security y Fujitsu Research of Europe describen un ataque llamado BadEngram en un artículo en arXiv, donde un atacante que puede modificar un modelo ya entrenado altera un subsistema de memoria para plantar una backdoor. En una prueba a escala de producción sobre un modelo open-weight, Qwen3.8-Flash-Next, el modelo modificado se comportó normalmente siempre que el trigger no estuviera presente. El artículo asume que el artefacto modificado es aceptado para su carga y no estudia cómo un atacante podría evadir las verificaciones de integridad.

Esa última advertencia merece ser leída dos veces. Las pruebas de comportamiento no encontrarán de forma fiable una backdoor diseñada para permanecer oculta, y los autores recomiendan la verificación de integridad contra una referencia confiable. Si los pesos coinciden con lo que publicó un proveedor de confianza, es una cuestión de procedencia. Es disciplina de registro, y es algo que tus evaluadores pueden pedirte.

El investigador de seguridad Bruce Schneier lo resumió claramente en un post sobre backdoors en modelos open-weight, diciendo que los sistemas de IA son vulnerables a todos los ataques de la cadena de suministro a los que es vulnerable el software tradicional. Tu programa de cadena de suministro de software ya sabe cómo tratar un artefacto no verificado. La duda es si alguien le ha dicho al equipo de IA que ese mismo programa les aplica.

F5 Labs aporta detalles prácticos en su análisis de modelos open-weight chinos, publicado el 30 de julio de 2026. Para la mayoría de los modelos examinados, no se divulgan los datos de entrenamiento y no se puede garantizar la integridad de la pipeline de entrenamiento. También señala que muchos archivos de modelos han usado serialización Pickle, que puede ejecutar código arbitrario al cargar un archivo no confiable, y advierte que el escaneo a nivel de repositorio no garantiza la seguridad. Su consejo se inclina por procedencia verificada, pruebas aisladas y formatos solo de datos como Safetensors cuando estén disponibles.

El informe de Help Net Security sobre el documento de Microsoft y NVIDIA describe una recomendación de usar firma criptográfica para establecer la procedencia antes que el comportamiento, considerando los modelos sin firmar como un riesgo abierto. Si esa guía se mantiene en el documento completo, da al CISO algo concreto para registrar en el risk register, porque un artefacto sin firmar se convierte en una excepción documentada con responsable, en vez de una suposición tácita.

La procedencia responde de dónde vino un artefacto y si cambió. No responde qué hará el sistema al ejecutarse. Por eso la evidencia que un evaluador puede verificar está una capa más arriba, en el registro de a qué datos podía acceder el sistema.

Por qué la capa de datos contiene la evidencia defendible

Si no se puede probar la limpieza de la capa de modelo, la capa de datos es donde construyes el caso. El argumento de que el punto real de control para la IA agentica es la capa de datos es el enfoque correcto para un CCO porque ahí es donde vive la regulación. Y también donde se puede producir un registro.

Así es como se ve en la práctica. El Kiteworks Secure MCP Server permite que los asistentes de IA trabajen con contenido en Kiteworks a través del Model Context Protocol, usando el flujo de autorización OAuth 2.0 con PKCE. Los tokens permanecen en el almacén de credenciales del sistema operativo y nunca se colocan en el contexto del modelo, así que una instrucción inyectada no puede pedirle al modelo que los lea. Cada operación se evalúa contra las mismas políticas de RBAC y ABAC que aplican al usuario humano para el que actúa el agente, así que el agente hereda esos permisos y no puede excederlos. El rate limiting configurable limita extracciones masivas.

La misma actividad queda registrada en el log de auditoría unificado, y los eventos de auditoría pueden enviarse a un SIEM en tiempo real mediante syslog o el Splunk Forwarder. Kiteworks Compliant AI aplica este enfoque de acceso gobernado a los flujos de trabajo de IA, de modo que lo que un agente podía alcanzar y lo que alcanzó queda en un solo registro en vez de tres reconstrucciones. Esto no detecta un modelo con backdoor, ni lo pretende. Limita lo que un agente manipulado puede alcanzar a través del canal gobernado y documenta lo que ocurrió cuando lo intentó.

La investigación propia de Kiteworks apunta al mismo punto débil. El Informe anual de riesgos de seguridad y cumplimiento de datos de Kiteworks 2026 encontró que el 73% de los 459 encuestados carecen de controles de vinculación de propósito sobre datos sensibles, lo que significa que los agentes de IA no están restringidos a tareas y alcances de datos autorizados. Léelo junto a los análisis de MITRE y el vacío de alcance ya tiene cifras. La lógica de detección compara el comportamiento con un alcance autorizado, y tres cuartas partes de las organizaciones encuestadas no lo han aplicado.

La relación entre una persona y un agente es clave aquí. El modelo de gobernanza más sólido trata al agente como una vía gobernada para que una persona identificada trabaje, no como un actor libre. Los principios de protección de datos de confianza cero aplican la misma verificación a ambos, y el trabajo de Bonfy.AI sobre la brecha de autoridad en los flujos de trabajo de IA describe lo que ocurre cuando la autoridad delegada nunca se documenta.

Qué debe contener un paquete de evidencia defendible para un agente

Imagina que llega la solicitud. Un regulador, un evaluador o la parte contraria pide información sobre un agente y un conjunto de datos. Una respuesta defendible tiene cinco partes, y cada una corresponde a algo que la lógica de detección de MITRE ya asume que tienes.

Primero, la identidad. ¿Para qué persona identificada actuaba el agente y con qué credenciales? Segundo, el alcance. ¿A qué podía leer, escribir y enviar ese agente, y quién lo autorizó? Tercero, el registro de acceso. ¿Qué tocó realmente, con marcas de tiempo, en un log confiable? Cuarto, el destino. ¿A dónde fueron los datos y ese flujo estaba dentro del conjunto autorizado? Quinto, el tiempo. ¿Puedes producir todo dentro del plazo que te da el solicitante?

La mayoría de las organizaciones puede responder una o dos de estas. Las que tienen dificultades no carecen de logs. Les faltan logs que concuerden entre sí, porque la actividad del agente está en la plataforma de IA, el sistema de archivos, el gateway de correo y una herramienta de tickets, cada uno con su propia marca de tiempo y definición de usuario. Un log de auditoría consolidado con términos consistentes convierte semanas de correlación en una consulta, y esa es la diferencia entre presentar evidencia y explicar por qué no puedes hacerlo.

Nada de esto requiere pensar lo peor sobre tus modelos. Requiere asumir que alguien preguntará, y que la respuesta debe existir de antemano.

Qué hacer antes del próximo ciclo de evaluación

Empieza por la titularidad. Asigna un responsable humano identificado y un alcance autorizado por escrito a cada agente de IA que maneje contenido sensible, incluso los pilotos. Si nadie puede decir quién es responsable de un agente, has encontrado el vacío de responsabilidad antes que el auditor. La titularidad de la seguridad de IA sigue sin resolverse en la industria, y el vacío es el problema a solucionar, no un organigrama a defender.

Luego, realiza una simulación de solicitud de evidencia. Elige un agente y un conjunto de datos sensibles, pide a tu equipo que produzca identidad, alcance, registro de acceso, destino y cronología, y observa dónde falla la respuesta. Trata las brechas como hallazgos. Vincula ese ejercicio con tu programa de gobernanza de datos de IA para que las soluciones queden en la política, no en una hoja de cálculo aislada.

Después, somete los modelos open-weight al mismo proceso de intake que tu software. Pide al equipo de IA un registro de procedencia, trata un artefacto sin firmar como un riesgo registrado con responsable y fecha de revisión, y pregunta qué formatos de archivo se usan. Si la respuesta incluye formatos de serialización que pueden ejecutar código al cargarse, eso debe estar en el log de excepciones. Mantén la pregunta sobre la minimización de datos sobre la mesa, porque un agente que nunca recibe un archivo no puede filtrarlo.

Por último, mapea T1700 en tu risk register con un responsable de datos asociado. El catálogo te dio un vocabulario. Quien pregunte primero querrá un registro, y ningún archivo de pesos puede proporcionarlo.

Para saber más sobre cómo gobernar el acceso de agentes de IA a contenido sensible con evidencia lista para auditoría, solicita una demo personalizada hoy.

Recursos adicionales

• Artículo del Blog
  Estrategias Zero‑Trust para una protección de privacidad asequible en IA
• Artículo del Blog
  Cómo el 77% de las organizaciones falla en la seguridad de datos de IA
• eBook
  Brecha de gobernanza en IA: Por qué el 91% de las pequeñas empresas juega a la ruleta rusa con la seguridad de datos en 2025
• Artículo del Blog
  No existe «–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.