# OpenShell: la política del agente debe poder demostrarse antes de ejecutarse > OpenShell convierte permisos, aislamiento y cambios de capacidad en una política validable cuya evidencia precede a la acción del agente. - Author: Viktor Berthelius (BRTHLS) - Published: 2026-10-29 - Category: automation aiops - Tags: openshell, agent-security, policy-as-code, sandbox - Language: es - Canonical: https://www.brthls.com/magazine/openshell-politica-agente-demostrarse-antes-ejecutarse-es - Source: BRTHLS Magazine — https://www.brthls.com --- ## Problema Muchas políticas para agentes describen intención: qué repositorio puede leer, qué servicio puede consultar o qué acción no debería realizar. El documento puede ser correcto y, aun así, no existir ningún mecanismo que demuestre que esa intención gobierna la ejecución real. La distancia aparece en los bordes. Una regla permite un host, pero no distingue qué binario abre la conexión. Una credencial llega al proceso aunque solo debía utilizarse contra un endpoint. Un cambio de política amplía capacidad sin mostrar qué permiso nuevo introduce. El equipo cree haber aprobado una tarea; en realidad ha aprobado una superficie difícil de reconstruir. OpenShell, publicado por NVIDIA como runtime para agentes autónomos, plantea una separación útil: el gateway conserva estado y revisiones; el supervisor aplica la frontera local antes de lanzar al agente; y la política declara acceso a proceso, filesystem, red y credenciales. Lo importante no es solo aislar. Es hacer que la autorización deje evidencia verificable. ## Tesis La política de un agente debe ser un artefacto ejecutable que pueda validarse antes de conceder capacidad y explicarse después de cada decisión. Un control maduro responde a tres preguntas: qué quería autorizar el operador, qué regla efectiva se aplicó y qué observó el sistema cuando permitió o denegó la acción. Si falta una, la gobernanza depende de interpretar configuración después del incidente. OpenShell aporta una idea más exigente que la allowlist convencional: la capacidad puede ligarse al destino, al binario que la utiliza y, cuando el protocolo lo permite, al método o herramienta invocados. La política no se limita a decir «puede salir a internet». Define una relación concreta entre actor, destino y operación. ## Framework Una política demostrable necesita cinco piezas: - **Intención:** tarea y riesgo que justifican el permiso. - **Compilación:** validación de esquema y rechazo de reglas ambiguas o inválidas. - **Aplicación:** control en el punto donde proceso, archivo, red y credencial son observables. - **Decisión:** registro de la regla que permitió, denegó o dejó en auditoría la acción. - **Cambio:** comparación entre capacidad anterior y capacidad propuesta. La arquitectura oficial de OpenShell coloca el supervisor dentro del sandbox como frontera local. Aplica la política del filesystem antes de iniciar el proceso, reduce privilegios, encamina el tráfico por un proxy y limita la inyección de credenciales a rutas autorizadas. Los controles estáticos requieren recrear el entorno; los dinámicos pueden actualizarse manteniendo una última configuración válida si la nueva falla. El repositorio añade una pieza especialmente relevante: el asesor de políticas puede convertir una denegación observada en una propuesta, pero la propuesta pasa por un verificador determinista. Ese verificador busca ampliaciones como nuevo alcance con credenciales, nuevos métodos o accesos especialmente sensibles. La aprobación automática no equivale a declarar la propuesta «segura»; depende de una configuración explícita y de que no aparezcan hallazgos nuevos. ## Por qué importa ahora Un agente útil descubre dependencias durante el trabajo. Puede necesitar otra API, una ruta de escritura o una herramienta que no figuraba en el plan. Bloquear cualquier cambio hace inviable la exploración. Aprobarlo de forma informal convierte cada excepción en deuda de seguridad. La solución no es dar más permisos al inicio. Es diseñar un circuito de ampliación: denegar por defecto, observar la necesidad, proponer la regla mínima, demostrar el delta y decidir desde fuera del proceso que solicita acceso. Esto cambia el papel del log. Ya no sirve solo para investigar después. Forma parte del control: muestra qué se denegó, permite formular una política más estrecha y conserva la revisión aplicada. La evidencia reduce tanto el riesgo como la fricción, porque sustituye conversaciones abstractas por un cambio concreto de capacidad. ## Anti-ejemplo Un agente de desarrollo necesita consultar incidencias y proponer un cambio. Para evitar interrupciones, el equipo permite acceso general a la API, monta el workspace completo con escritura y expone una credencial en el entorno. La tarea termina bien, pero nadie puede demostrar que el agente solo leyó las incidencias necesarias, escribió en el repositorio esperado o utilizó la credencial contra el destino previsto. El éxito funcional oculta un control defectuoso. El fallo no fue elegir un agente demasiado autónomo. Fue expresar la política como comodidad operativa en lugar de como conjunto verificable de capacidades. ## Protocolo (3 pasos) | Paso | Decisión | Evidencia mínima | | --- | --- | --- | | Declarar | Asociar cada permiso a tarea, binario, destino y operación | Política versionada con propietario y motivo | | Probar | Ejecutar denegaciones y casos permitidos antes de producción | Registro que demuestra ambos caminos | | Ampliar | Evaluar el delta de cualquier propuesta de acceso | Hallazgos del verificador y aprobación externa | Empieza en modo de observación cuando necesites descubrir tráfico, pero no lo confundas con aplicación. Una regla que registra y deja pasar aporta visibilidad; no impide la acción. El paso a enforcement debe formar parte del criterio de aceptación. ## Relacionado - [Sandboxed Work: el nuevo perímetro de ejecución para agentes en producción](/magazine/sandboxed-work-perimetro-ejecucion-agentes-produccion-es) - [El computador del agente necesita un ciclo de vida](/magazine/computador-agente-ciclo-vida-sandbox-es) - [Output Verification Layer: el seguro invisible de los agentes en producción](/magazine/output-verification-layer-seguro-invisible-agentes-produccion-es) ## Fuentes consultadas - [NVIDIA OpenShell — How OpenShell Works](https://docs.nvidia.com/openshell/dev/about/how-it-works) - [NVIDIA OpenShell — Security Best Practices](https://docs.nvidia.com/openshell/dev/security/best-practices) - [NVIDIA OpenShell — Security Policy Architecture](https://github.com/NVIDIA/OpenShell/blob/abe42fb5/architecture/security-policy.md) ## Próximo paso Toma la política del agente con mayor capacidad y selecciona un permiso sensible. Demuestra qué solicitud permite, cuál deniega, qué identidad ejecuta la acción y cómo se revisaría una ampliación. Si la respuesta solo está escrita en un documento, la política todavía no gobierna el runtime. ## Lecturas conectadas - [El computador del agente necesita un ciclo de vida](https://www.brthls.com/magazine/computador-agente-ciclo-vida-sandbox-es) — Conexión editorial. - [Sandboxed Work: el nuevo perímetro de ejecución para agentes en producción](https://www.brthls.com/magazine/sandboxed-work-perimetro-ejecucion-agentes-produccion-es) — Conexión editorial. - [Output Verification Layer: el seguro invisible de los agentes en producción](https://www.brthls.com/magazine/output-verification-layer-seguro-invisible-agentes-produccion-es) — Conexión editorial. --- _Cite as: Berthelius, V. (2026). "OpenShell: la política del agente debe poder demostrarse antes de ejecutarse". BRTHLS Magazine. https://www.brthls.com/magazine/openshell-politica-agente-demostrarse-antes-ejecutarse-es_