Los agentes de IA se están moviendo rápidamente más allá del chat. Inspeccionan código, corren tests, leen documentos, buscan en bases de conocimiento, consultan sistemas internos y operan durante horas en representación de un usuario. Eso desbloquea productividad, pero también puede darles acceso a datos empresariales sensibles y la capacidad de completar tareas y ejecutar acciones a través de los sistemas del negocio, lo que hace esencial un entorno seguro y gobernado.
El Secure Agent Workspace Reference Design de NVIDIA introduce un cambio arquitectónico claro: el laptop, navegador, IDE o terminal del usuario funciona como capa de presentación, no como capa de ejecución. La ejecución del agente ocurre en un workspace administrado donde identidad, acceso a la red, credenciales, políticas de runtime, auditoría y revisión humana se pueden aplicar de forma consistente.
¿Qué separa el diseño en dos capas?
Los pilares del diseño se pueden resumir en tres bloques:
- NVIDIA Secure Agent Workspace separa la capa de presentación (dispositivo del usuario) de la capa de ejecución (workspace administrado), imponiendo operación segura del agente mediante gestión controlada de identidad, red y políticas.
- Implementación que requiere provisionar máquinas virtuales dedicadas por usuario administradas por la empresa, forzar autenticación single sign-on, bloquear accesos de red no aprobados, exigir aprobación humana para acciones significativas y centralizar los logs para monitoreo y auditoría.
- Refuerzo adicional con sandbox activo, políticas de seguridad firmadas centralmente, protección estricta de credenciales via proxies, verificación continua de reglas, y uso de GitOps y gestión empresarial de identidades para operaciones repetibles, auditables y aisladas del agente tanto on-prem como en la nube.
¿Cómo asegurar el perímetro del workspace?
La primera fase de implementación se enfoca en controlar el perímetro alrededor del workspace: quién entra, cómo, qué workspace recibe y qué servicios puede alcanzar. En esta etapa la VM actúa como frontera primaria de aislamiento, y el objetivo es que la actividad del agente sea observable, acotada y revocable antes de sumar controles más profundos de runtime.
- Provisionar workspaces gestionados: entregar a cada usuario su propia máquina virtual administrada por la empresa.
- Puertas de login: usar el SSO corporativo para controlar el acceso; nadie abre un workspace sin permiso autenticado.
- Cerrar la red: bloquear todo tráfico de internet por defecto. Solo se permiten conexiones a servicios internos y externos aprobados previamente.
- Aprobación humana: cualquier acción del agente que modifique un sistema (mergear código, actualizar tickets) debe ser aprobada por una persona, no solo por el agente.
- Logs centralizados: enviar toda la actividad del workspace a un solo lugar para que seguridad monitoree comportamientos sospechosos.
¿Qué controles agrega el runtime dentro de la VM?
En la segunda fase se suman controles dentro del workspace para gobernar el comportamiento real del agente. Esto acerca la protección al límite de la llamada de herramientas: qué archivos puede leer el agente, qué comandos puede ejecutar y a qué servicios accede. Los secretos quedan detrás de un proxy, la política se controla centralmente y el agente no puede expandir silenciosamente sus permisos.
- Sandboxing activo: correr el agente dentro de un runtime dedicado (por ejemplo NVIDIA OpenShell) que vigile cada acción en tiempo real.
- Políticas firmadas: definir centralmente qué puede hacer el agente y enviar las reglas como bundles firmados y seguros al workspace.
- Protección de credenciales: no guardar contraseñas ni llaves secretas en el workspace. Usar un proxy que las administre por detrás para que el agente nunca vea el secreto crudo.
- Verificación continua: revisar automáticamente que las reglas estén activas antes de cada acción del agente.
¿Qué son los agent blueprints?
Los blueprints son plantillas reutilizables de flujos de trabajo que corren encima del workspace. Cada blueprint se configura con su objetivo, herramientas requeridas, servicios permitidos, alcance de datos, permisos de escritura, revisiones y expectativas de logging. Los blueprints deben integrarse al workspace con estos pasos:
- Definir identidad del agente: registrar al agente con una identidad lógica que se conecta al usuario o sponsor via SSO. Un registro de delegación define exactamente qué está autorizado a hacer.
- Manejar secretos: nunca hardcodear secretos. Usar un proxy de credenciales que entregue tokens de capacidad de corta vida en lugar de API keys crudas.
- Configurar inferencia: una capa gateway maneja quotas, control de acceso basado en roles (RBAC) y rate limiting dinámico para un servicio de inferencia seguro y escalable.
- Blindar la gobernanza: definir controles de "blast radius" (radio de impacto). Qué acciones (mergear código, cambiar el estado de un ticket) requieren revisión humana antes de ejecutarse, y garantizar que todos los logs salgan en formato Open Cybersecurity Schema Framework (OCSF) para auditoría.
¿Cómo se despliega on-prem o en la nube?
El despliegue puede elegir Red Hat OpenShift Virtualization para ambientes on-premises o Microsoft Azure para escenarios cloud-native. El patrón central es el mismo en ambos: cada usuario recibe una máquina virtual dedicada y el endpoint local solo se conecta a ese workspace. La ejecución del agente sigue dentro de un límite gestionado con política centralizada, control de acceso y auditoría.
Los pasos son:
1. Provisionar una VM por usuario: crear una VM dedicada Linux o Windows para cada usuario.
2. Establecer la ruta de acceso: poner un broker de acceso confiable delante del workspace. Los usuarios se conectan por SSO corporativo y sesiones cortas y auditables. El endpoint solo actúa como superficie de presentación, sin ejecución autónoma del agente localmente.
3. Definir la frontera de red: partir con egreso denegado por defecto y permitir solo destinos aprobados. En OpenShift, usar primitivas como NetworkPolicy, EgressFirewall, rutas e ingresos aprobados. En Azure, enrutar el tráfico saliente por Azure Firewall Premium, deshabilitar la propagación de rutas BGP, denegar el acceso a CIDR corporativos y evitar cualquier ruta entrante pública.
4. Administrar imágenes y perfiles centralmente: usar solo imágenes de VM aprobadas. En OpenShift, gestionar perfiles y estado de la plataforma con GitOps. En Azure, construir imágenes doradas con Packer y publicarlas via Azure Compute Gallery.
5. GitOps para intent de políticas: guardar perfiles de VM, reglas de red, metadata de políticas y releases en Git. GitOps reconcilia el estado deseado, mientras los bundles de políticas de runtime firmados se distribuyen por un canal de release controlado.
6. Proteger secretos e identidad: mantener secretos crudos fuera del proceso del agente cuando se pueda. En Azure, usar Workload Identity Federation para provisionamiento sin secretos, managed identities para acceso runtime de VM, Azure Key Vault por Private Endpoints y una identidad de runtime acotada antes de que arranque el código del agente.
7. Centralizar auditoría y observabilidad: capturar eventos de ciclo de vida del workspace, sesiones del broker, releases de política, actividad allow/deny de red y eventos de runtime/tool. Enviar logs al SIEM empresarial o stack de logging de plataforma (Azure Monitor, Log Analytics, Microsoft Sentinel o path de auditoría compatible con OCSF).
El estado final es un patrón práctico de Secure Agent Workspace: VMs de un solo usuario aportan aislamiento, GitOps entrega operaciones repetibles, la identidad corporativa controla el acceso, la política de red limita el alcance y el enforcement de runtime agrega una capa más profunda de política para la seguridad del agente autónomo. Los recursos para implementarlo están en la documentación oficial.
