top of page

NVIDIA lanza Open Agent Safety Platform, trasladando las barreras de seguridad de la IA fuera del modelo

hace 1 hora
16 min de lectura

NVIDIA lanzó Open Agent Safety Platform el 28 de septiembre con un claro desafío al modelo de seguridad actual de la industria de la IA. En lugar de confiar en que los agentes obedezcan los prompts, NVIDIA pretende que el software y el hardware externos al agente controlen cada acción.

La plataforma combina OpenShell, un entorno de ejecución de código abierto para la ejecución aislada de agentes, con Sentry, un diseño de monitorización independiente basado en unidades de procesamiento de datos NVIDIA BlueField-4. NVIDIA afirma que Sentry puede poner en cuarentena a un agente en milisegundos cuando cruza un límite autorizado.

Esta distinción hace que sea más que otro framework de agentes. NVIDIA sostiene que la alineación de modelos y las instrucciones a nivel de aplicación no pueden proporcionar suficiente control una vez que los agentes reciben credenciales, acceso a la red y permiso para modificar sistemas reales. Su alternativa propuesta se asemeja a la seguridad de infraestructura convencional: denegar el acceso por defecto, conceder permisos limitados, registrar cada decisión y mantener la aplicación de controles fuera del alcance de la carga de trabajo.

La pregunta inmediata no es si OpenShell puede colocar un agente dentro de una zona aislada. Los sistemas operativos y las plataformas en la nube existentes ya ofrecen herramientas de aislamiento. La cuestión más difícil es si NVIDIA puede convertir la contención de agentes en una capa de infraestructura práctica sin bloquear el trabajo que las empresas quieren que realicen los agentes.

NVIDIA lanza Open Agent Safety Platform con dos capas de control

NVIDIA ha dividido la seguridad de los agentes en un límite de software y un respaldo de hardware independiente.

OpenShell proporciona la primera capa. Ejecuta cada agente dentro de un entorno aislado y aplica políticas que cubren archivos, procesos, destinos de red, credenciales y endpoints de modelos. El agente puede recibir el acceso requerido para una tarea sin obtener control sin restricciones sobre su sistema anfitrión.

NVIDIA describe OpenShell como un entorno de ejecución y no como un framework de agentes. Se sitúa por debajo de herramientas como Claude Code, Codex, GitHub Copilot CLI, OpenCode y sistemas de agentes personalizados. Los desarrolladores no necesitan reemplazar el modelo de razonamiento del agente ni el arnés de aplicación para utilizar el límite de seguridad.

El entorno de ejecución adopta un enfoque de denegación por defecto. Un agente no recibe acceso general a la red, privilegios elevados ni permisos amplios sobre el sistema de archivos al iniciarse su zona aislada. Después, los administradores definen recursos aprobados mediante políticas legibles por máquina.

Por ejemplo, un agente de procesamiento de facturas podría recibir permiso para leer una carpeta específica y contactar con una API de contabilidad aprobada. Podría seguir sin poder eliminar facturas, inspeccionar directorios no relacionados o enviar datos a un sitio web no aprobado.

OpenShell también separa el uso de credenciales de su posesión. El supervisor, que se ejecuta fuera de la zona aislada, puede proporcionar credenciales solo cuando una política autoriza una solicitud concreta. El agente no necesita acceso directo al secreto subyacente.

El entorno de ejecución evalúa la actividad de red mediante detalles como el binario solicitante, el destino, el método y la ruta. Puede aplicar actualizaciones de políticas mientras un agente sigue en ejecución. Cada acción permitida o denegada pasa a formar parte de un registro de auditoría.

La arquitectura de OpenShell de NVIDIA también incluye un verificador de políticas. Este componente utiliza verificación formal, un método matemático para comprobar si reglas especificadas satisfacen propiedades definidas, antes de que los administradores apliquen cambios de políticas.

