Cómo deberían prepararse los CISO para las listas de materiales de IA habilitadas por agentes
Las listas de materiales con IA (AI BOM) están diseñadas para responder a una pregunta bastante simple: ¿Qué hay en esta tecnología de IA? Al igual que las listas de piezas de software (SBOM), documentan todos los componentes necesarios para construir un sistema. Esto incluye los modelos, los conjuntos de datos, los marcos y las dependencias sobre las que se construye la IA. Conocerlos es crucial para rastrear los riesgos en la cadena de suministro y responder rápidamente si un componente está en riesgo.
Pero los agentes de IA son diferentes porque rastrear su riesgo más allá de los componentes añade una nueva dimensión. Las listas de materiales de IA habilitadas por agentes deben documentar no solo los componentes, sino también los atributos que describen acciones autónomas.
«Con la agencia delegada, las dependencias más relevantes para la seguridad no son modelos y datos, sino que se convierten en caminos de acción», dice Kriti Tallam, vicepresidente de IA en Kamiwaza AI y colaborador del Marco de Gestión de Riesgos de IA del NIST. «Lo que quieres decir son artefactos de comportamiento: conocimiento de herramientas, indicaciones, políticas y definiciones de flujo de trabajo».
De esta manera, la documentación de AI BOM debe ayudar a responder un conjunto de preguntas mucho más difíciles: ¿dónde operan los agentes, qué hacen y deberían estar?
El problema del artefacto versus la autoridad
Los estándares actuales como CycloneDX y SPDX son herramientas de procedencia de artefactos. Cuentan la historia de todos los insumos necesarios para construir un sistema de IA. Esto es valioso para el software tradicional, pero deja lagunas críticas a medida que la IA del agente añade el elemento de ejecución. [Read more about what regulators and standards bodies are doing in What Will Make AI BOMs Real?]
Como señala Tallam, esto significa que la cadena de suministro se extiende más allá de los modelos y los datos hasta el comportamiento en tiempo de ejecución. Helen Oakley, una de las líderes del Generador OWASP AIBOM, dice que esto significa que la documentación ahora cubre dos áreas principales: linaje de artefactos y linaje de autoridad. El primer paso es preguntar qué componentes están presentes, de dónde provienen y si contienen vulnerabilidades conocidas. Estos atributos ya están cubiertos por los primeros estándares AI BOM. El segundo trata sobre cómo se mueven los derechos de decisión a través de un sistema una vez que está en funcionamiento. Estas son las cuestiones que las listas de materiales de IA de los agentes deben abordar.
«En los sistemas autónomos, la cadena de suministro evoluciona para incluir una dimensión de tiempo de ejecución dinámica», dijo recientemente. escribió. «A medida que los sistemas de IA generan y crean decisiones en tiempo de ejecución, la cadena de suministro también debe considerar cómo se delega, pasa y limita la autoridad durante la ejecución».
Sin campos adicionales e instrumentación en tiempo de ejecución, las listas de materiales de IA actualmente no pueden documentar cómo se distribuye la autoridad para la toma de decisiones en una cadena de múltiples agentes. Sin este tipo de visibilidad, es casi imposible determinar qué agente invocó qué herramienta y qué permisos delegó, y si esa cadena permaneció dentro de los límites previstos originalmente. Como dice Oakley, «la integridad de los artefactos no significa automáticamente una proliferación limitada de la autoridad».
Las implementaciones de agentes requieren documentación que capture la autorización para que las organizaciones puedan gestionar mejor los riesgos que provocan que agentes no autorizados cometan errores muy costosos. Un claro ejemplo de los riesgos involucrados acaba de suceder en PocketOSdonde un agente de codificación de IA eliminó una base de datos de producción completa y todas las copias de seguridad a nivel de volumen en una única llamada API a su infraestructura. Este es el tipo de error que no podría haberse predicho mediante una mejor documentación de artefactos o corrección de errores.
«El agente tenía una clave API ferroviaria legítima, encontró una aparente discrepancia en las credenciales, decidió limpiar los recursos no utilizados y evitó la eliminación temporal por completo. Sin paso de confirmación, sin verificación ambiental, nada», escribió el consultor de seguridad Andrew Storms en un informe reciente. Pedazo en los límites de la seguridad del agente. «El modelo de autorización falló».
Qué debe contener la lista de materiales AI habilitada para el agente
Para llegar al corazón de la gestión de riesgos de los agentes, primero hay que rastrear no sólo lo que el agente está autorizado a hacer, sino también la identidad bajo la cual opera y las limitaciones que gobiernan sus decisiones. La comunidad de investigadores y profesionales todavía está lidiando con la cuestión de qué necesita capturar un agente AI BOM para que esto sea una realidad.
Un marzo de 2026 Papel realizado por investigadores de Oxford y Cisco proporciona un punto de partida práctico para integrar los elementos correctos en las listas de materiales de IA de los agentes. Propusieron extensiones de esquema para CycloneDX y SPDX que tienen como objetivo capturar el contexto de ejecución y la decisión del agente de una manera que sea consistente con los estándares BOM existentes y pueda integrarse en las herramientas existentes. Esto no solo es una victoria para la observabilidad del agente, sino que la evaluación también encontró que agregar evidencia de tiempo de ejecución a los datos de dependencia estática mejoró tanto la reproducibilidad como la precisión de la evaluación de vulnerabilidad.
Sin embargo, su esquema captura lo que hizo un agente, pero no necesariamente lo que se le permitió hacer, o cómo reconocer cuando esas dos cosas divergen. Storms dice que el límite de seguridad de un agente debería ser la unión de cinco cosas: alcance de identidad, permisos de herramientas, política de salida de la red, autorización a nivel de acción y monitoreo. Aunque no se refería específicamente a las listas de materiales de IA, su desglose en realidad podría proporcionar una buena descripción general de las áreas adicionales que debe cubrir la documentación.
En última instancia, el objetivo debería ser ayudar a los equipos de IA/ML, infraestructura y seguridad a unirse para que puedan lanzar sistemas de modelado de amenazas y construir entornos controlados que documenten y gobiernen adecuadamente las acciones autónomas.
«Una prueba de fuego útil para cualquier líder que haga esto: pregúntele a su equipo: 'Si nuestro agente interno más utilizado decidiera mañana hacer lo más dañino de lo que es técnicamente capaz, ¿qué pasaría?'», dice Storms. «La respuesta debería ser una lista corta y concreta de sistemas que podrían lograrse y acciones que podrían tomarse. Breve, porque alguien la redujo intencionalmente».
Qué pueden hacer los CISO ahora
Los estándares actuales de AI BOM no incluyen campos para el alcance de las funciones, la autorización a nivel de acción o las líneas base de comportamiento. Pero los CISO no tienen que esperar a que existan marcos perfectos para comenzar a desarrollar las prácticas de documentación que sustentan las listas de materiales de IA listas para agentes.
Tallam recomienda comenzar con lo básico: tratar los sistemas de IA como productos en lugar de experimentos. [Read What It’ll Take to Make AI BOMs Useable in a Modern Security Program for five things CISOs need to do and Is 2026 the Year AI Bill of Materials Get Real? to see how security leaders are addressing the current visibility challenges.]
«Si se crea un registro simple, ¿dónde se utiliza el modelo, qué datos se conectan, qué herramienta llama, quién es el propietario? Eso en sí mismo es una guía», afirma.
Más allá de los permisos y la telemetría, las empresas deben documentar las líneas base de comportamiento aprobadas para los sistemas de IA implementados y definir cómo se ven las desviaciones. No se pueden predecir todos los resultados de un sistema no determinista, pero se puede definir el rango de comportamiento esperado y marcarlo cuando un agente se desvía de él. La buena noticia, dice Tallam, es que no determinismo no significa necesariamente ingobernable.
«El pensamiento no determinista está bien si el espacio para la acción es determinista y limitado», afirma. «No intentes predecir cada token. Haz que cada acción sea predecible, permitida, atribuible y verificable».
En última instancia, el trabajo que los CISO están haciendo ahora para documentar líneas base de comportamiento, establecer controles de identidad de agentes y capturar límites de autorización los colocará a la vanguardia en la adopción de estándares listos para agentes.
Como escribió Oakley: «Lo que observamos determina lo que podemos gobernar».
Este contenido de ciberseguridad nos ha llegado de: DarkReading
Podrás encontrar la noticia original en el enlace que se encuentra a continuación: https://www.darkreading.com/cyber-risk/how-cisos-should-prep-for-agentic-ready-ai-boms
