La arquitectura de referencia NVIDIA OpenShell lleva la aplicación de controles para agentes a la infraestructura

NVIDIA lanzó su arquitectura de referencia NVIDIA OpenShell el 21 de octubre, situando los permisos de los agentes fuera del control del software que ejecuta el trabajo. Anunciado en GTC Berlin, el diseño conecta la computación de modelos, la ejecución de agentes y la aplicación independiente de controles de seguridad. Su propuesta central es práctica: un agente debería seguir trabajando de forma autónoma sin obtener autoridad para reescribir sus propias restricciones.

Esto plantea una decisión de compra distinta a la de elegir un modelo más capaz. Las empresas deben decidir dónde residen los permisos, qué infraestructura los aplica y quién puede detener a un agente después de que algo salga mal. La tensión se sitúa entre una autonomía útil y unas restricciones lo bastante precisas para evitar acciones no autorizadas sin bloquear el trabajo legítimo.

Claude Code de Anthropic ofrece una comparación útil porque también restringe a los agentes mediante su entorno operativo. NVIDIA amplía esa conversación a la infraestructura empresarial y la aplicación opcional mediante hardware. Desarrolladores, equipos de seguridad y proveedores de software empresarial afrontan ahora una pregunta común: ¿cómo convierte una organización sus reglas de negocio en límites que sigan siendo eficaces durante la ejecución?

La arquitectura de referencia NVIDIA OpenShell conecta la ejecución con la aplicación de controles

El anuncio presenta la contención de agentes como una responsabilidad de infraestructura, con componentes separados para realizar el trabajo y gobernarlo.

Una arquitectura de referencia es un diseño de sistema documentado que las organizaciones y los socios pueden utilizar al crear despliegues. No significa que cada integración mencionada llegue como un producto terminado con capacidades idénticas. Esa distinción importa al evaluar un anuncio que abarca procesadores, sistemas operativos, proveedores de seguridad y aplicaciones empresariales.

Según la arquitectura de referencia OpenShell de NVIDIA, la infraestructura Vera Rubin ejecuta modelos, mientras que las CPU Vera operan los arneses de agentes, el software que coordina llamadas al modelo y herramientas. Las unidades de procesamiento de datos BlueField-4, procesadores especializados de infraestructura, ejecutan el software de seguridad Sentry para una supervisión y aplicación independientes.

La división refleja problemas operativos distintos. Generar un plan requiere capacidad de cómputo. Ejecutarlo requiere acceso a archivos, servicios y herramientas. Autorizar esas acciones requiere reglas que el agente ejecutor no pueda modificar simplemente porque una restricción interfiera con su tarea.

El anuncio también extiende el diseño hacia despliegues locales y perimetrales, es decir, sistemas que operan más cerca de los usuarios o los equipos. NVIDIA menciona RTX Spark, DGX Spark y DGX Station. Los compradores deberían evaluar esos entornos individualmente en lugar de asumir que una estación de trabajo local ofrece todas las protecciones descritas para un despliegue de infraestructura mayor.

El cambio importante es la relación propuesta entre esas piezas. En lugar de tratar la seguridad como una función de aplicación añadida después del desarrollo, la arquitectura sitúa la aplicación de controles por debajo de la aplicación. La solicitud de un agente pasa a ser algo que la infraestructura evalúa, en vez de algo aceptado porque el agente generó una explicación plausible.

Consideremos una tarea de ingeniería ilustrativa: un agente investiga un servicio que falla y propone una reparación. Leer archivos de diagnóstico, instalar una dependencia, cambiar la configuración y desplegar la corrección representan permisos diferentes. Una única instrucción para reparar el servicio no establece que todos los pasos posibles estén autorizados.

Ese ejemplo explica por qué la arquitectura es relevante más allá de los especialistas en seguridad. Los equipos de producto que prometen ejecución autónoma también deben explicar los límites de esa ejecución. De lo contrario, los clientes reciben una descripción de capacidades sin una explicación correspondiente del control.

