A medida que los agentes de IA se vuelven más capaces y operan en horizontes de tiempo más largos, incorporar seguridad y confianza en las aplicaciones que impulsan se vuelve cada vez más importante. A partir del trabajo con NVIDIA OpenShell, desarrolladores de agentes, proyectos de código abierto y socios del ecosistema, los equipos de seguridad de IA de NVIDIA ofrecen su lectura sobre el stack de agentes emergente, incluido el rol de cada capa y dónde debería vivir la seguridad.
¿Por qué importa dónde se ponen los controles?
Reportes recientes explican por qué la ubicación de los controles no es un detalle. En pocas semanas de este año, OpenAI, Anthropic y el Instituto de Seguridad de IA del Reino Unido reportaron cada uno agentes de frontera operando más allá de los límites previstos. Entre los comportamientos descritos figuran explotar una vía inesperada para salir de entornos de laboratorio hacia internet abierta, obtener acceso no autorizado a sistemas de otras compañías y ejecutar acciones no sancionadas que involucraban a personas e infraestructura. Se trataba de agentes de horizonte largo corriendo con salvaguardas de modelo reducidas.
Todos apuntan al mismo desafío de diseño: las capacidades que permiten a un agente resolver problemas de forma creativa también lo ayudan a encontrar caminos que sus instrucciones originales no anticiparon.
La propia investigación de NVIDIA refuerza el punto sobre la capa de harness. Con Agentic Variation Operators (AVO), sus investigadores alcanzaron un puntaje de 100% en ARC-AGI-3, un benchmark interactivo de razonamiento que ubica a los agentes en entornos desconocidos sin instrucciones, reglas explícitas ni metas declaradas.
Controles de comportamiento contra controles de infraestructura
Asegurar agentes no exige reinventar la seguridad. Décadas de seguridad de sistemas entregan principios duraderos: mínimo privilegio, defensa en profundidad, aislamiento, autorización explícita y auditabilidad. El desafío es determinar dónde aplicarlos dentro del stack.
Los prompts, las salvaguardas del modelo y la lógica del harness moldean lo que un agente probablemente hará, pero no crean un límite duro sobre lo que puede hacer. De ahí surgen dos tipos distintos de control:
- Controles de comportamiento: el modelo y el agente proponen acciones, y el harness las dirige. El harness es el punto de control natural, porque es dueño del ciclo, del contexto, de las herramientas y de la sesión. Ese direccionamiento es valioso, pero cada control implementado a ese nivel sigue dependiendo de cómo se comporte el modelo.
- Controles de infraestructura: la autoridad final pertenece al entorno donde el agente corre. Ese entorno sostiene la identidad, aplica políticas, contiene fallas, registra lo ocurrido y llega a la misma decisión de autorización siempre, dada la misma política aprobada y el mismo estado verificado.
La formulación de NVIDIA es directa: el harness guía lo que un agente intenta; la infraestructura controla lo que un agente puede hacer. Ambos son necesarios, solo uno es autoritativo.
El harness, además, es un mal lugar para depositar una garantía de seguridad. Es un espectro más que una categoría fija: Codex y Claude Code son harnesses opinados, mientras que Pi y DeepSeek Harness (DSH) exponen buena parte del harness como sustrato programable, con comportamientos que se componen y reemplazan como plugins a través de Cordis. Una capa diseñada para ser modificada no puede imponer controles contra su propia modificación de manera confiable.
¿Cuáles son las fallas más comunes hoy?
Muchos stacks de agentes comparten el mismo defecto: las decisiones de autorización pueden ser influidas por el agente o por datos no confiables que este lee. NVIDIA enumera seis brechas recurrentes:
- Límites poco claros: las reglas se reparten entre prompts, modelos, agentes, harnesses, runtimes e infraestructura, de modo que la versión autoritativa es difícil de encontrar.
- Acceso excesivo: el agente recibe credenciales permanentes, a menudo de larga vida, o permisos que exceden lo que la tarea actual necesita.
- Datos no confiables como control: documentos, mensajes, resultados de herramientas y memoria pueden redirigir la acción sin haber sido autorizados como instrucciones.
- Efectos externos sin control: una API permitida puede mover datos, crear cómputo o disparar efectos fuera de los controles previstos.
- Fallas que se componen: los agentes delegan, comparten memoria y llaman a pares, así que un error se vuelve una cascada rápida.
- Evidencia de auditoría incompleta: las aprobaciones son vagas, revocar accesos es lento y el registro no alcanza para explicar un incidente.
Las cinco reglas de diseño
Cinco reglas ayudan a mantener las decisiones de seguridad fuera del control del agente:
- Arriba propone, abajo decide. Ningún modelo, agente, harness, herramienta o sistema de memoria se otorga autoridad a sí mismo.
- Ubicación autoritativa de la política. La política vive bajo la línea. Planificar considerando la política por encima de esa línea es útil, pero solo referencial.
- Revisar cada efecto. Controlar cada archivo, proceso, petición de red, llamada a API, operación de datos, asignación de recursos, comunicación y acción sobre dispositivos.
- Acceso justo a tiempo. Las credenciales y capacidades deben ser acotadas, de vida corta y fáciles de remover.
- Aislamiento y recuperación. Aislar cada agente, revocar accesos rápido, recuperar y preservar el registro.
El límite de seguridad debe establecerse cuando el agente se lanza, no después. Un orquestador le pide a OpenShell crear un runtime y aplicar políticas; el harness elegido arranca dentro de ese runtime, y sus plugins, procesos de Model Context Protocol (MCP), herramientas y demás código dirigido por el modelo corren dentro del mismo límite. Los subagentes reciben runtimes hijos delegados con techos que no pueden exceder.
La conclusión operativa es tajante: un control que el agente puede decidir no invocar no es un control de seguridad efectivo. Cualquier ruta que permita a las capas superiores esquivar la política y su aplicación es, según NVIDIA, un defecto arquitectónico.
¿Qué implica para un equipo pequeño?
El modelo por capas se parece al modelo OSI: cada capa tiene un trabajo y una interfaz clara, y las capas altas pueden cambiar sin redefinir la capa de control que tienen debajo. Eso significa que los tres requisitos que hacen funcionar el límite (tratar como no confiable todo lo que está arriba, hacer autoritativo lo que está abajo, y usar señales de riesgo solo para reducir autoridad, nunca para ampliarla) se pueden aplicar sin adoptar el stack completo de un proveedor. Para equipos en Chile y la región que están montando sus primeros agentes internos, la lectura práctica es que la inversión rinde más en aislamiento y credenciales de vida corta que en escribir prompts defensivos cada vez más largos.