El verificador aborda un problema sutil. Los equipos de seguridad suelen entender que un agente necesita acceso a un nuevo servicio, pero no pueden ver fácilmente todas las capacidades que crea un cambio de política. Una regla que parece limitada podría abrir una ruta de red inesperada o poner una credencial al alcance.

Sentry proporciona la segunda capa. Se ejecuta en un dominio de confianza aislado sobre las DPU BlueField-4, procesadores especializados que gestionan cargas de trabajo de infraestructura y seguridad fuera de la CPU principal.

Según el anuncio de la plataforma de NVIDIA, Sentry monitoriza de forma independiente la actividad de los agentes y puede detener comportamientos sospechosos en milisegundos. NVIDIA afirma que el sistema utiliza su software DOCA para inspeccionar solicitudes, verificar identidades, proteger el acceso a los datos y generar telemetría certificada.

Esta separación importa porque un agente no puede simplemente dar instrucciones a Sentry mediante prompts, reescribir sus indicaciones ni desactivarlo desde el entorno de trabajo. Incluso un entorno de ejecución comprometido se enfrenta a otro punto de aplicación de controles más allá del sistema principal.

OpenShell está ampliamente disponible, mientras que Sentry se presenta como parte de un diseño de sistema de referencia vinculado a BlueField-4. Según NVIDIA, el software de OpenShell también puede ampliarse a procesadores de Arm e Intel.

El resultado es una propuesta por capas en lugar de un único producto de seguridad. OpenShell limita lo que un agente puede hacer durante la operación normal. Sentry vigila desde fuera de ese límite y responde cuando la actividad parece escapar de él.

Por qué la seguridad de los agentes está yendo más allá de los prompts

Un agente que puede actuar crea un problema de seguridad que unas mejores instrucciones por sí solas no pueden resolver.

Los chatbots tradicionales devuelven texto para que una persona lo revise. Los agentes autónomos pueden leer archivos locales, instalar paquetes, llamar a servicios externos, utilizar tokens de autenticación, modificar código y seguir trabajando sin aprobación constante.

Estas capacidades hacen útiles a los agentes. También amplían las consecuencias de una suposición equivocada, una entrada manipulada, una dependencia comprometida o una instrucción ambigua.

Un prompt puede indicarle a un agente que no comparta información confidencial. Esa instrucción no impide físicamente que el agente abra un archivo sensible o contacte con un servidor desconocido. Las barreras de seguridad de la aplicación siguen formando parte del mismo entorno de software que el agente explora.

La inyección de prompts hace que esta debilidad sea especialmente importante. Un agente podría encontrarse con instrucciones hostiles dentro de un sitio web, documento, correo electrónico, gestor de incidencias o repositorio de código fuente. Esas instrucciones pueden intentar redirigir al agente mientras aparentan ser datos legítimos de la tarea.

Un modelo también puede malinterpretar una solicitud válida sin encontrarse con un atacante. Un agente de programación al que se le pide limpiar un proyecto podría eliminar archivos necesarios. Un agente de investigación podría enviar información a un servicio no autorizado porque considera útil ese paso.

Justin Boitano, vicepresidente de IA empresarial de NVIDIA, dijo a los periodistas que los agentes pueden desviarse cuando las instrucciones son ambiguas o las herramientas se comportan de manera inesperada. Su argumento central fue que no se puede esperar que un agente se controle a sí mismo una vez que puede actuar.

Este es el principio que sustenta el anuncio de NVIDIA lanza Open Agent Safety Platform. El razonamiento de los agentes sigue siendo probabilístico, pero los permisos de infraestructura pueden ser deterministas. Un motor de políticas puede rechazar una conexión de red independientemente de la explicación del modelo para solicitarla.

El cambio se parece a transformaciones anteriores en la seguridad en la nube. Las organizaciones dejaron de depender únicamente de que los desarrolladores de aplicaciones protegieran cada base de datos, secreto y ruta de red. Añadieron gestión de identidades, aislamiento de cargas de trabajo, motores de políticas y monitorización fuera de cada aplicación.