La disponibilidad también necesita una interpretación cuidadosa. NVIDIA afirma que la arquitectura de referencia está disponible, pero eso no establece la preparación para producción de todas las combinaciones de socios. Un diseño documentado, un despliegue compatible y una instalación validada de un cliente responden a preguntas diferentes.

Por tanto, para quienes evalúan el lanzamiento, la primera pregunta es específica: ¿qué partes de la cadena propuesta de ejecución y aplicación de controles existen en la configuración ofrecida? La respuesta determina si un comprador está evaluando controles de software, protección adicional mediante hardware o una hoja de ruta que combina ambos.

Los equipos empresariales heredan el problema de los permisos

Trasladar la aplicación de controles a la infraestructura da a las empresas más control, al tiempo que hace más difícil dejar implícitas sus decisiones de política.

La presión inmediata recae sobre los equipos responsables de traducir la autoridad empresarial en permisos técnicos. Los equipos de seguridad pueden definir recursos restringidos, pero los responsables de negocio deben explicar qué acciones corresponden a una tarea. Después, los equipos de infraestructura deben hacer que esas decisiones sean aplicables en todos los sistemas que toca un agente.

Una instrucción como «preparar la renovación del cliente» contiene una ambigüedad considerable. Podría justificar leer el historial de la cuenta y redactar una propuesta. No justifica automáticamente cambiar términos contractuales, exportar registros de clientes o enviar la propuesta sin revisión.

Estas son distinciones ilustrativas, no resultados comunicados de despliegues de OpenShell. Muestran por qué la seguridad de los agentes exige más que identificar el modelo o comprobar si un empleado inició la solicitud. La autoridad depende de la acción, su objetivo y las circunstancias.

Los controles de tiempo de ejecución para agentes de NVIDIA dividen la responsabilidad entre una puerta de enlace, un supervisor, un sandbox y un verificador de políticas. La puerta de enlace gestiona las políticas y los ciclos de vida de los sandbox. El supervisor comprueba solicitudes y media las credenciales fuera del sandbox, un entorno de ejecución aislado. El verificador de políticas comprueba los permisos frente a un límite definido por la organización.

Esa separación proporciona puntos de aplicación de controles, pero las organizaciones aún deben decidir qué deberían permitir esos puntos. Un límite verificado formalmente puede confirmar una relación entre políticas. No puede decidir de forma independiente si un departamento empresarial otorgó un acceso excesivo desde el principio.

Esto cambia la conversación entre los desarrolladores de aplicaciones y los revisores de seguridad. En vez de preguntar si un agente es generalmente fiable, los revisores pueden examinar qué puede leer, modificar, invocar o transmitir. Estas preguntas generan respuestas más accionables, aunque también requieren una preparación más detallada.

Los desarrolladores afrontan una restricción de diseño relacionada. Un flujo de trabajo que solo tiene éxito cuando recibe permisos amplios es más difícil de aprobar que uno con requisitos explícitos y limitados. Las interfaces de herramientas y las descripciones de tareas pasan a formar parte del diseño de seguridad porque determinan con qué precisión puede expresarse la autoridad.

Para los trabajadores del conocimiento, la distinción comienza con el acceso a la información. Una base de conocimientos con capacidad de búsqueda ayuda a establecer dónde reside el material útil. Un agente que realiza acciones introduce otra decisión: si encontrar información también concede permiso para compartirla o modificar el sistema que la contiene.

La carga organizativa es continua. Los empleados cambian de función, los proyectos terminan, las credenciales caducan y las aplicaciones adquieren nuevas funciones. La autoridad de un agente debe reflejar esos cambios en lugar de conservar el acceso que hizo exitosa su primera demostración.

