Un agente puede leer archivos, editarlos y ejecutar comandos con rapidez. Esa capacidad exige controles que delimiten dónde puede trabajar, qué puede ejecutar y quién autoriza una acción sensible.
Bionic combina proyectos, directorios de trabajo, entornos administrados, permisos y modos de aprobación del shell. Ninguna capa es perfecta por separado: la seguridad surge de utilizarlas juntas y revisar el resultado.
El modelo también es una capa, pero no debe considerarse una frontera de seguridad. Puede interpretar mal una solicitud, recibir datos hostiles o construir un comando correcto para un objetivo equivocado.
| Escenario | Acceso | Precaución |
|---|---|---|
| Documentos | Bionic utiliza un sandbox administrado para iterar sobre archivos del proyecto. | Los archivos externos siguen en su ubicación original y una edición puede modificar el original. |
| Código | Con Allow coding, trabaja sobre el directorio local seleccionado y puede usar Git y shell. | Elige la raíz más estrecha que contenga el repositorio necesario. |
No abras como directorio de trabajo todo tu perfil de usuario o una carpeta que contenga varios proyectos y secretos. Una raíz precisa reduce errores de búsqueda y cambios fuera de alcance.
Un sandbox busca limitar el efecto de las operaciones a un entorno controlado. Es especialmente útil para transformar documentos, ejecutar código auxiliar o generar entregables sin ofrecer acceso general al equipo.
La documentación técnica de Auto Review subraya que el sandbox y la aprobación resuelven problemas diferentes. Algunas tareas necesitan leer configuración externa, instalar software o actuar en servicios que no pueden aislarse por completo.
Las versiones actuales de Bionic muestran en el compositor cuatro opciones para controlar comandos. Los nombres pueden aparecer traducidos.
| Modo | Comportamiento | Uso aconsejado |
|---|---|---|
| Disabled | Deshabilita la ejecución de comandos. | Lectura, planificación o sesiones que no necesitan terminal. |
| Manual Review | El usuario revisa las solicitudes de shell. | Aprendizaje, repositorios sensibles y tareas de riesgo. |
| Auto Review | Un pipeline automático permite comandos seguros y deriva casos dudosos. | Trabajo cotidiano con equilibrio entre fluidez y control. |
| Allow All | Permite ejecutar sin la revisión normal de cada comando. | Sólo entornos desechables, controlados y recuperables. |
| Tarea | Modo inicial | Motivo |
|---|---|---|
| Explicar un repositorio | Disabled o Manual Review | La mayor parte del trabajo es de lectura. |
| Corregir y probar una aplicación | Auto Review | Hay muchos comandos rutinarios con cambios revisables. |
| Migrar o borrar datos | Manual Review | Los efectos pueden ser irreversibles. |
| Experimento dentro de una máquina efímera | Auto Review; excepcionalmente Allow All | El entorno debe poder recrearse sin pérdida. |
Elige el modo antes de iniciar la tarea y vuelve a uno más restrictivo cuando termine. Bionic puede recordar preferencias; esa comodidad exige revisar el indicador en cada nueva sesión.
La primera etapa es determinista y no utiliza un LLM. Si el Shell Judge puede demostrar que la forma concreta es segura, permite la ejecución. Si no, Auto Review no supone que sea peligrosa ni segura: pasa al siguiente nivel.
Una expresión regular no basta para analizar tuberías, redirecciones, variables, sustituciones y comandos anidados. Shell Judge convierte el texto en un árbol sintáctico abstracto o AST.
El analizador identifica ambos comandos y sigue el posible valor de base. La revisión debe considerar la operación completa, no sólo la primera palabra visible.
Tras el parseo, Bionic produce una representación común de lo que el comando podría hacer en el peor caso: comandos invocados, rutas leídas, destinos escritos, cambios de directorio y construcciones desconocidas.
El enfoque es una allowlist: si aparece una estructura que el analizador no comprende por completo, no se aprueba mecánicamente. También trata con cautela variables de entorno, expansiones y valores dinámicos.
La seguridad depende del comando, sus argumentos y el contexto. Por ejemplo, mostrar una versión no equivale a ejecutar un script, y leer un archivo del proyecto no equivale a leer un archivo sensible del sistema.
No utilices esta lista como garantía universal. Alias, configuraciones, hooks y binarios reemplazados pueden modificar el comportamiento real.
Shell Judge analiza sh, bash, zsh y PowerShell. En macOS Bionic prefiere zsh. En Windows prefiere Git Bash si está instalado; en caso contrario recurre a PowerShell y luego a cmd.
Un alias puede significar cosas distintas. Por ejemplo, cat en PowerShell es un alias de Get-Content, no necesariamente el ejecutable POSIX. Revisa el shell indicado y evita asumir que un comando se comporta igual en todas las plataformas.
Cuando Shell Judge no puede aprobar un comando, Auto Review crea un subagente revisor que considera el contexto disponible. Lo clasifica en tres ejes independientes:
| Eje | Pregunta | Valores publicados |
|---|---|---|
| Risk | ¿Qué tan peligroso es en el peor caso? | low, high, too_destructive. |
| Authorization | ¿El usuario autorizó esta acción? | explicitly_no, neutral, explicitly_yes. |
| Correctness | ¿Hay errores evidentes en la orden? | Señala problemas al agente principal. |
Los comandos de bajo riesgo pueden continuar si el usuario no los prohibió. Los de alto riesgo necesitan evidencia de autorización. Una acción clasificada como demasiado destructiva no se ejecuta incluso con autorización explícita.
Auto Review no intenta resolver toda incertidumbre. Si la revisión no puede permitir el comando, Bionic solicita decisión humana. Esto evita que el agente conozca el rechazo e intente reformular la orden para eludirlo.
Una solicitud de aprobación no es una molestia que deba aceptarse automáticamente. Es una señal para detenerse y verificar.
«Haz lo necesario» es una autorización ambigua. Define acción, objeto y límites:
La autorización para una tarea no se extiende automáticamente a otra sesión, repositorio o destino. Tampoco convierte en correcto un argumento mal escrito.
git reset --hard, limpieza de archivos y reescritura de historia.Las versiones actuales permiten conservar preferencias e instrucciones personalizadas para Auto Review. Úsalas para expresar políticas estables y concretas, no para desactivar la cautela.
Revisa estas preferencias cuando cambies de cliente, repositorio o nivel de sensibilidad. Una regla apropiada para un proyecto de demostración puede ser peligrosa en producción.
Archivos, páginas web, salidas de herramientas e incidencias pueden contener instrucciones hostiles. Trátalos como datos no confiables. El diseño publicado del Shell Reviewer excluye resultados de herramientas de su transcripción para reducir ese riesgo, pero la protección total no es posible.
Objetivo: observar el comportamiento del shell sin modificar archivos.
No necesitas ejecutar una orden peligrosa. Pide una propuesta hipotética y analiza su sustitución:
Un buen flujo separa descubrimiento, verificación y mutación. Si no puede mostrar de antemano los objetivos exactos, la operación no está lista para aprobarse.
La aprobación previa no cierra la tarea. Comprueba lo ocurrido:
| Problema | Respuesta recomendada |
|---|---|
| El agente no puede usar shell. | Comprueba Allow coding, directorio y que el modo no esté en Disabled. |
| Pide demasiadas aprobaciones. | Usa Auto Review, simplifica comandos o divide la tarea; no elijas Allow All por cansancio. |
| Un comando seguro no se autoaprueba. | Puede contener una forma desconocida o dinámica; revísalo manualmente. |
| Auto Review rechaza una acción necesaria. | Lee el riesgo, autoriza explícitamente el alcance o propón una variante reversible. |
| Usa otro shell. | Comprueba el shell seleccionado y adapta sintaxis, rutas y comillas. |
| Modificó un archivo externo. | Recuerda que los externos se editan en origen; restaura desde historial o copia. |
| El comando terminó pero la tarea falló. | Revisa salida, diff y pruebas: ejecución permitida no implica resultado correcto. |
En el último tema estudiaremos privacidad, Zero Data Retention, cuentas, créditos y buenas prácticas para operar Bionic de forma responsable.
Fuentes oficiales consultadas: arquitectura de Auto Review, modos de aprobación y preferencias, trabajo seguro con código, sandbox y archivos de documentos, permisos iniciales del proyecto y cambios recientes de Bionic.