La seguridad de los agentes se enfrenta ahora a una transición similar. El modelo sigue necesitando entrenamiento de seguridad y la aplicación sigue necesitando instrucciones sensatas. Ninguna de las dos capas debería recibir autoridad ilimitada simplemente porque funciona bien durante las pruebas.

La posición de NVIDIA también presiona a los proveedores de plataformas de agentes. Los controles de seguridad implementados solo dentro de un arnés de agentes resultan menos convincentes cuando un entorno de ejecución externo puede aplicar permisos en varios modelos y frameworks.

Los proveedores de nube también afrontan presión. Los clientes que despliegan flotas de agentes esperarán cada vez más límites de identidad, intermediación de credenciales, controles de salida y registros de auditoría diseñados para cargas de trabajo autónomas. Los contenedores genéricos no responderán a todas las cuestiones de gobernanza.

Las empresas constituyen el tercer grupo sometido a presión. Una compañía no puede afirmar que un agente actúa con el principio de mínimo privilegio si no puede explicar a qué recursos accede el agente, cómo cambian los permisos y quién puede detenerlo.

Ese requisito va más allá de los escenarios dramáticos de agentes fuera de control. Los equipos de cumplimiento necesitan registros de las operaciones ordinarias, incluidos el acceso a archivos, las llamadas a API, los cambios de políticas y el uso de credenciales.

NVIDIA afirma que más de 100 organizaciones están trabajando con tecnologías de la plataforma. Su grupo anunciado incluye Anthropic, Cisco, CrowdStrike, Dell Technologies, Hugging Face, JPMorganChase, Microsoft, Palantir, Perplexity, Red Hat, Salesforce, SAP, Scale AI, ServiceNow y otras.

Esta lista indica un amplio interés, pero no demuestra madurez para producción. “Trabajar con” puede abarcar evaluaciones, integraciones, ingeniería conjunta o soporte planificado. Los compradores aún necesitan pruebas de despliegue y resultados operativos.

OpenShell 0.1 convierte el mínimo privilegio en un entorno de ejecución para agentes

La principal contribución de OpenShell no es un modelo más inteligente, sino una capa de control reutilizable bajo muchos modelos diferentes.

La línea de versiones OpenShell 0.1 formaliza ese enfoque mediante una cadencia de lanzamientos estable, puntos de extensión ampliados, nuevas API y mecanismos de aislamiento adicionales. Su repositorio de código abierto expone el entorno de ejecución, el sistema de políticas, los kits de desarrollo de software y los materiales de despliegue para su inspección.

Cada agente se ejecuta dentro de una zona aislada con una cuenta sin privilegios y capacidades reducidas del sistema operativo. Los controles de Linux restringen el acceso al sistema de archivos y las llamadas al sistema, mientras que las conexiones salientes pasan por comprobaciones de políticas.

La arquitectura separa la zona aislada de su supervisor. El agente opera dentro del límite restringido de la carga de trabajo, mientras que el supervisor permanece fuera e intermedia el acceso autorizado. Una puerta de enlace gestiona usuarios, zonas aisladas, políticas, configuraciones y credenciales.

Esta separación reduce la autoridad que posee el proceso del agente. Si un modelo genera un comando de shell que solicita un archivo prohibido, el entorno operativo bloquea la acción. La confianza del modelo o su justificación declarada no cambian ese resultado.

Las políticas de OpenShell son declarativas. Los administradores describen el comportamiento permitido en la configuración en lugar de integrar cada restricción dentro del código de la aplicación. Esto crea una superficie de revisión común para los equipos de seguridad, plataforma y desarrollo.

Las políticas cubren varias áreas relacionadas. Las reglas del sistema de archivos distinguen las rutas legibles de las escribibles. Los controles de procesos reducen privilegios y restringen las llamadas al sistema. Las reglas de red evalúan destinos, puertos, binarios y detalles a nivel de aplicación.