Por eso la gobernanza no puede terminar con un documento de aprobación. Las empresas necesitan una conexión entre la persona que autoriza el trabajo, la política que representa esa autoridad y la infraestructura que la aplica. Sin esa conexión, las reglas aplicadas de forma independiente aún pueden preservar una decisión desactualizada o excesivamente amplia.

Por tanto, el lanzamiento presiona tanto a los proveedores de software como a los compradores de infraestructura. Los proveedores deben exponer suficiente detalle sobre las acciones de los agentes para que los clientes puedan gobernarlas. Un sistema que presenta cada operación como una solicitud indistinguible deja a los clientes ante una elección burda entre acceso amplio e interrupción.

El aislamiento mediante hardware cambia dónde se mantiene el límite

La propuesta de hardware de NVIDIA añade un punto de aplicación independiente; su valor depende de si las acciones pertinentes realmente pasan por ese punto.

Una restricción de software tiene un alcance definido. Su protección depende de los componentes que la aplican y de las suposiciones que realizan esos componentes. Añadir una capa de seguridad de hardware separada cambia algunas de esas suposiciones al situar los controles fuera del entorno de ejecución del agente.

NVIDIA describe Sentry como protección adicional opcional junto a los límites de software de OpenShell. Esa distinción evita un malentendido común: utilizar OpenShell no significa automáticamente que un despliegue incluya la aplicación de controles de BlueField-4. Los compradores deben identificar la configuración real antes de comparar afirmaciones de seguridad.

En el diseño de seguridad de tiempo de ejecución Sentry de NVIDIA, BlueField-4 ocupa la ruta de comunicación del nodo hacia los modelos y los sistemas externos. Sentry combina la inspección del tráfico con análisis selectivos de la memoria del host. NVIDIA afirma que puede poner en cuarentena a agentes en milisegundos sin requerir cooperación del agente ni del software host.

La lógica arquitectónica es directa. Un control resulta más útil frente a una carga de trabajo comprometida cuando esa carga no puede desactivarlo. Pero la independencia por sí sola no establece una cobertura completa. El punto de aplicación también debe ver la acción que se está evaluando y conservar la autoridad para bloquearla.

Esto genera preguntas concretas para las revisiones de despliegue. ¿La configuración enruta cada conexión externa pertinente por la ruta controlada? ¿Qué acciones locales reciben restricciones independientes? ¿Qué sucede cuando una herramienta realiza trabajo en otro servicio después de recibir una solicitud autorizada?

Estas preguntas se derivan del diseño, no documentan fallos descubiertos. Importan porque el flujo de trabajo de un agente puede atravesar varios límites administrativos. Bloquear su próxima conexión no necesariamente puede revertir una acción ya aceptada por otra aplicación.

El tráfico cifrado introduce otra decisión de configuración. NVIDIA describe la inspección de conexiones configuradas para descifrarse y examinarse. Por tanto, las empresas deben entender dónde se aplica la inspección, qué información se vuelve visible y cómo encaja esa visibilidad con sus requisitos de confidencialidad.

La comparación con Anthropic ayuda a aclarar la elección de diseño. El sandboxing de Claude Code de Anthropic utiliza mecanismos del sistema operativo para restringir el acceso al sistema de archivos y a la red. Su enfoque declarado otorga libertad a los agentes dentro de límites predefinidos mientras controla el acceso más allá de ellos.

Ambos enfoques imponen restricciones fuera de las instrucciones generadas por el modelo. La diferencia no es una simple competencia entre software sin restricciones y hardware seguro. Los compradores están comparando mecanismos de aplicación, requisitos de implementación y supuestos de fallo.

El ejemplo de Anthropic aborda un entorno de ejecución para desarrolladores. El anuncio de NVIDIA conecta la ejecución de agentes con un diseño de infraestructura más amplio y una capa de hardware independiente opcional. Ninguna de las dos descripciones establece por sí sola qué enfoque se adapta mejor a una carga de trabajo empresarial concreta.

