Una sola inyección exitosa equivale a entregar todas las credenciales
Colocar las APTI keys en variables de entorno ha sido el procedimiento estándar en la ingeniería de servidores durante los últimos veinte años. El 28 de septiembre de 2026, NVIDIA lanzó su plataforma de seguridad abierta para agentes (Open Agent Safety Platform), convirtiendo este procedimiento estándar en algo prohibido en la era de los agentes. La plataforma incluye dos elementos: el software de código abierto OpenShell (Apache 2.0, en el repositorio NVIDIA/OpenShell de GitHub), y el diseño de sistema de referencia Sentry, que funciona en el DPU BlueField-4 (Data Processing Unit, unidad de procesamiento de datos) como un watchdog fuera de banda que supervisa los agentes en la CPU principal, con la capacidad de aislar agentes fuera de control en milisegundos, según afirma la compañía.
Estado del repositorio: implementación en Rust, con módulos separados en crates y soporte para políticas de seguridad en el kernel.como core, supervisor, credential-gateway, policy-engine, egress-gateway; 18.2k estrellas y 1,852 commits; versión estable 0.1.x, con aproximadamente una nueva versión cada tres semanas. La alta densidad de commits combinada con el ritmo de una versión cada tres semanas apunta a la misma conclusión: este runtime todavía está en una fase de rápido desarrollo, y quienes lo integren en producción debenreservado costos para cambios en la interfaz.
La lógica de diseño de OpenShell se puede resumir en un principio: el comportamiento de los agentes es impredecible, por lo que se debe restringir su alcance, trasladando la autorización del contexto del modelo al kernel. El punto focal de la competencia en los runtime de agentes cambia así de “qué tan obediente es el modelo” a “qué tan lejos puede llegar un acceso no autorizado”.
Las credenciales entran en la pasarela, no en el contexto
El trabajo diario de los agentes autónomos consiste en ejecutar comandos de shell, escribir archivos y realizar solicitudes de red, con las credenciales generalmente almacenadas en variables de entorno, archivos de configuración o archivos .env. Una sola inyección exitosa de prompts, o incluso un simple error de juicio del modelo, puede hacer que el actúe con todas las credenciales. El radio de explosión equivale al conjunto de permisos que se le han otorgado, y restringir los permisos es reducir el radio de explosión. Este es el punto de partida de todo el diseño de OpenShell.
Las barreras a nivel de prompt no tienen fuerza coercitiva frente a entradas adversarias. Las restricciones del system prompt dependen de la obediencia del modelo, y todo lo que un atacante necesita hacer es hacer que el modelo cambie de opinión; los límites de permisos a nivel de kernel no se preocupan por las intenciones del modelo, y las llamadas al sistema se rechazan directamente. La diferencia entre las barreras y los límites radica en quien impone: uno depende de la disciplina del modelo, el otro del kernel.
Figura: Captura de pantalla de la interfaz de línea de comandos de OpenShell en ejecución, las acciones del agente solo se ejecutan después de pasar la verificación de la política. Fuente: Documentación del repositorio oficial de OpenShell
El forzamiento a nivel de kernel es el primer mecanismo clave. Las políticas se aplican en la capa del kernel, sin depender de bibliotecas de tiempo de ejecución ni de configuraciones de contenedores; cada acción del agente dentro de los límites debe pasar una verificación de políticas. Los contenedores resuelven el aislamiento de procesos y la distribución de imágenes, pero OpenShell responde a otra pregunta: ¿está autorizado cada acceso del agente a credenciales, archivos y red durante su ejecución?
La pasarela de credenciales es el segundo mecanismo clave. Las APTI keys y los tokens se entregan a la pasarela de credenciales para que los gestione, inyectándolos en las solicitudes salientes; las credenciales nunca entran en el contexto del agente, ni tampoco en su sistema de archivos. En comparación con la práctica habitual de “meter la clave en un .env”, la superficie de potencial de filtración se reduce de toda la máquina a un solo componente de pasarela. El modelo puede ser engañado, pero un modelo engañado no tiene las llaves en su poder.
El tráfico saliente también está controlado: la pasarela de salida (egress gateway) solo permite el tráfico a destinos en una lista blanca, y todo lo que está fuera de la lista es inaccesible; el sistema de archivos y los destinos de red solo exponen los directorios y direcciones que el agente debería ver.
Figura: Arquitectura de OpenShell: los módulos de agente, supervisor, pasarela de credenciales, motor de políticas y pasarela de salida son independientes, y la verificación de credenciales y políticas se realiza fuera del contexto del agente. Fuente: Imágenes del repositorio docs/images de OpenShell
Los cambios en las políticas deben pasar primero por verificación formal antes de entrar en vigor
Un error en una política equivale a crear un agujero de seguridad. OpenShell bloquea los cambios en las políticas con una verificación formal: las nuevas políticas deben pasar una verificación formal antes de entrar en vigor para confirmar que su semántica coincide con lo esperado. En herramientas de sandbox similares, este paso es raro; la mayoría de las soluciones se quedan en el estado de “las políticas son código, se aplican una vez modificadas”.
El componente supervisor se encarga de la creación, supervisión y terminación de los agentes, constituyendo una capa de gestión del ciclo de vida. El SDK cubre cuatro lenguajes: Python, TypeScript, Go y Rust, y la implementación en Kubernetes se realiza a través de Helm, por lo que la integración en proyectos es completa.
La verificación formal tiene sus propios límites: combate las “polísticas mal escritas”, pero no resuelve el problema de “las políticas están bien escritas pero demasiado restrictivas”. Si las políticas son demasiado restrictivas, el agente no puede realizar su trabajo, y la presión operativa empujará a las personas a relajar las reglas; una vez que las intenciones se relajan, la verificación más estricta solo ejecuta con precisión una intención laxa. La responsabilidad de seguridad se traslada de la capa de código a los autores de las políticas, y las políticas mismas se convertirán en un nuevo objeto de auditoría.
Figura: Ilustración de los puntos de forzamiento del sandbox: las políticas se aplican en los límites del sistema de archivos, red, credenciales y tráfico saliente, cada límite corresponde a un componente independiente. Fuente: Documentación del repositorio docs/images de OpenShell
El watchdog se traslada al DPU BlueField-4 para un aislamiento en milisegundos
El diseño de referencia Sentry traslada el watchdog fuera del host. Funciona en el DPU BlueField-4, supervisa los agentes que se ejecutan en la CPU principal fuera de banda, y según afirma la compañía, puede aislar agentes fuera de control en milisegundos; en el entorno de demostración, la CPU Vera también participó en la ejecución.
Fuera de banda es clave en este diseño. La supervisión dentro de banda comparte el mismo kernel y dominio de confianza con el objeto supervisado; si el host es comprometido, la supervisión también lo es. El DPU tiene su propia capacidad computacional y ruta de red independientes, por lo que incluso si un agente en la CPU principal se sale de control, no puede alcanzar al watchdog mismo. El aislamiento se mide en milisegundos, por lo que la ventana de mal comportamiento también se reduce a milisegundos; con la condición de que el firmware y la pila de software en el lado del DPU mantengan su integridad, el watchdog mismo se convierte en un nuevo objetivo de alto valor para los ataques.
El comunicado de prensa oficial también enumera 12 socios industriales e integradores, incluyendo proveedores de nube y empresas de seguridad. La postura en el ecosistema es clara: NVIDIA quiere que “los agentes se ejecuten en un runtime con límites” se convierta en la forma de implementación predeterminada, al igual que el hypervisor para las máquinas virtuales.
El número de versión 0.1.x es más honesto que las cuatro palabras “ampliamente disponible”
El número de versión vierte primero un poco de agua fría. OpenShell actualmente se encuentra en versión inicial, dejando margen para el desarrollo futuro.está en la versión estable 0.1.x, con un ritmo de publicación de aproximadamente tres semanas, pero el lenguaje oficial de la compañía es que “ya está ampliamente disponible” (now broadly available). El ritmo de una versión cada tres semanas es en sí mismo una señal: las interfaces y semántica todavía están cambiando, y quienes lo integren en producción debenreservado costos para migraciones; las cuatro palabras “amplio disponible” y el 0.1.x dejan espacio para el juicio de los usuarios.
El segundo golpe de agua fría: el sandbox reduce el radio de explosión, pero no elimina los riesgos. La capa de forzamiento del kernel, la pasarela de credenciales y el motor de políticas se convierten en nuevas bases de confianza, y si tienen problemas, los límites fallan. La superficie de ataque cambia de posición, pero no disminuye en volumen; el objeto de auditoría se amplía de “aplicaciones de agente” a “runtime de sandbox”.
La disputa sobre el enfoque aún no tiene una conclusión. Plataformas gestionadas como Claude Managed Agents de Anthropic integran el sandbox en servicios en la nube, por lo que los usuarios no necesitan construir sus propios límites; OpenShell sigue la ruta de autohospedaje y auditabilidad. Las condiciones previas para estos dos enfoques son diferentes: los equipos que requieren que los datos no salgan de su dominio y necesitan mantener pistas de auditoría elegirán el segundo, mientras que los equipos sin capacidad operativa dedicada para gestionar límites usarán servicios gestionados que son mucho más sencillos. La elección está determinada por los requisitos de cumplimiento y la capacidad operativa, y ambos caminos tienen sus escenarios válidos.
El software se regala, el hardware se vende como siempre
La cuenta comercial debe estar clara. OpenShell se distribuye bajo Apache 2.0, lo que reduce los requisitos de cumplimiento para la implementación de agentes; el diseño de referencia Sentry está vinculado al DPU BlueField-4 y la CPU Vera. El software se distribuye gratuitamente, mientras que el hardware de seguridad se vende por unidad: es la misma estrategia de siempre de la era CUDA: las herramientas del ecosistema son gratuitas, pero se cobra por la capacidad computacional. El runtime del sandbox en sí no genera ingresos, y el dinero se gasta en el hardware donde se ejecuta el límite.
Esta estrategia también tiene sentido para los usuarios: elegir OpenShell significa obtener límites auditables y una lista clara de compras de hardware; elegir una plataforma gestionada significa obtener un sistema sin operaciones manuales. Ambas formas de entrega tienen sus propias cuentas, y solo mirando el protocolo de código abierto del repositorio, no se puede ver la estructura del negocio completo.
Volviendo a la línea divisoria mencionada al principio. Las barreras de los prompts controlan lo que el modelo dice, mientras que los límites del kernel controlan lo que los procesos pueden hacer; la primera depende de la obediencia del modelo, la segunda de la corrección de las políticas. Después de que NVIDIA entregara tanto el runtime de código abierto como el watchdog del DPU, el enfoque de seguridad de los agentes se ha desplazado de “hacer que el modelo obedezca” a “limitar lo lejos que puede llegar un acceso no autorizado”. Si el modelo se saldrá de control sigue siendo desconocido, pero lo lejos que puede llegar un proceso ahora es medible y auditable; esta es la verdadera novedad en ese comunicado del 28 de septiembre, y la parte que el número de versión 0.1.x aún no ha tenido tiempo de cumplir.
Enlaces de referencia:
- Comunicado de prensa oficial de NVIDIA
- README del repositorio oficial de OpenShell
- Documentación de arquitectura de OpenShell