Los perfiles de proveedores conectan los servicios aprobados con las credenciales y reglas de red correspondientes. Esto puede mantener un token de API vinculado a su destino previsto en lugar de colocarlo en una variable de entorno general.

El entorno de ejecución también admite el enrutamiento de inferencia. Una empresa puede gobernar qué endpoints de modelos utiliza un agente mientras mantiene las credenciales de proveedores fuera de la zona aislada. Esto importa cuando los equipos combinan modelos locales, API en la nube y datos restringidos.

La observabilidad completa el ciclo de control básico. OpenShell registra las decisiones y puede exportar eventos de seguridad en un formato estructurado. Los investigadores pueden revisar qué solicitó un agente, qué permitió el entorno de ejecución y qué denegó.

Estas capacidades encajan especialmente bien con los agentes de programación. Un desarrollador podría permitir a un agente leer un repositorio, crear archivos dentro de una rama de trabajo, descargar paquetes de registros aprobados y contactar con un endpoint de modelo autorizado.

La misma política puede bloquear el acceso a repositorios no relacionados, directorios personales, credenciales de producción y sitios web arbitrarios. Si el agente solicita un acceso más amplio, una persona o un sistema de confianza puede revisar el cambio propuesto.

El diseño también admite agentes de larga duración. Un sandbox tradicional suele proteger un proceso acotado para una tarea limitada. OpenShell busca gobernar la actividad cambiante de los agentes a lo largo del tiempo, incluidas las actualizaciones de políticas y los flujos de trabajo con subagentes.

Esa ambición introduce complejidad operativa. Las políticas deben admitir variaciones legítimas sin volverse tan amplias que pierdan su valor protector. Los equipos también necesitan procesos para revisar excepciones sin paralizar cada tarea.

La verificación formal ayuda a evaluar la estructura de una política propuesta. No puede decidir si la empresa pretendía autorizar una acción peligrosa. La gobernanza humana sigue determinando el límite aceptable.

El carácter de código abierto de OpenShell ofrece a las organizaciones otra ventaja. Los investigadores de seguridad pueden inspeccionar la implementación, poner a prueba las suposiciones y proponer cambios. Las empresas también pueden ampliar el software para distintas plataformas de cómputo o entornos de implementación.

El código abierto no produce automáticamente software seguro. Proporciona las condiciones para una revisión independiente, pero un escrutinio útil exige mantenedores activos, procesos claros de divulgación, pruebas reproducibles y correcciones rápidas.

La versión 0.1 también transmite cautela. El proyecto ya cuenta con una arquitectura pública concreta, pero los primeros adoptantes deben esperar cambios en las API, las políticas, las prácticas de implementación y las integraciones a medida que las cargas de trabajo reales revelen limitaciones.

La principal disputa es la aplicación de controles frente a la autodisciplina del agente

NVIDIA apuesta a que los controles de infraestructura aplicables superarán a las reglas de seguridad que permanecen dentro del ciclo de razonamiento del agente.

No se trata principalmente de una disputa entre NVIDIA y otro fabricante de chips. Es una disputa entre dos vías de seguridad: pedir a un agente que se comporte de forma segura y construir un entorno donde las acciones inseguras fallen.

Los proveedores de modelos continúan mejorando la alineación, el comportamiento de rechazo, la jerarquía de instrucciones y la supervisión. Estas medidas pueden reducir la probabilidad de que un modelo elija una acción dañina. También abordan comportamientos que los controles de infraestructura no pueden reconocer por sí solos.

OpenShell aborda una capa diferente. Asume que un modelo acabará cometiendo un error, siguiendo un contexto manipulado o intentando una operación no autorizada. El entorno de ejecución se centra en limitar el daño resultante.

Las dos vías deberían complementarse, pero sus prioridades difieren. La alineación busca mejorar las decisiones del agente. La aplicación de controles en tiempo de ejecución asume que las decisiones siguen siendo falibles y restringe sus consecuencias.

