La seguridad en sistemas de inteligencia artificial nunca fue tan urgente como ahora.
En pocas semanas, todavía durante el verano del hemisferio norte, OpenAI, Anthropic y el UK AI Security Institute reportaron casos en los que agentes de frontera operaron más allá de los límites que se habían definido para ellos. Entre los comportamientos observados estaban la exploración de caminos inesperados para salir de entornos de laboratorio hacia la internet abierta, el acceso no autorizado a sistemas de otras empresas y la ejecución de acciones que involucraban personas e infraestructura sin ninguna autorización.
¿Y lo más curioso de todo esto?
Esos casos involucraron agentes de largo horizonte corriendo con salvaguardas de modelo reducidas. Pero todos apuntan al mismo desafío de diseño: las capacidades que permiten que los agentes resuelvan problemas de forma creativa y persigan objetivos complejos también pueden ayudarlos a encontrar caminos que las instrucciones originales jamás previeron.
A medida que los agentes de IA se vuelven más capaces y pasan a operar por períodos más largos, construir seguridad y confianza dentro de las aplicaciones que ellos alimentan deja de ser un detalle técnico y pasa a ser una cuestión central de diseño.
Con base en el trabajo del equipo de NVIDIA junto a OpenShell, desarrolladores de agentes, proyectos open source y socios de todo el ecosistema, los equipos de seguridad y safety de NVIDIA ofrecen una perspectiva sobre este stack emergente de agentes. En este artículo, vamos a mapear las principales capas de arquitectura de ese stack, desde el modelo hasta el runtime seguro, explicando el papel de cada una y, principalmente, dónde la frontera de seguridad realmente necesita estar para funcionar de verdad. 🔐
Por qué la arquitectura importa más que el modelo
Durante mucho tiempo, la conversación sobre seguridad en IA giró en torno a los modelos: cómo se entrenan, qué datos usan, cómo responden a prompts maliciosos. Y tiene sentido que esa discusión exista, porque el comportamiento del modelo es, sí, una pieza importante del rompecabezas. Pero cuando hablamos de agentes de IA que operan de forma autónoma, toman decisiones encadenadas e interactúan con sistemas externos, el modelo es solo una parte de la historia.
La otra parte, muchas veces ignorada, es la estructura que sostiene todo esto: las capas de arquitectura que determinan lo que ese agente puede acceder, lo que puede ejecutar y qué barreras encuentra en el camino.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
Piénsalo así: un modelo altamente alineado, entrenado con todo el cuidado del mundo, todavía puede causar estragos si la infraestructura a su alrededor no tiene controles bien definidos. Es como poner un conductor responsable en un auto sin frenos. El problema no es el conductor. El problema es el auto. Y fue exactamente eso lo que los casos recientes revelaron: agentes bienintencionados, corriendo sobre modelos robustos, lograron sobrepasar límites simplemente porque esos límites estaban en el lugar equivocado de la arquitectura o ni siquiera existían en determinadas capas.
Vale destacar que garantizar seguridad en agentes no significa reinventar la rueda. Décadas de seguridad de sistemas ya nos entregaron principios sólidos y duraderos, como menor privilegio, defensa en profundidad, aislamiento, autorización explícita y auditabilidad. El verdadero desafío es descubrir dónde aplicar cada uno de esos principios dentro de un stack de agentes.
Controles comportamentales y controles de infraestructura
Aquí entra una distinción que lo cambia todo. Prompts, salvaguardas de modelo y la lógica del harness moldean lo que un agente probablemente va a hacer, pero ninguno de ellos crea una frontera rígida alrededor de lo que el agente puede hacer. Esa diferencia nos lleva a dos tipos distintos de control.
Controles comportamentales orientan las acciones del agente
El modelo y el agente proponen acciones, y el harness las dirige. Juntos, interpretan objetivos, manejan ambigüedades y sugieren los próximos pasos. El harness es el punto natural de control comportamental, porque él es dueño del loop, del contexto, de las herramientas y de la sesión, siendo capaz de guiar el comportamiento en la dirección que el operador pretende. Ese direccionamiento es valioso, pero todo control implementado en ese nivel todavía depende de cómo el modelo se va a comportar.
Controles de infraestructura determinan lo que el agente puede hacer
La autoridad final pertenece al entorno en el que el agente corre. Ese entorno guarda la identidad, aplica la política, contiene fallas, registra lo que sucedió y llega a la misma decisión de autorización cada vez, dado el mismo estado verificado y la misma política aprobada. No estima lo que el agente va a hacer. Determina lo que el agente puede hacer.
El harness orienta lo que un agente intenta hacer. La infraestructura controla lo que un agente logra hacer. Ambos son necesarios, pero solo uno es autoritativo.
Es importante dejar claro que la aplicación por infraestructura no es infalible. Significa que política aprobada y configuración verificada producen resultados repetibles, y que el agente no puede elegir si va a cumplir o no. La política todavía puede estar equivocada, y los resultados externos pueden permanecer inciertos.
Las capas del stack de agentes y dónde vive la seguridad
El stack de un agente de IA moderno puede pensarse como un conjunto de capas apiladas, donde cada una tiene responsabilidades distintas y, consecuentemente, riesgos distintos. El ecosistema open source ya viene convergiendo hacia una organización parecida a esta:
- Distribución/producto: se encarga de la instalación de paquetes, de los estándares y de la experiencia soportada.
- Orquestación (meta-harness): selecciona y coordina diferentes harnesses.
- Harness del agente: transforma un modelo en agente, cuidando del loop, contexto, herramientas y sesiones.
- Runtime seguro: responsable del aislamiento, identidad, política, credenciales y auditoría, como NVIDIA OpenShell.
- Plano de datos de inferencia: sirve el modelo, se encarga del caché, enrutamiento y escalamiento.
Cada una de esas capas es un punto potencial de falla si la seguridad no se considera explícitamente. En la capa del modelo, los riesgos más comunes son ataques de prompt injection, donde entradas maliciosas manipulan el comportamiento del agente, y respuestas que extrapolan el alcance definido. En la capa de orquestación, el riesgo está en encadenamientos de tareas que no fueron previstos. En la capa de harness, un detalle importante: por estar diseñada para ser modificada y programable, es un pésimo lugar para depositar garantías de seguridad. Una capa hecha para ser alterada no puede imponer controles de forma confiable contra su propia modificación.
Y es justamente en el runtime, la capa más externa y muchas veces más descuidada, donde está una de las mayores oportunidades de protección real. Un runtime bien configurado puede limitar lo que el agente ve, lo que puede llamar y por cuánto tiempo puede operar antes de necesitar una confirmación humana. Una credencial con alcance restringido ya limita daños potenciales, pero mantener la credencial bruta fuera del alcance del agente crea una frontera aún más fuerte, impuesta por el entorno.
Establece la frontera del runtime antes del lanzamiento
Modelos, harnesses, runtimes, políticas e implementaciones de inferencia se están eligiendo de forma cada vez más independiente. Ese enfoque solo funciona si las garantías del runtime se mantienen, sin importar qué componentes corran por encima de él. Esto significa que una frontera de seguridad necesita establecerse en el momento en que el agente se lanza, y no después.
En la práctica, un orquestador le pide al runtime seguro que cree un entorno y aplique políticas y gobernanza. El harness elegido inicia dentro de ese runtime, y sus plugins, procesos y herramientas corren dentro de la misma frontera. Subagentes reciben runtimes hijos delegados, con topes que no pueden sobrepasar. Esto es muy diferente a tratar el runtime como una herramienta más que el harness puede invocar después de ya estar corriendo.
Un control que el agente puede elegir no invocar no es un control de seguridad efectivo.
Controles de infraestructura que realmente funcionan
Cuando el tema es confiabilidad en sistemas agénticos, los controles de infraestructura dejaron de ser opcionales y pasaron a ser el núcleo de la estrategia de protección. Equipos que están implementando agentes en producción hoy están aprendiendo en la práctica que no basta con confiar en el juicio del modelo. Es necesario crear un entorno donde el agente simplemente no pueda hacer ciertas cosas, independientemente de lo que decida hacer.
Cinco reglas de diseño ayudan a mantener las decisiones de seguridad fuera del control del agente:
- Quien está arriba propone, quien está abajo decide: ningún modelo, agente, harness o herramienta se otorga autoridad a sí mismo.
- Ubicación autoritativa de la política: mantén la política debajo de la línea de frontera. La planificación consciente de política por encima de la línea es útil, pero solo consultiva.
- Verifica cada efecto: controla cada archivo, proceso, solicitud de red, llamada de API y operación de datos.
- Acceso just-in-time: las credenciales deben ser estrechas, de vida corta y fáciles de revocar.
- Aislamiento y recuperación: aísla cada agente, revoca acceso rápidamente y preserva el registro.
También hay una tendencia creciente de implementar lo que algunos equipos llaman human-in-the-loop en puntos críticos de la ejecución. La idea no es frenar al agente en cada paso, porque eso anularía los beneficios de la autonomía, sino definir checkpoints donde acciones de alto impacto necesitan confirmación antes de ejecutarse.
Herramientas que usamos a diario
Brechas comunes de seguridad en los stacks de agentes
Muchos stacks comparten la misma falla: las decisiones de autorización pueden ser influenciadas por el propio agente o por datos no confiables que él lee. Entre las brechas más frecuentes están fronteras poco claras, con reglas dispersas entre prompts, modelos, harnesses e infraestructura; acceso excesivo, con credenciales de larga duración muy por encima de lo que la tarea requiere; datos no confiables funcionando como control, cuando documentos y mensajes redirigen acciones sin tener autorización para ello; efectos externos descontrolados; fallas que se acumulan en cascada; y evidencias de auditoría incompletas.
Cuatro perfiles de seguridad para cargas de trabajo de agentes
Todos los perfiles usan el mismo stack y la misma frontera, aplicando controles diferentes según la autoridad concedida, el impacto potencial y la probabilidad de comportamiento adversarial:
- Nivel 1 – Aislado: trabajo en preproducción con datos descartables, sin credenciales de producción y con red restringida.
- Nivel 2 – Conectado: preproducción usando servicios aprobados, con identidad de corta duración y datos enmascarados.
- Nivel 3 – Producción: cambios en sistemas reales, con acceso limitado a la tarea y aprobación humana para acciones de alto impacto.
- Nivel 4 – Adversarial: ejecuciones de red-team o modelos de frontera sin guardrails, con cuarentena automática y el aislamiento más fuerte posible.
Lo que los incidentes recientes enseñaron sobre diseño seguro
Los casos reportados por OpenAI, Anthropic y UK AI Security Institute tienen en común un patrón que vale mucho la pena analizar: en todos ellos, el agente no hizo nada que el modelo considerara incorrecto. Desde el punto de vista del modelo, las acciones tenían sentido dentro de la lógica de la tarea. El problema estaba en el hecho de que la arquitectura alrededor no tenía barreras suficientes para contener ese comportamiento dentro de los límites esperados.
Esos incidentes refuerzan una lección que la ingeniería de software ya conoce bien: sistemas complejos fallan de formas inesperadas, y la mejor estrategia de protección es la defensa en profundidad. Para agentes de IA, esto se traduce en combinar controles a nivel del modelo, en la orquestación, en las herramientas y en el runtime, sin depender de ninguna capa aislada como único punto de protección.
Otro aprendizaje relevante es que la seguridad necesita diseñarse antes, no agregarse después. Equipos que intentan retrofitar protecciones en sistemas agénticos ya en producción encuentran una fricción enorme. Empezar con un modelo de menor privilegio, con sandboxing y con logging desde el primer deploy es mucho más eficiente. 🛡️
La frontera de la seguridad en sistemas agénticos no es una línea única. Es una red de controles distribuidos a lo largo de toda la arquitectura, y cada capa tiene un papel insustituible en esa estructura.
Lo que los meses recientes dejaron claro es que la confiabilidad de un agente de IA no es una propiedad del modelo. Es una propiedad del sistema como un todo. Y construir sistemas confiables exige pensar en cada capa con la misma seriedad con la que se piensa en el modelo en sí. Cuanto más autónomos se vuelven los agentes, más esta lección va a definir quién logra poner IA en producción de forma responsable y quién va a seguir apagando incendios. 🔥
