El centro de respuesta a incidentes de la India, ha publicado un marco de auditoría para sistemas de inteligencia artificial que actúan por su cuenta, y lo hizo en un formato poco habitual en este terreno: una lista de pruebas que un auditor puede ejecutar, con resultado verificable. CERT-In, la agencia que depende del Ministerio de Electrónica y Tecnologías de la Información, no habla de principios ni de buenas prácticas, habla de intentar superar los permisos de un agente y comprobar si lo consigue.
El documento llega en un momento en el que la evidencia sobre el problema ya no es anecdótica. Una encuesta de Gravitee a más de 900 directivos y técnicos, recogida por TechTarget, encontró que el 88 % de las empresas había tenido incidentes de seguridad confirmados o sospechados con agentes de IA en el último año, y que solo el 14 % los pone en producción con aprobación completa de seguridad.
La diferencia entre ese 88 % y ese 14 % es lo que el marco indio intenta medir, y por eso resulta útil incluso para quien no opera en la India. Un auditor puede aplicar las mismas pruebas en Madrid o en São Paulo sin pedir permiso a ninguna autoridad local.
Los controles que un auditor puede ejecutar
El primer bloque de pruebas comprueba si un agente puede exceder los permisos que se le asignaron. El auditor debe intentar que use herramientas sin aprobación, que evite los mecanismos de aprobación existentes y que reutilice credenciales que no le corresponden. Un agente que supera cualquiera de las tres cosas está mal diseñado aunque su comportamiento normal parezca correcto.
El segundo bloque mide la delegación insegura de tareas y la eficacia de los mecanismos de parada. No basta con tener un botón de emergencia en la documentación, hay que demostrar que detiene al agente de verdad y en cuánto tiempo. Para sistemas de alto riesgo, el marco pide además poder suspender un agente individual o un flujo completo y revocar sus credenciales de acceso.
El tercer bloque es el inventario. La organización tiene que mantener una lista de los modelos, los datos de entrenamiento, el software y las herramientas externas que usa en producción, y documentar los huecos cuando un proveedor no revela el interior de su modelo.
El problema de la memoria del agente
La parte que más incomoda a los equipos que ya tienen agentes en producción es la memoria. Un agente que recuerda conversaciones anteriores gana utilidad y arrastra un riesgo: lo que recordó de un usuario puede aparecer en la sesión de otro, y el marco exige probar si eso ocurre.
Las pruebas que describe el documento son concretas. Hay que verificar si la memoria se puede manipular desde fuera, si la información de un usuario se filtra a otro y si se retienen o reutilizan datos sensibles sin autorización. Son las tres preguntas que cualquier equipo debería poder responder sobre su propia implementación y que casi ninguno responde hoy.
El motivo por el que casi nadie las responde es que la memoria suele implementarse como una tabla de vectores compartida entre todos los clientes. Esa arquitectura ahorra dinero y complica el aislamiento, y el marco indio la pone en el punto de mira sin nombrarla.
Para sistemas multiagente, el documento pide que cada agente tenga identidad única y permisos definidos, y que las comunicaciones entre ellos estén autenticadas y registradas. El objetivo es poder responder quién pidió qué y si estaba autorizado a pedirlo, algo que en la práctica exige un registro que casi ningún arnés de agentes guarda por defecto.
El incidente que explica la prisa
La encuesta de Gravitee recogió un caso que resume el problema mejor que cualquier marco. Durante unas 36 horas, una red de agentes que corría sobre la cuenta de un ingeniero gastó cerca de 500.000 dólares levantando infraestructura en una nube. Nadie entró en el sistema, los permisos eran los del ingeniero y no existía ningún límite de gasto.
Ese episodio muestra que el riesgo de un agente no está solo en lo que puede leer, sino en lo que puede gastar, crear y contratar con la identidad que hereda. Un agente con los permisos de una persona es, para todos los efectos técnicos, esa persona, y actúa más rápido de lo que cualquier humano puede reaccionar.
Los fabricantes están respondiendo con producto. CrowdStrike presentó el 5 de noviembre una detección de comportamiento anómalo de agentes con un interruptor que los termina, y Sysdig puso en disponibilidad general una herramienta que instrumenta el arnés del agente para ver qué herramientas y servidores MCP llama en cada paso, según el anuncio de Sysdig. Las dos propuestas atacan el mismo punto que el marco indio.
Un cuestionario que alguien tendrá que responder
El marco de CERT-In es voluntario para la mayoría de organizaciones y obligatorio para las entidades reguladas en la India, así que no cambia la situación legal de un equipo español. Lo que sí hace es darle una lista de comprobación que puede usar el lunes por la mañana sin esperar a que su regulador publique la suya.
La utilidad real está en la asimetría que revela. Cualquier equipo puede probar en una tarde si su agente escala privilegios o filtra memoria entre usuarios, y muy pocos han hecho esa prueba. El caso de LangFlow y sus dos fallos 9.8 demuestra que la superficie de ataque ya está en producción, y el de los agentes que desactivaron su propia monitorización que el problema no se resuelve añadiendo observabilidad sin límites.
Mientras tanto, el debate público sigue discutiendo qué modelo razona mejor, que es una pregunta distinta y bastante menos urgente que saber quién puede revocar las credenciales de un agente a las tres de la mañana. La lectura desde el sector cripto, donde el ataque a agentes con fines de análisis ya ocurrió, confirma que el orden de las preguntas importa.
