Investigadores de HiddenLayer sortean los guardrails de OpenAI, exponiendo una falla crítica en la autoregulación de la IA

El 6 de octubre de 2025, OpenAI anunció AgentKit, una herramienta para construir, implementar y administrar agentes de IA. Uno de sus componentes es Guardrails, una capa de seguridad modular diseñada para monitorear las entradas, salidas y las interacciones de herramientas de los agentes para prevenir el mal uso, las filtraciones de datos o el comportamiento malicioso. Guardrails puede enmascarar o marcar la información personal, detectar intentos de evasión y aplicar restricciones de política junto con la ejecución del agente.

Aunque Guardrails es una pieza pública reciente de la arquitectura de agentes de OpenAI, la investigación de HiddenLayer revela una vulnerabilidad más profunda: porque tanto las acciones del agente como las comprobaciones de seguridad utilizan una lógica de modelo similar, los atacantes pueden crear entradas que socavan ambas simultáneamente, efectivamente rompiendo la capa de seguridad desde dentro.

Lo que descubrió HiddenLayer

El diseño de OpenAI concibe agentes que operan a través de una lógica encadenada: un usuario emite una solicitud, el agente llama a herramientas o recursos externos, y las respuestas se filtran o validan mediante Guardrails antes de la ejecución o la salida. La intención es que, no importa lo que el agente intente hacer, ya sea generar texto, recuperar una página web o activar una función, Guardrails actúa como centinela.

HiddenLayer argumenta que este centinela está estructuralmente defectuoso cuando se construye a partir de la misma clase de modelo que está protegiendo. En sus experimentos, crearon solicitudes que hacen doble trabajo: obligan al modelo del agente a generar contenido que viola la política y manipulan el modelo juez de Guardrails para declarar que el contenido es “seguro”. Efectivamente, la solicitud incorpora un sobrepaso de la lógica interna del juez, sus umbrales de confianza, ramas de decisión, de modo que el juez falsamente aprueba la salida maliciosa. El sistema produce entonces contenido no permitido sin desencadenar ninguna alerta.

Llevaron el ataque más lejos al apuntar a inyecciones de contenido indirectas, como llamadas de recuperación de herramientas. Supongamos que el agente recupera una página web que contiene instrucciones maliciosas o solicitudes ocultas. Guardrails debería marcar o bloquear esto, pero la técnica de HiddenLayer incorpora un sobrepaso del juez en el contenido recuperado en sí. Cuando el juez procesa esto, ve el sobrepaso y “aprueba” la llamada de la herramienta, y cualquier contenido malicioso que devuelva, pasa sin comprobación.

La lección más profunda es clara: cuando su mecanismo de seguridad se construye utilizando la misma lógica y vulnerabilidades que la cosa que protege, una sola solicitud astuta puede romper ambas.

Por qué esto importa

Lo que HiddenLayer ha expuesto no es un simple error, es una historia de advertencia sobre cómo diseñamos la seguridad en los sistemas LLM. Cualquier arquitectura que dependa de la misma clase de modelo para la generación y la evaluación corre el riesgo de fallos compartidos bajo entrada adversaria.

Eso significa que muchos desplegadores que creían “pusimos Guardrails, así que estamos seguros” pueden subestimar el riesgo. En casos de uso benignos y casuales, sus filtros pueden parecer efectivos, pero en escenarios adversarios, pueden fallar silenciosamente. En dominios como la atención médica, las finanzas, el gobierno o los sistemas críticos, tales fallos silenciosos podrían llevar a daños graves.

Esta investigación también se basa en métodos anteriores de inyección de solicitudes. La técnica anterior de HiddenLayer, “Policy Puppetry“, mostró cómo los atacantes pueden disfrazar instrucciones dañinas como contenido de política. Ahora, demuestran que tales ataques enmascarados pueden extenderse en la lógica de seguridad en sí.

Implicaciones para los desplegadores y los investigadores

A la luz de esta vulnerabilidad, cualquier persona que utilice o construya sistemas LLM agenticos debe replantear la estrategia de seguridad.

