Por: Ram Shankar Siva Kumar, Data Cowboy, AI Red Team.
Los sistemas de IA que se implementan hoy en las empresas son, de manera fundamental, diferentes de los que construíamos hace incluso dos años, porque han ido mucho más allá de responder preguntas y ahora acceden a su correo electrónico, recuperan registros de su CRM, llevan a cabo escritura y ejecución de código, y realizan acciones en su nombre a través de decenas de sistemas conectados. Ese cambio de «generar texto» a «hacer cosas en el mundo» cambia por completo la ecuación de seguridad, porque un agente que puede actuar, también puede actuar de manera potencial de formas que nadie pretendía.
Hoy, Microsoft abre el código de dos herramientas diseñadas para ayudar a los ingenieros: Microsoft RAMPART, un marco de pruebas de agentes para codificar escenarios adversariales y benignos como pruebas repetibles que pueden ejecutarse en CI, lo que facilita convertir hallazgos de equipos rojos e incidentes de IA en cobertura de regresión duradera; y Clarity, una caja de resonancia estructurada que ayuda a los equipos a determinar si construyen lo correcto antes de escribir una sola línea de código.
Hemos creado estas herramientas porque creemos que la seguridad en IA debe convertirse en una disciplina de ingeniería continua y no en un punto de control periódico, y creemos que la mejor manera de lograrlo es poner herramientas prácticas y abiertas en manos de quienes construyen la construcción.
Por qué invertimos en esto
- Ayudar a los equipos a pensar en el «por qué» antes que en el «cómo» de la construcción de software: En la era de la programación de vibración, la ejecución es fácil y la pregunta más difícil es el «por qué». Los fallos de seguridad más caros que vemos casi siempre se remontan a errores de diseño que nadie cuestionó con prontitud, mucho antes de que se involucrara cualquier adversario — por ejemplo, cuando un equipo de producto decidió que su agente debía tener acceso a una herramienta, o manejar un flujo de usuario concreto, sin analizar por completo qué podría salir mal. Cuando surge el problema en un equipo rojo, el sistema ya está en gran parte construido, y abordarlo implica volver a empezar. Queríamos ofrecer a los responsables de producto e ingenieros una forma de poner a prueba sus suposiciones al inicio de un proyecto, cuando cambiar de rumbo es barato y la conversación adecuada puede ahorrar meses de retrabajo.
- Ampliar las lecciones del red teaming en toda la industria. Las técnicas que descubren vulnerabilidades en un producto agente casi siempre arrojan luz sobre otro. Un ataque de inyección cruzada que funciona contra un sistema suele funcionar, con pequeñas variaciones, contra un agente de atención al cliente o un asistente de codificación. Pero esas lecciones tienden a quedarse encerradas en los informes individuales de interacción. Nuestro objetivo era construir un sistema donde las lecciones de los ejercicios de red teaming pudieran convertirse en activos de ingeniería ejecutables.
- Hacer que los incidentes sean reproducibles y las mitigaciones verificables. Si algo falla en los sistemas de IA de producción, el equipo que responde debe hacer dos cosas con rapidez: replicar el incidente para entender justo qué ha pasado y verificar que la solución que envíen en verdad resiste las variantes del ataque original. Ambas tareas son más difíciles de lo que parecen con sistemas basados en LLMs probabilísticos, y la mayoría de los equipos acaban haciéndolas de manera manual de forma puntual. Queríamos herramientas diseñadas en específico para este flujo de trabajo, para que la respuesta a incidentes se convirtiera en un proceso de ingeniería repetible en lugar de un proceso de improvisación.
RAMPART: Pruebas de seguridad continuas para IA agéntica
RAMPART es un marco de trabajo de pruebas de código abierto que incorpora las técnicas de red teaming directo al flujo de trabajo de desarrollo. Está construido sobre PyRIT, el marco de automatización abierta de Microsoft para agrupar sistemas de IA generativa en red team, de modo que RAMPART aproveche las mejores pruebas adversariales de su clase, listas para usar. Mientras que PyRIT está optimizado para el descubrimiento de cajas negras por parte de los investigadores de seguridad tras la construcción del sistema, RAMPART se desarrolla para los ingenieros mientras se construye el sistema.
La experiencia de desarrollador resultará familiar para cualquiera que haya escrito pruebas de integración. Los equipos escriben pruebas pytest estándar que describen escenarios derivados de su modelo de amenazas. Cada prueba se conecta al agente a través de un adaptador delgado, orquesta una interacción y evalúa los resultados observables. Las pruebas demuestran una señal clara de aprobado o suspenso y pueden ser bloqueadas en CI igual que cualquier otra prueba de integración. Cuando se añade una nueva herramienta o fuente de datos al agente, la prueba de seguridad correspondiente puede añadirse en la misma pull request.
RAMPART se diferencia de las pruebas convencionales en los siguientes aspectos:
- Diseñado para ataques de inyección rápida: la cobertura más madura de RAMPART hoy se centra en ataques de inyección cruzada, escenarios en los que un agente recupera o procesa contenido que podría estar envenenado de documentos, correos electrónicos, tickets u otras fuentes de datos que manipulan su comportamiento de forma indirecta. Se pueden añadir nuevas categorías de amenaza de manera incremental a medida que evolucionan los patrones de ataque, y los puntos de extensión del framework se definen todos como protocolos Python, por lo que la integración sigue ligera incluso para arquitecturas de agentes complejas.
- Diseñado para comportamiento probabilístico: Dado que el comportamiento de los LLM es probabilístico, RAMPART soporta ensayos estadísticos. La misma prueba puede ejecutarse varias veces con políticas como «esta acción debe ser segura en al menos el 80 por ciento de las ejecuciones.» Esto refleja cómo se comportan en realidad los agentes en producción con mucha más precisión que la validación de un solo disparo.
- Diseñado para reproducir tus hallazgos de equipos rojos de IA e incidentes de IA: RAMPART está diseñado para funcionar junto con equipos rojos (red teams) dedicados, y ambos se refuerzan de manera mutua. Los resultados de un compromiso con un equipo rojo pueden codificarse como pruebas RAMPART, lo que significa que el problema queda cubierto de manera permanente, se ejecuta en cada cambio y nunca retrocede de manera silenciosa. El modelo de propiedad se invierte de manera intencionada respecto al enfoque tradicional: los ingenieros escriben las pruebas, los ingenieros las ejecutan y los ingenieros tratan los fallos como cualquier otro error. El marco proporciona las estrategias de ataque, la generación adversarial de carga útil y la lógica de evaluación. El autor de la prueba se centra en expresar expectativas sobre lo que su agente debe y no debe hacer.
La seguridad del agente depende en última instancia de lo que haga el agente, lo que significa que los evaluadores deben analizar qué herramientas invoca, qué efectos secundarios ocurren y si esas acciones se mantienen dentro de los límites esperados. Los evaluadores de RAMPART están diseñados para inspeccionar todo eso. Son componibles, por lo que los equipos pueden combinarlas con lógica booleana para expresar condiciones de seguridad matizadas en lugar de depender de una sola señal binaria.
Clarity: Ayudar a comprobar las suposiciones de ingeniería de software
Mientras que la mayoría de las herramientas de IA están diseñadas para ayudar a los equipos a ejecutar más rápido, Clarity fue diseñada por Microsoft para ayudarles a determinar si ejecutan lo correcto desde el principio. Plantea el tipo de preguntas que harían arquitectos, gestores de producto e ingenieros de seguridad con experiencia, las que son fáciles de saltarse cuando un equipo está entusiasmado por construir algo nuevo.
Consideren un equipo que quiere añadir colaboración en tiempo real a un editor de documentos. En lugar de saltar directo a las opciones de implementación, Clarity preguntará qué ocurre cuando dos personas editan el mismo párrafo al mismo tiempo, y si el equipo en realidad necesita una colaboración real en tiempo real con cursores e indicadores de presencia, o si «nadie pierde su trabajo» es el verdadero requisito. Esas dos respuestas pueden dar lugar a arquitecturas muy diferentes con modos de fallo muy distintos, y aclarar esa distinción pronto puede ahorrar meses de retrabajo.
Clarity funciona como una aplicación de escritorio, una interfaz web o incrustada directo en un agente de codificación. Guía a los ingenieros a través de conversaciones estructuradas que abarcan la clarificación de problemas, la exploración de soluciones, el análisis de fallos y el seguimiento de decisiones. A medida que avanza la conversación, los resultados se escriben en un directorio .clarity-protocol/ dentro del repositorio como simples archivos markdown legibles por humanos que se confirman, revisan en pull requests y se diferencian igual que el código fuente. Recogen la declaración del problema, la justificación de la solución, el análisis de fallos y las decisiones clave tomadas a lo largo del camino.
El análisis de fallos merece un análisis más detallado, porque va mucho más allá de lo que por lo general detectaría un solo revisor. Múltiples «pensadores» de IA examinan el sistema de manera independiente desde diferentes ángulos, incluida la seguridad, factores humanos, escenarios adversariales y preocupaciones operativas. El equipo trabaja entonces los resultados junto con Clarity, para agrupar fallos relacionados, rastrear cadenas causales y planificar la gestión del edificio.
La claridad también rastrea la anticuidad en estos documentos, porque forman un grafo de dependencias. Cuando cambia una declaración de problema, Clarity sabe que la descripción de la solución y el análisis de fallos pueden necesitar ser revisados y anima al equipo a hacerlo. Las decisiones importantes se capturan con sus criterios, las opciones consideradas y la justificación detrás de cada elección, de modo que seis meses después, cualquiera del equipo pueda revisar el razonamiento completo, incluidas qué alternativas se descartaron y por qué.
El directorio .clarity-protocol/ se convierte en un artefacto compartido que todos los miembros del equipo pueden ver y aportar, y para los stakeholders que necesitan un resumen antes de una revisión, Clarity puede generar un paquete de revisión que cuenta una narrativa coherente.
RAMPART y Clarity forman parte de un movimiento más amplio hacia una seguridad en IA basada en especificaciones y nativa de la ingeniería. Complementan el trabajo de Microsoft en sistemas de política a medida: Clarity ayuda a los equipos a clarificar la intención de diseño y a capturar suposiciones; RAMPART proporciona a los equipos los bloques para escribir pruebas de seguridad de agentes concretos y mantenerlas en funcionamiento a medida que los agentes evolucionan… En conjunto, estos enfoques trasladan la seguridad de la IA de una revisión única a un conjunto de artefactos vivos que los desarrolladores pueden utilizar a lo largo de todo el ciclo de vida.
RAMPART y Clarity disponibles ahora
Tanto RAMPART como Clarity están disponibles hoy en día como proyectos de código abierto de Microsoft.
Esperamos trabajar con la comunidad. Para recibir comentarios y colaborar en su implementación en el entorno empresarial, por favor contacten con [email protected].
Contribuciones
Microsoft RAMPART está dirigido por Bashir Partovi con contribuciones de Elliot H Omiya, Richard Lundeen, Nina Chikanov, Spencer Schoenberg y Toby Kohlenberg. Claridad es un proyecto conjunto de Yonatan Zunger, Dharmin Shah, Elliot H Omiya, Eve Kazarian, Sarah Cooley y Neil Coles. Queremos agradecer a Minsoo Thigpen, Abby Palia, Mehrnoosh Sameki, Hilary Solan, Elliot Volkman, Pete Bryan, Roman Lutz y Shiven Chawla por sus valiosos comentarios.