Para una organización que ejecuta tareas de desarrollo con un alcance limitado, los controles de entorno existentes merecen evaluarse por sus propios méritos. Para implementaciones sensibles que requieren mayor independencia del software anfitrión, el enfoque de hardware de NVIDIA presenta una opción distinta. La decisión debe responder a la amenaza que se busca abordar.

La disyuntiva clave es una separación más sólida a cambio de una mayor complejidad de implementación. Una capa adicional de aplicación crea otro punto en el que detener actividad insegura. También crea otro componente cuyas políticas, visibilidad, actualizaciones y responsabilidad operativa deben mantenerse coherentes con el resto del sistema.

Los anuncios de socios revelan distintas fases de preparación

Los detalles más útiles de los socios distinguen entre las capacidades disponibles ahora y las integraciones que siguen previstas.

ServiceNow ofrece un ejemplo concreto de cómo la arquitectura entra en la conversación sobre productos empresariales. Su anuncio sobre gobernanza de agentes empresariales indica que Arc, un agente personal diseñado para trabajos de larga duración, está disponible de forma general. ServiceNow describe la aplicación de OpenShell como parte de la ejecución gobernada de Arc.

El mismo anuncio sitúa la integración de AI Passport con la aplicación de OpenShell y BlueField en una futura versión. AI Passport es un registro de autoridad destinado a comunicar los permisos de un agente. Su condición prevista importa porque el lanzamiento actual de una aplicación no establece la disponibilidad de toda la cadena de gobernanza propuesta.

Esta distinción ofrece a los compradores una forma útil de interpretar otros materiales de lanzamiento. La disponibilidad expresada en presente debe evaluarse por separado de la integración prevista, la colaboración con socios y las capacidades futuras. Combinarlas en una única impresión de preparación oculta el trabajo que aún se necesita.

El ejemplo de ServiceNow también hace tangible el problema empresarial. Un agente persistente para el entorno laboral debe operar con asignaciones y permisos cambiantes. La gobernanza debe seguir siendo pertinente tras la solicitud inicial, especialmente cuando una tarea continúa más allá de la atención inmediata del usuario.

Un caso ilustrativo es el de un empleado que asigna a un agente la coordinación de la entrega de un proyecto. Leer documentos del proyecto, identificar trabajo pendiente, redactar mensajes y modificar derechos de acceso requieren distinta autoridad. Un sistema útil debe preservar esa distinción a medida que evoluciona la tarea.

Los socios de seguridad introducen otra capa de diferenciación. F5 describe la inspección del tráfico de IA que complementa los permisos de ejecución con el examen de prompts, respuestas y llamadas a herramientas compatibles. Su anuncio también distingue una topología de implementación propuesta sujeta a validación del producto.

Se trata de una salvedad importante, no de una nota menor. Un socio puede respaldar la dirección de la arquitectura mientras una configuración concreta sigue requiriendo validación. Los clientes deben preguntar qué implementación se ha probado, con qué funciones de inspección habilitadas y frente a qué carga de trabajo.

El planteamiento de F5 también separa la autorización de la evaluación del contenido. Una solicitud puede dirigirse a un servicio aprobado y, aun así, contener información sensible o instrucciones maliciosas. El permiso para conectarse y la evaluación del contenido transmitido abordan riesgos distintos.

Esto ayuda a explicar por qué el lanzamiento incluye socios de seguridad en lugar de presentar la aplicación de la infraestructura como un sustituto de todas las defensas existentes. El límite propuesto necesita información sobre identidad, autorización y actividad sospechosa. También necesita una respuesta operativa después de que algo sea bloqueado.

La cuestión comercial es si esas capas se vuelven más fáciles de operar conjuntamente. Los compradores deben buscar políticas coherentes y registros de incidentes comprensibles. Añadir consolas separadas sin una relación clara entre las decisiones obligaría a los investigadores a reconstruir lo ocurrido entre sistemas desconectados.

