Salir del entorno aislado a propósito

Aislar un agente es fácil de decidir y más difícil de sobrellevar, porque en cuanto una tarea legítima necesita algo que está fuera de la caja, hace falta una forma de dejarla salir que sea deliberada y no accidental. El modo elevado es la respuesta de OpenClaw a eso. No cambia nada para un agente que nunca estuvo aislado, y para uno que sí lo está, abre un camino estrecho y controlado hacia el host. Vale la pena leer los controles con atención, porque varios de ellos tienen que alinearse antes de que se mueva un solo comando.

Qué hace el modo elevado

• El modo elevado permite que un agente aislado salga del aislamiento normal configurado para el agente y ejecute los comandos fuera del entorno aislado, con controles de aprobación que siguen siendo configurables.
• Solo cambia el comportamiento cuando el agente está aislado, porque un agente sin aislamiento ya ejecuta sus comandos de shell en el host.
• El host efectivo es el Gateway por defecto y solo pasa a ser el nodo cuando el destino de exec configurado o de la sesión ya es un nodo, así que la elevación no es una sobrescritura entre hosts.
• Hay cuatro directivas disponibles por sesión: un nivel on que mantiene las aprobaciones, un nivel ask que es un alias de él, un nivel full que puede saltarse las aprobaciones y un nivel off que vuelve a la ejecución confinada en el entorno aislado.

Las sesiones cuyo rol de creador exige aislamiento no pueden usar el modo elevado para escapar.

Los controles que deben alinearse

La disponibilidad es una conjunción, no un interruptor. El control global tiene que estar activado, y el remitente tiene que aparecer en la lista de permitidos de su canal, que se mantiene como listas de identificadores por canal. Un control por agente solo puede restringir más, así que tanto el control global como el control por agente deben estar activados para que un agente cumpla los requisitos. La lista de permitidos por agente funciona igual, y un remitente tiene que coincidir con la lista global y con la del agente. Los plugins de canal pueden aportar una lista de permitidos de respaldo mediante un hook de adaptador del SDK, pero hoy ningún canal incluido implementa ese hook, así que en la práctica cada proveedor necesita su propia entrada explícita en la lista de permitidos. Si falla cualquier control, el modo elevado se trata como no disponible en lugar de concederse parcialmente. Las entradas en sí pueden ser identificadores simples, que coinciden con un ID de remitente, un número E.164 o un campo From, o pueden llevar un prefijo que apunta a un nombre visible, un nombre de usuario o una etiqueta, con prefijos de identidad explícitos disponibles cuando necesitas evitar ambigüedades. Hay además una dependencia más discreta, ya que el comando de chat bash está detrás de su propio indicador y además requiere que el modo elevado esté activado, así que desactivar el modo elevado también bloquea esos mensajes de shell.

Niveles y precedencia

• Un mensaje que solo contiene la directiva fija el valor predeterminado de la sesión, mientras que la misma directiva usada en línea delante de una petición se aplica solo a ese mensaje.
• La resolución empieza por la directiva en línea, luego la sobrescritura de la sesión y, por último, el valor predeterminado global definido en la configuración.
• En el nivel full, las aprobaciones solo se saltan cuando el modo de exec resuelto y la política de aprobación del host ya son totalmente permisivos, y en los niveles on y ask siempre se aplican las reglas de aprobación configuradas.

El modo elevado da por hecho que ya tienes un entorno aislado del Gateway del que merezca la pena salir, y da por hecho que ya has decidido qué puede hacer un comando una vez que llega, que es la función de las aprobaciones de exec. Ninguna de las dos cosas es algo que la elevación sustituya.

Por qué se mantienen los límites

El diseño trata la elevación como una palanca sobre un único eje y se niega a que se convierta en una sobrescritura general. Si la política de herramientas deniega la herramienta exec por completo, la elevación no puede devolverla, porque las dos responden a preguntas distintas y gana la más restrictiva. Si el rol de operador del creador autenticado de la sesión exigía un entorno aislado, la elevación no puede ejecutar ningún comando en el Gateway ni en un nodo, lo que mantiene una decisión del operador por encima de una directiva de chat. La selección de host se trata del mismo modo, así que un destino automático no se convierte en una libre elección de máquina. Mantener estos controles separados es lo que hace que la composición sea predecible, y la documentación tiene una página sobre cómo interactúan los tres en el momento de una llamada a herramienta, que vale la pena leer entera una vez (cómo se combinan los tres controles). La directiva exec relacionada es otra palanca distinta, que ajusta los valores predeterminados de exec por sesión para los remitentes autorizados sin requerir elevación en absoluto. En conjunto, las reglas hacen que activar la elevación amplíe exactamente una cosa y deje todos los demás límites donde estaban.

En Diali

En Diali, cada cliente ejecuta su propio asistente, y la configuración de ejecución de OpenClaw alojado en Diali se genera desde el panel y se reemplaza en cada versión. Si quieres ver dónde están los límites antes de ampliar alguno, empieza por nuestra página sobre la seguridad en Diali.

• El modo elevado no cambia nada a menos que el agente esté realmente aislado.
• Todos los controles deben superarse: el global, el del agente y la lista de permitidos de ese canal.
• Solo el nivel full se salta las aprobaciones, y solo cuando la política ya es permisiva.