La participación de Anthropic ilustra este enfoque combinado. NVIDIA afirma que Claude Managed Agents separa el ciclo del agente de los sandboxes de ejecución. OpenShell y BlueField pueden añadir controles adicionales sobre el acceso a través de esos sandboxes.

Esta disposición crea una defensa en profundidad, lo que significa que varios controles independientes se interponen entre el agente y los recursos sensibles. Un fallo en una capa no derrota automáticamente todas las demás.

La plataforma también admite modelos abiertos y cerrados. Esta posición independiente del modelo es estratégicamente importante para NVIDIA porque la empresa suministra infraestructura en ecosistemas de IA competidores. Un entorno de ejecución compartido podría resultar útil independientemente del modelo que lidere un mercado concreto.

Sin embargo, la portabilidad del software y la independencia del hardware no son idénticas. OpenShell puede extenderse más allá de las CPU de NVIDIA, mientras que el diseño completo de Sentry depende de BlueField-4 para una aplicación aislada y a nivel de silicio.

Esto crea una tensión comercial dentro de la plataforma “abierta”. La capa de software puede admitir infraestructura heterogénea, pero el argumento de contención más sólido de NVIDIA destaca el hardware de red de NVIDIA y su pila DOCA.

Los competidores y los proveedores de nube pueden responder de varias maneras. Pueden admitir OpenShell en sus plataformas, crear sistemas de políticas compatibles o promover como alternativas las funciones existentes de aislamiento y computación confidencial.

Los proveedores de seguridad también pueden conectar la actividad de los agentes con productos consolidados de protección de endpoints, identidad, red y datos. Es probable que la gobernanza de agentes se convierta en otra capa de la arquitectura de seguridad empresarial, en lugar de un mercado independiente.

Por tanto, el evento de lanzamiento de NVIDIA Open Agent Safety Platform amplía el papel de NVIDIA. La empresa no se limita a suministrar capacidad de cómputo para entrenamiento e inferencia. Quiere ayudar a definir cómo las cargas de trabajo autónomas reciben autoridad y cómo la infraestructura la revoca.

Esta posición otorga a NVIDIA influencia sobre un nuevo plano de control. Si las políticas de OpenShell se adoptan ampliamente, el entorno de ejecución podría moldear las expectativas sobre identidad de agentes, auditabilidad, manejo de credenciales y acceso a la red.

La adopción dependerá de la neutralidad. Las empresas pueden dudar si una capa de seguridad supuestamente universal favorece claramente a una pila de hardware. Serán importantes unas interfaces claras y un respaldo creíble para sistemas ajenos a NVIDIA.

Los desarrolladores evaluarán una cuestión distinta: la fricción. Una capa de seguridad que interrumpa constantemente el trabajo útil fomentará excepciones amplias, implementaciones abandonadas o mecanismos extraoficiales para eludirla.

La plataforma solo tendrá éxito si los permisos restringidos siguen siendo prácticos. Eso requiere herramientas que ayuden a los equipos a descubrir el acceso necesario, explicar las denegaciones, probar políticas y aprobar cambios sin convertir cada tarea de un agente en un ticket de seguridad.

Lo que la plataforma de seguridad de NVIDIA todavía no puede garantizar

La contención puede restringir el alcance de un agente, pero no puede determinar si toda acción permitida es correcta.

Un agente puede causar daños sin salirse de sus permisos formales. Un agente financiero autorizado para enviar facturas podría aprobar un documento fraudulento. Un agente de programación con acceso de escritura podría introducir una vulnerabilidad sutil en un repositorio autorizado.

OpenShell puede registrar esas acciones y restringir su alcance. No puede comprender de forma independiente la intención, la lógica empresarial o los requisitos éticos de cada organización.

La calidad de la política sigue siendo fundamental. Si un administrador concede acceso amplio al sistema de archivos, salida de red sin restricciones o credenciales reutilizables, el entorno de ejecución aplicará con precisión un límite débil.

Earlence Fernandes, investigador de la University of California, San Diego, describió la plataforma como un paso en la dirección correcta. También advirtió que definir el acceso mínimo necesario sigue siendo difícil porque los agentes útiles necesitan recursos reales.