La amplitud de los socios indica interés, pero el detalle de la implementación tiene más peso. Un cliente puede evaluar una configuración compatible, una limitación documentada o una integración entregada. El nombre de una empresa en una lista de lanzamiento aporta menos evidencia sobre lo que ese cliente puede operar de forma segura hoy.

Los límites seguros siguen dependiendo de reglas correctas

La arquitectura de referencia NVIDIA OpenShell no elimina la distinción entre una acción autorizada y una buena decisión.

Un agente puede mantenerse dentro de sus permisos y aun así producir un resultado incorrecto. Puede interpretar mal un documento, elegir el registro equivocado o hacer una recomendación deficiente. La contención de infraestructura aborda el alcance de la acción; no establece la veracidad de cada conclusión.

Esta distinción debe determinar cómo interpretan las organizaciones la palabra “seguro”. La seguridad es un resultado amplio, mientras que la aplicación en tiempo de ejecución proporciona controles concretos. Una evaluación significativa identifica el fallo que se previene y los supuestos bajo los que esa prevención se mantiene.

Imagine un agente autorizado para actualizar un sistema de programación. Una restricción podría impedir con éxito que acceda a datos de nóminas. El mismo agente podría seguir programando la cita equivocada dentro de la aplicación permitida. Ambos resultados importan, pero requieren salvaguardas diferentes.

Los permisos excesivamente amplios crean otra limitación. Una regla aplicada perfectamente que permite a un agente exportar un conjunto de datos completo no protege ese conjunto de datos frente a una exportación autorizada. La calidad de la decisión empresarial sigue siendo central incluso cuando la aplicación funciona exactamente según lo diseñado.

Los permisos excesivamente restringidos crean el problema opuesto. Si el trabajo rutinario se detiene repetidamente, los usuarios tienen incentivos para solicitar accesos más amplios. Los equipos de seguridad necesitan entonces pruebas de qué bloqueos evitan daños y cuáles reflejan políticas mal ajustadas a tareas legítimas.

Esta es una preocupación analítica, no una conclusión de que OpenShell cause interrupciones innecesarias. Identifica la medición necesaria para evaluar la disyuntiva de autonomía. La contención exitosa debe considerarse junto con la finalización útil de tareas, la frecuencia de intervención y las consecuencias de las operaciones denegadas.

El momento de detección también necesita contexto. Una afirmación de cuarentena rápida describe la respuesta después de detectar una condición relevante. Los compradores aún necesitan entender qué eventos activan la detección y si un sistema externo ya ha actuado antes de que comience la contención.

Las descripciones disponibles de los proveedores no establecen una garantía universal verificada de forma independiente para los flujos de trabajo empresariales. Explican mecanismos previstos y puntos de integración. Las conclusiones sobre seguridad en producción requieren evidencia vinculada a la configuración implementada, incluidos sus permisos y protecciones habilitadas.

También existe una dimensión de privacidad en la observabilidad ampliada. Examinar las comunicaciones y el contexto de ejecución puede mejorar las investigaciones, al tiempo que expone material sensible a componentes de seguridad adicionales. Las organizaciones necesitan decisiones claras sobre el alcance de la inspección, el acceso a los registros y la retención.

La responsabilidad operativa merece la misma atención. Alguien debe mantener las políticas, investigar denegaciones, aprobar excepciones y restaurar un agente tras la contención. Si estas responsabilidades siguen sin estar claras, un límite técnicamente eficaz puede aun así provocar una interrupción prolongada o una solución alternativa insegura.

El enfoque de NVIDIA hace estas preguntas más concretas porque identifica lugares donde las reglas pueden aplicarse de forma independiente. Es un progreso útil en el diseño de sistemas. No elimina la necesidad de evaluar las propias reglas ni el flujo de trabajo que rodea una decisión de seguridad.

Por tanto, el estándar apropiado es una afirmación acotada: controles concretos previenen acciones no autorizadas concretas bajo condiciones especificadas. Los compradores deben evitar convertir esa afirmación en una promesa general de que un agente no puede causar daño.

