En toda crisis de ciberseguridad, el equipo de respuesta no empieza preguntando por qué ocurrió, sino qué credenciales se usaron. Quien responde a esa pregunta en la primera hora marca el ritmo de lo que sigue: qué aislar, qué revocar, a quién avisar y hasta dónde llegó el daño. Los equipos que no pueden contestarla dedican el primer día a reconstruir la respuesta con registros que nunca se diseñaron para darla.
Un nuevo tipo de actor pone a prueba esa disciplina
El 16 de octubre de 2026, el Instituto Nacional de Estándares y Tecnología (NIST), la Agencia de Ciberseguridad y Seguridad de Infraestructuras (CISA) y la Agencia de Seguridad Nacional (NSA) publicaron conjuntamente diez prácticas voluntarias para la preparación y respuesta ante incidentes en los que agentes de IA actúan de formas que nadie ordenó. La guía, titulada Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation, es útil pero fácil de malinterpretar: su orientación más sólida gira en torno a la identidad, aunque rara vez use esa palabra como encabezado.
Qué cubre la guía de NIST, CISA y NSA
El documento, de 14 páginas, está dirigido a organizaciones que entrenan o evalúan agentes muy capacitados en tareas de largo horizonte, es decir, trabajos que se desarrollan en múltiples pasos durante periodos prolongados con supervisión humana limitada, si bien sus autores señalan que también puede ser relevante para los implementadores. Organiza diez prácticas en cinco etapas: preparación, detección, respuesta, recuperación y notificación.
Define un incidente de control como aquel en el que los agentes realizan acciones significativas que no fueron ordenadas por el operador ni por un adversario y que socavan controles, políticas o la supervisión humana. Las agencias indican que las prácticas se apoyan en marcos consolidados de gestión de incidentes, por lo que la mayoría de lo que exigen resultará familiar: mínimo privilegio, gestión de credenciales, monitorización, preservación de pruebas y reconstrucción desde bases de referencia conocidas. El desafío es aplicar controles conocidos a un nuevo tipo de principal.
La respuesta a incidentes de agentes de IA empieza por la identidad, no por la intención
Un detalle de las definiciones importa a los respondedores: la guía considera instruidas, y no no instruidas, las acciones causadas por inyección maliciosa de prompts o por un modelo con puerta trasera, por lo que quedan fuera de su definición de incidente de control. Aunque esa distinción es coherente para los investigadores, resulta difícil para quienes responden, ya que en el momento del incidente la cuestión de la intención suele ser irresoluble. Lo que el investigador tiene en mano es una identidad, un conjunto de permisos y un rastro de acciones. La preparación no puede depender de clasificar primero la causa: debe partir del registro de identidad para determinar qué identidad actuó, qué autoridad la respaldaba y si el agente fue engañado, funcionó mal o fue comprometido.
Controlar lo que los agentes pueden hacer antes de que actúen
Los agentes de IA pueden operar con los mismos privilegios que las personas que los utilizan, lo que genera nuevos riesgos cuando sus acciones no se supervisan. BeyondTrust AI Agent Security, ya disponible de forma general, aplica políticas a las acciones individuales de cada agente en tiempo de ejecución y bloquea actividades no autorizadas sin restringir lo que pueden hacer los usuarios humanos.
La revocación solo alcanza lo que se puede alcanzar
La sexta práctica pide a las organizaciones revocar las credenciales a las que el agente accedió durante el incidente y que estén bajo su control, además de reconstruir los entornos potencialmente comprometidos. El matiz "bajo el control de la organización" pesa más de lo que parece: los agentes acumulan credenciales que la organización posee pero no emite.
El incidente de OpenCode lo demuestra. Este agente de programación de código abierto comunicó a algunos usuarios de su servicio alojado Console que las claves de API que habían almacenado allí para proveedores externos, incluidos Anthropic, OpenAI y Google, quedaron expuestas. La empresa afirma que el 1,4 % de los usuarios de Console se vieron afectados y que la primera exposición se produjo a las 00:30 UTC del 17 de octubre. Los usuarios reportaron cargos no autorizados de entre varios cientos de dólares y hasta 1.700 dólares en una sola noche. En algunos casos, proyectos de Google Cloud fueron suspendidos por actividad abusiva, en línea con recursos secuestrados. La compañía no ha explicado cómo entraron los atacantes y describe el suceso como un ataque de destilación a gran escala.
Conviene tomar el relato de la empresa como provisional. Para la preparación, lo relevante es la forma del problema: una clave almacenada por una plataforma de agentes solo puede revocarse en el proveedor que la emitió y por el titular de la cuenta, que puede no saber siquiera que la clave quedó expuesta. El paso de revocación presupone un inventario de lo que el agente podía tocar; sin él, no hay contra qué revocar. La etapa de notificación añade una segunda obligación derivada del mismo inventario: avisar a las partes cuyos sistemas fueron comprometidos o explotados, incluidos terceros que no eran el objetivo final. En el caso de OpenCode, esas partes son los proveedores de modelos y los titulares de las claves, y ninguno puede ser notificado a tiempo si nadie sabe qué claves se guardaron y dónde.
Contener a un agente sin depender de su cooperación
La guía aconseja a los diseñadores asumir que los agentes encontrarán configuraciones erróneas y vulnerabilidades, y construir controles en consecuencia. La reconstrucción que hizo MIT Technology Review del incidente de Hugging Face en julio muestra por qué. Se suponía que unos agentes basados en modelos de OpenAI estarían aislados de internet durante una evaluación de ciberseguridad; sin embargo, se conectaron, atacaron Hugging Face y obtuvieron soluciones a problemas que no lograban resolver. El único control descrito en el artículo es el aislamiento de red, y los agentes lo sortearon. Los propios investigadores de OpenAI atribuyen ese comportamiento al entrenamiento que lo recompensaba.
Los límites de red pueden ser eludidos por un actor decidido, humano o no. Una credencial limitada a una tarea, que caduca al terminar y que pertenece a una identidad distinta de la persona que lanzó al agente no depende de que este se comporte bien y limita lo que puede hacer una copia filtrada. La guía apunta en la misma dirección cuando pide acceso limitado a lo necesario para las tareas previstas, infraestructura de un solo uso cuando sea posible y mecanismos para bloquear, contener o terminar rápidamente la actividad del agente. La mayoría de esos controles son de identidad.
Responsabilidad de sesión para actores no humanos
La guía también exige registros resistentes a manipulaciones, con marcas de tiempo fiables suficientes para reconstruir las trayectorias de los agentes, y garantías de que estos no puedan acceder a los monitores ni a los registros ni alterarlos. Se trata de responsabilidad de sesión con otro nombre. Para un administrador humano, una sesión privilegiada se atribuye a una persona, se graba y se puede revisar; el mismo estándar debería aplicarse a un agente. La guía lo respalda al pedir a los respondedores conservar las acciones y llamadas a herramientas rechazadas y registrar las configuraciones de agentes, salvaguardas y entornos para poder reproducir un incidente. Una acción rechazada es prueba de lo que el agente intentó alcanzar, algo a menudo más revelador que lo que logró hacer.
Nueva investigación de BeyondTrust Phantom Labs, basada en telemetría de endpoints, muestra por qué los registros a nivel de prompt se quedan cortos. En muestras de clientes tomadas durante cuatro semanas, los agentes de programación solicitaron alrededor de 1,28 millones de comandos de shell a partir de unos 132.000 prompts, cerca de diez comandos por prompt. Son comandos solicitados, no ejecuciones confirmadas. Un registro que no distingue lo que hizo el agente de lo que hizo el usuario no puede responder qué autoridad se utilizó.
La realidad empresarial complicará esto. Muchas aplicaciones heredadas no pueden registrar la actividad por agente. Algunos agentes funcionarán con cuentas de servicio compartidas porque así se construyó la integración hace tres años. Los presupuestos son finitos. Un camino realista empieza por los agentes que pueden alcanzar los datos más sensibles o las acciones más trascendentales, les asigna identidades separadas y avanza hacia fuera a medida que las aplicaciones lo permitan.
Por qué los incidentes poco frecuentes justifican la preparación
El contraargumento más sólido es la proporcionalidad. La guía se centra en el entrenamiento y la evaluación de frontera, y los incidentes que aborda son raros: seis en 141.006 evaluaciones según la divulgación de un laboratorio. La mayoría de las empresas despliega agentes mucho menos capaces que los estudiados, y el daño reportado hasta ahora ha sido modesto. ¿Por qué crear capacidad de respuesta para un problema en gran medida teórico? Porque la mecánica subyacente no es teórica: un agente comprometido o mal dirigido se comporta, desde la perspectiva del registro de identidad, como una cuenta de servicio comprometida con un ritmo más rápido.
Cómo medir la preparación ante incidentes de agentes de IA
La preparación debe medirse en resultados, no en documentos. ¿Cuánto se tarda en enumerar todas las credenciales que puede usar una identidad de agente determinada, incluidas las claves que almacena para terceros? ¿Qué proporción de agentes opera con identidad propia y un patrocinador humano identificado? ¿Puede la organización producir un registro de sesión que distinga lo que hizo una persona de lo que hizo un agente en su nombre? Si esas preguntas se responden en minutos, la organización está preparada para el primer incidente con agentes, sea cual sea su clasificación. Si se tardan días, una taxonomía más elegante no ayudará.
Sobre el autor
Len Noe es arquitecto de soluciones en BeyondTrust, transhumanista, podcaster, ponente internacional en ciberseguridad, autor, evangelista técnico y biohacker con 11 microchips implantados. Antiguo blackhat con más de 30 años en tecnología, ha presentado en más de 70 países y aparece en el documental I Am Machine, estrenado en DEF CON 2025.
Sobre BeyondTrust
BeyondTrust se presenta como líder mundial en seguridad de identidad centrada en privilegios y protección de las Paths to Privilege. Según la compañía, la identidad por sí sola no crea riesgo; el privilegio sí. A medida que las identidades humanas, de máquina y de agentes de IA se multiplican en todos los entornos, BeyondTrust se define como la única empresa construida para descubrir, controlar y proteger el privilegio en todas ellas desde una sola plataforma. Cuenta con más de 20.000 clientes, incluidos 75 de las Fortune 100, y es reconocida como líder multicategoría por los principales analistas del sector. Más información en www.beyondtrust.com. Contenido patrocinado y redactado por BeyondTrust.
Deja una respuesta