Somesh Jha, profesor de informática de la University of Wisconsin, planteó una preocupación relacionada. Declaró a la Associated Press que los estudios de caso deben mostrar cómo el sistema equilibra la seguridad frente al bloqueo de trabajo útil.

Los falsos positivos constituyen un lado de ese equilibrio. Si Sentry pone en cuarentena cargas de trabajo legítimas, las organizaciones podrían perder confianza en las operaciones autónomas. Necesitan procedimientos de recuperación fiables y explicaciones para cada intervención.

Los falsos negativos constituyen el otro lado. El comportamiento sospechoso puede parecerse a una actividad válida, especialmente cuando un agente utiliza herramientas aprobadas con un propósito no previsto. Una solicitud permitida todavía puede filtrar información a través de su contenido.

NVIDIA afirma que Sentry puede intervenir en cuestión de milisegundos. La velocidad importa tras la detección, pero la afirmación pública no establece la precisión de detección en entornos diversos.

Los benchmarks independientes deberán medir más que la latencia de cuarentena. Los evaluadores deberían probar intentos de escape, elusión de políticas, uso indebido de credenciales, transferencia encubierta de datos, dependencias comprometidas y ataques contra el propio plano de control.

La sobrecarga de rendimiento también necesita una medición cuidadosa. NVIDIA describe como mínima la sobrecarga de OpenShell en las CPU Vera. Los compradores necesitan resultados específicos por carga de trabajo que cubran agentes con uso intensivo de red, grandes cadenas de herramientas, cambios frecuentes de políticas y muchos sandboxes simultáneos.

La dependencia de hardware del sistema completo presenta otra incertidumbre. BlueField puede aislar la aplicación de controles de la carga de trabajo principal, lo que refuerza el modelo de seguridad. También añade requisitos de infraestructura que los adoptantes de soluciones exclusivamente de software no afrontan.

La plataforma no elimina la necesidad de trabajar en la alineación de modelos. No puede detener resultados engañosos, razonamiento deficiente, pruebas fabricadas, recomendaciones sesgadas o contenido dañino cuando esos comportamientos ocurren dentro de canales permitidos.

Tampoco puede resolver la responsabilidad. Las organizaciones todavía deben decidir quién aprueba los permisos, quién revisa los registros, quién responde a los eventos de contención y quién asume la responsabilidad por las acciones autorizadas de un agente.

NVIDIA ha vinculado el lanzamiento con incidentes recientes en los que agentes excedieron los límites previstos. La cobertura inicial destaca correctamente la importancia de OpenShell y de la plataforma de seguridad más amplia.

Sin embargo, las afirmaciones de que el sistema habría evitado una brecha anterior siguen siendo evaluaciones retrospectivas de la empresa. Las pruebas que reproduzcan incidentes y los ejercicios independientes de red team aportarían pruebas más sólidas.

La interpretación más creíble es más limitada. NVIDIA ha presentado una respuesta seria a nivel de sistemas frente al riesgo de los agentes, pero no ha resuelto la seguridad de la IA en su conjunto. La plataforma puede reducir la superficie de ataque accesible cuando las organizaciones la configuran correctamente.

Tres señales mostrarán si la plataforma funciona

La próxima evidencia debe proceder de implementaciones, pruebas independientes y soporte más allá de la propia infraestructura de NVIDIA.

La primera señal es la experiencia de producción publicada por las organizaciones nombradas en el lanzamiento. La lista de socios es considerable, pero los clientes necesitan relatos detallados sobre políticas, acciones bloqueadas, sobrecarga operativa y respuesta a incidentes.

Un estudio de caso significativo describiría un flujo de trabajo real de un agente y sus permisos necesarios. Mostraría qué acciones denegó OpenShell, cómo los desarrolladores ajustaron las políticas y si esos controles interrumpieron el trabajo legítimo.