Primero: no confíe solo en comprobaciones basadas en modelos internos. La seguridad debe ser en capas. Eso significa combinar filtros basados en reglas, detectores de anomalías, sistemas de registro, monitoreo externo, supervisión humana y rastros de auditoría. Si una capa falla, otras pueden detectar la violación.

Segundo: pruebas de ataque adversario regulares son innegociables. Los modelos deben enfrentar inyecciones de solicitudes que intenten anular la lógica de guardia en sí, no solo “mal contenido”. Las pruebas deben evolucionar a medida que los atacantes inventan nuevas técnicas.

Tercero: en sectores regulados o críticos en términos de seguridad, la transparencia y la verificabilidad son esenciales. Los desplegadores necesitan pruebas de que un sistema puede resistir ataques adversarios, no solo funcionalidad básica. Eso sugiere que las auditorías de terceros, la verificación formal o las garantías de seguridad pueden convertirse en requisitos.

Cuarto: para los constructores de modelos, parchear esta clase de vulnerabilidad es complicado. Debido a que está vinculada a cómo los modelos analizan y obedecen instrucciones, simplemente filtrar una clase de solicitud no garantiza la resistencia a nuevas solicitudes. Las defensas basadas en afinación o filtros pueden degradar el rendimiento del modelo o llevar a carreras de armas. Un diseño más robusto puede requerir separación arquitectónica, la lógica de guardia que se ejecuta en un modelo o subsistema diferente al modelo de generación.

Limitaciones y preguntas abiertas

Para ser claro: el trabajo de HiddenLayer es un concepto de prueba, no un veredicto final sobre cada arquitectura de seguridad. Sus ataques exitosos dependen de un conocimiento profundo de la estructura de la solicitud del modelo de guardia y la lógica de puntuación interna. En entornos de solicitud más restringidos o sistemas que aleatorizan las defensas, el ataque puede ser más difícil de montar.

Además, no analizan completamente cómo son coherentes o útiles las salidas maliciosas cuando se crean bajo estas restricciones. Algunas salidas de evasión o sobrepaso pueden degradar en calidad o confiabilidad. Así que el riesgo es real, pero restringido por el entorno, el presupuesto de la solicitud, las restricciones de la interfaz y la aleatoriedad de la guardia.

Finalmente, algunos diseños de guardrail utilizan diferentes clases de modelos, métodos de conjunto o evaluación aleatorizada. No es seguro que todos estos sistemas sean vulnerables; si este ataque se generaliza ampliamente es una pregunta de investigación abierta.

Mirando hacia adelante: El futuro de la seguridad de la IA

Parecemos estar entrando en una nueva fase: ataques de solicitud no solo contra los modelos, sino contra sus capas de seguridad. Técnicas como secuestro de cadena de pensamiento, subversión de solicitud jerárquica y sobrepaso del juez empujarán a las defensas a evolucionar más rápido.

El camino hacia adelante es probablemente hacia la supervisión externa, sistemas que monitorean las salidas desde fuera, no comparten lógica de modelo o aplican comprobaciones de seguridad externas. Arquitecturas híbridas, métodos formales, detección de anomalías y bucles de retroalimentación humana necesitarán unirse.

Los guardrails son una herramienta útil, pero los hallazgos de HiddenLayer nos recuerdan: no pueden ser la única herramienta. La seguridad debe provenir de fuera del sistema, no solo de dentro.

La lógica del, o aplicar comprobaciones de seguridad externas. Arquitecturas híbridas, métodos formales, detección de anomalías y bucles de retroalimentación humana necesitarán unirse. Guardrails son una herramienta útil, pero HiddenLayer’s findings recuerdan: no pueden ser la única herramienta. La seguridad debe provenir de fuera del sistema, no solo de dentro del logic, o aplicar comprobaciones de seguridad externas. Arquitecturas híbridas, métodos formales, detección de anomalías y bucles de retroalimentación humana necesitarán unirse. Guardrails son una herramienta útil, pero HiddenLayer’s findings recuerdan: no pueden ser la única herramienta. La seguridad debe provenir de fuera del sistema, no solo de dentro.