Observe las integraciones entregadas, la evidencia de seguridad y el ajuste operativo

Las próximas señales significativas son capacidades entregadas, validación reproducible y evidencia de que las organizaciones pueden mantener los controles resultantes.

Durante los próximos meses, la primera señal será la entrega de las integraciones descritas como trabajo futuro. La aplicación prevista de AI Passport por parte de ServiceNow ofrece un ejemplo específico. Una versión con compatibilidad y limitaciones documentadas facilitaría evaluar la conexión propuesta entre la autoridad empresarial y la aplicación de infraestructura.

Eso reforzaría el argumento de que las empresas pueden trasladar una decisión de gobernanza entre capas de ejecución. La continuidad del lenguaje de hoja de ruta dejaría esa parte de la propuesta menos consolidada. Los compradores deben distinguir la disponibilidad de productos de las demostraciones o los anuncios de colaboración.

La segunda señal es la validación de seguridad vinculada a una implementación completa. Una evidencia útil describiría la carga de trabajo, la configuración de políticas, la inspección habilitada, la acción no autorizada intentada y el resultado observado. También debería explicar qué trabajo legítimo siguió siendo posible.

Una demostración que muestra que un agente ha sido detenido establece menos que una explicación reproducible de por qué fue detenido. Esta última ayuda a los clientes a determinar si el mismo control se aplica a sus aplicaciones. También expone supuestos que una presentación puede dejar sin expresar.

La validación debe incluir flujos de trabajo permitidos además de ataques. Un límite que bloquea actividad no autorizada mientras permite el trabajo esperado respalda la disyuntiva central de la arquitectura. La dependencia repetida de excepciones amplias debilitaría la afirmación de que las empresas pueden combinar autonomía con control preciso.

La tercera señal es el ajuste operativo en entornos empresariales reales. Las organizaciones necesitan saber si las políticas se mantienen coherentes a medida que cambian las aplicaciones, las identidades y las herramientas. También necesitan registros de incidentes que expliquen la relación entre la acción solicitada y la decisión de aplicación.

La evidencia de actualizaciones de políticas manejables e investigaciones comprensibles reforzaría el argumento de implementación. La evidencia de reglas incoherentes o propiedad poco clara identificaría un cuello de botella distinto. En esa situación, una capacidad adicional de aplicación no resolvería por sí sola el problema de gobernanza.

Las implementaciones locales y en el borde merecen atención particular dentro de esa evaluación operativa. Los lectores deben buscar capacidades documentadas del sistema específico que se está implementando. Una familia de productos o una etiqueta de arquitectura compartida no responde a todas las preguntas sobre la cobertura de aplicación.

Para los desarrolladores, la consecuencia práctica es una demanda de requisitos de permisos más claros. Para los compradores empresariales, es una demanda de evidencia específica de la configuración. Para los trabajadores del conocimiento, es una distinción entre conceder a un agente acceso a la información y delegarle autoridad para actuar.

Antes de aprobar un despliegue, identifique el flujo de trabajo exacto que quiere que complete un agente y las acciones que deben permanecer fuera de su autoridad. Pida al proveedor que muestre ambos resultados en la configuración propuesta: que el trabajo legítimo continúe y que una acción no autorizada se detenga. Después, examine quién mantiene la política, cómo entran en vigor los cambios de acceso y qué pueden reconstruir posteriormente los investigadores. Mantenga separadas las capacidades actuales de las integraciones prometidas, especialmente cuando las versiones de software y hardware siguen calendarios distintos. La NVIDIA OpenShell Reference Architecture ofrece un diseño de infraestructura concreto para evaluar estos aspectos. Úsela para exigir una respuesta precisa a una pregunta práctica: ¿qué decisiones siguen bajo el control de su organización mientras el agente trabaja de forma independiente?