La evidencia procedente de entornos regulados sería especialmente útil. Los bancos, las organizaciones sanitarias, las agencias gubernamentales y los operadores de infraestructuras críticas afrontan requisitos estrictos de control de acceso y auditabilidad.

Si estas organizaciones llevan OpenShell a producción, el argumento de NVIDIA gana fuerza. Si la actividad sigue limitada a demostraciones y evaluaciones, el lanzamiento parecerá más una propuesta arquitectónica.

La segunda señal es la validación de seguridad independiente. Los investigadores necesitan acceso a implementaciones representativas, modelos de amenazas, guías de configuración y pruebas reproducibles.

Las pruebas deberían examinar el sandbox, el supervisor, la puerta de enlace, el demostrador de políticas, el intermediario de credenciales y el límite de Sentry. Los atacantes apuntarán a las interacciones entre componentes, no solo al componente que NVIDIA considera más sólido.

Los investigadores también deberían examinar fallos de usabilidad. Un sistema de seguridad técnicamente correcto puede volverse ineficaz cuando los administradores copian ejemplos permisivos, malinterpretan los valores predeterminados o desactivan controles tras denegaciones repetidas.

La documentación pública de NVIDIA ya ofrece a los desarrolladores material para inspeccionar. El siguiente paso es una revisión externa sostenida, una gestión transparente de vulnerabilidades y correcciones visibles cuando los investigadores encuentren fallos.

La tercera señal es una portabilidad creíble. El software de OpenShell puede extenderse a plataformas Arm e Intel, pero las afirmaciones más sólidas sobre Sentry siguen vinculadas a BlueField-4.

Las integraciones operativas en sistemas de nube, híbridos, locales y aislados de la red respaldarían la afirmación de NVIDIA de que se trata de una capa abierta de seguridad para agentes. Una concentración limitada en hardware de NVIDIA debilitaría ese posicionamiento.

El respaldo de los proveedores de sistemas operativos podría ayudar. Canonical, Red Hat y SUSE figuran entre las organizaciones que NVIDIA identifica como integradoras de tecnologías de plataforma en infraestructura de uso habitual.

Los desarrolladores también deberían seguir de cerca la cadencia de lanzamientos de OpenShell. La compatibilidad con las políticas, las API estables, las guías de migración y las mejoras de observabilidad determinarán si la versión 0.1 evoluciona hasta convertirse en una infraestructura fiable.

El anuncio del lanzamiento de NVIDIA Open Agent Safety Platform establece un estándar útil para el debate. La seguridad de los agentes debería incluir controles que un agente no pueda reescribir, persuadir ni ignorar.

Ese estándar no exige que todas las empresas adopten el diseño completo de NVIDIA. Sí exige que los compradores planteen preguntas más rigurosas sobre acceso, aislamiento, credenciales, auditoría y contención de emergencia.

Los equipos que evalúan agentes autónomos pueden empezar por identificar todos los recursos a los que puede acceder un agente. Deberían determinar qué controles dependen de la cooperación del modelo y cuáles siguen siendo aplicables cuando el modelo se comporta de forma inesperada.

También pueden mantener una base de conocimientos de ingeniería para políticas, acciones denegadas, decisiones sobre excepciones y hallazgos de incidentes. Ese registro ayuda a que las reglas de seguridad evolucionen a partir de evidencias, en lugar de conjeturas.

La prueba práctica es sencilla: ¿puede una organización permitir que un agente realice trabajo valioso sin concederle una autoridad muy superior a la necesaria para esa tarea? OpenShell y Sentry ofrecen la respuesta de NVIDIA. La evidencia en producción determinará si se sostiene.

 
 

Empieza gratis

Un asistente de IA local-first con gestión del conocimiento personal

Para ofrecer una mejor experiencia con la IA,

actualmente remio solo es compatible con Windows 10+ (x64) y M-Chip Macs.

Tu aliado de IA para el trabajo
Haz más con remio

Planifica. Crea. Entrega.
Todo en un solo lugar.

bottom of page