Esta página es una traducción de la documentación en inglés. Los comandos, identificadores y ejemplos no cambian. Runtime 7.24.4 · SDK 2.6.7. Original en inglés

Modo de operaciones en la nube

Estado: Activo Alcance: estado actual Última revisión: 2026-09-04 Responsable: runtime de ax-code

El modo de operaciones en la nube es una postura ya preparada para administrar infraestructura — proveedores de nube (AWS, GCP, Cloudflare, OVHcloud, DigitalOcean, RunPod) y dispositivos de red (VyOS, Juniper Junos) — donde un error afecta a sistemas en vivo y la reversión de Git no puede restaurar el estado. Se distribuye como el agente integrado cloudops: un prompt de sistema más una postura de permisos que activas con una sola elección, en lugar de escribir reglas a mano.

Qué te da el modo

Agente que empieza en solo lectura. El agente cloudops inicia cada tarea con inventario y simulaciones, y su prompt prohíbe mutar antes de que existan un plan, un diff y recetas de reversión.
Shell que pregunta antes de ejecutar. bash está definido como ask, así que cada comando de shell se confirma. Los verbos de mutación de nube y de red (familia de borrado aws/gcloud/az/doctl, kubectl delete/apply --prune, terraform apply sin un archivo de plan, commit remoto por ssh sin commit-confirm, mutaciones curl contra API del plano de control) se clasifican como bash_destructive y llevan una compuerta interactiva aparte que no se puede eludir.
Herramientas de operaciones de primer nivel. ops_plan, ops_diff, ops_verify y ops_journal están preautorizadas; ops_approve y ops_apply siguen en sus caminos interactivos (abajo).

El flujo: planificar → diff → aprobar → aplicar → verificar → diario

ops_plan: abre un OperationPlan: destino (proveedor, cuenta, región o dispositivo), intención, comando exacto de aplicación y contexto del comando, y pasos con efecto, reversibilidad (reversible | hard | irreversible) y radio de impacto (low | med | high). Produce un hash canónico del plan.
ops_diff: produce y revisa el artefacto comprobable por máquina (terraform plan -out, show | compare, salida de simulación de la CLI) y lo adjunta. Sin diff, no hay aprobación.
ops_approve: la persona aprueba el plan fijado por hash. Esta compuerta es solo interactiva: ninguna regla comodín ni el modo autónomo pueden preaprobarla, y no se ofrece una concesión duradera de «permitir siempre».
ops_apply: ejecuta la mutación del plan aprobado con el token de aprobación. Es el único camino de mutación autorizado; el token se canjea antes de que se ejecute nada.
ops_verify: ejecuta las afirmaciones declarativas de solo lectura del plan y registra la evidencia de éxito o fallo.
ops_journal: consulta el diario de operaciones de solo anexión y acotado al proyecto, por proyecto, plan o estado.

Activar el modo

En la TUI, elige Cloud Ops en el selector de agentes (o menciona con @ cloudops para una tarea acotada). Para hacerlo predeterminado de un proyecto, añádelo a ax-code.json:

{
  "default_agent": "cloudops",
  "isolation": {
    "mode": "workspace-write",
    "network": true
  }
}

workspace-write confina los cambios de archivo al espacio de trabajo; network: true mantiene accesibles webfetch, websearch y las CLI de proveedor (la red, si no, está desactivada en los modos con sandbox: consulta Modo sandbox). Ambos son ajustes de aislamiento de sesión, independientes del agente, así que se configuran aquí y no dentro del ajuste predefinido del agente.

Puedes endurecer o ampliar la postura por proyecto bajo agent.cloudops.permission, por ejemplo denegar herramientas concretas. La configuración confirmada en el repositorio solo puede añadir reglas de denegación; relajar un ask a allow debe venir de tu configuración de usuario de confianza o gestionada, nunca del repositorio. Para quitar el agente por completo, define "agent": { "cloudops": { "disable": true } }.

Un ejemplo trabajado

Aplicar un cambio de cortafuegos a un enrutador VyOS:

Pides: «permite tcp/8443 desde 10.0.0.0/8 en el cortafuegos de borde».
El agente carga la skill vyos-firewall, captura la configuración actual por SSH (show configuration commands guardado en un archivo con fecha) y abre un plan con ops_plan: un paso, efecto add firewall rule, reversibilidad reversible (borrar la regla restaura el estado), radio de impacto med.
Prepara el cambio en modo de configuración y adjunta el diff del dispositivo con ops_diff.
ops_approve te muestra el hash del plan y el cambio preparado exacto; apruebas, y se emite un token de 10 minutos.
ops_apply canjea el token y ejecuta la secuencia commit-confirm; el temporizador de reversión automática sigue armado hasta la verificación.
ops_verify comprueba la alcanzabilidad y que la regla coincida con el tráfico previsto; tanto la aprobación como el resultado quedan en el diario, así que una consulta posterior ops_journal reconstruye todo el cambio.

Si la aplicación hubiera fallado en el paso 5, el token ya no existiría: el paso 4 tendría que ejecutarse de nuevo antes de cualquier reintento.

Semántica del token de aprobación

De un solo uso: se canjea de forma atómica al inicio de ops_apply; un token consumido, desconocido o caducado falla sin que se ejecute nada.
Acotado por TTL: 10 minutos de forma predeterminada, 60 como máximo. La caducidad se comprueba de forma perezosa al consumir; no hay un barrido en segundo plano.
Ligado al plan: el token se emite contra el hash sha256 canónico del plan, que incluye el comando exacto de aplicación, el comando opcional de instantánea y el directorio de trabajo. La deriva de argumentos y los tokens presentados para otro plan se rechazan antes del consumo, lo que impide la reproducción, la confusión entre planes y la sustitución de comandos.
Revelado una vez: el token en bruto aparece exactamente una vez en el resultado ops_approve y nunca se persiste (solo se guarda su sha256).
Sin devolución: una aplicación fallida o que agota el tiempo no devuelve el token. Reintentar exige una nueva aprobación mediante ops_approve.

Modelo de seguridad

bash_destructive sigue siendo la compuerta de las mutaciones ad hoc. El flujo de operaciones cubre el cambio planificado; los comandos destructivos sueltos siguen llegando al clasificador destructivo y a su compuerta interactiva, y ninguna regla de permisos puede aprobarlos de forma automática.
ops_approve es solo interactivo, como isolation_escalation y bash_destructive: siempre pregunta, incluso bajo conjuntos de reglas de permiso comodín y en el modo autónomo sin interfaz.
El diario es de solo anexión desde el punto de vista del agente y está acotado al proyecto; sobrevive a las sesiones y no se elimina en cascada al borrar una sesión.
Los paquetes de skills llevan runbooks del proveedor. cloud-ops-aws, cloud-ops-gcp, cloud-ops-cloudflare, cloud-ops-digitalocean, cloud-ops-runpod, vyos-firewall y junos-firewall contienen las listas de comprobación que empiezan en solo lectura, los pasos de planificar antes de mutar y los patrones de reversión; el agente carga el paquete correspondiente antes de operar una superficie. OVHcloud y otros proveedores se cubren mediante servidores MCP configurados y su documentación, no con cadenas de CLI improvisadas.
Las credenciales nunca llegan al registro. Las asignaciones de credenciales en línea de las entradas bash persistidas se redactan antes de llegar al registro de eventos.

Modo estricto

De forma predeterminada, un comando bash clasificado como destructivo (la familia bash_destructive: verbos de mutación de nube y de red, rm -rf, git push --force y el resto de la lista del clasificador) recibe una pregunta interactiva que no se puede eludir: el usuario puede aprobar el comando suelto y este se ejecuta. El modo estricto quita esa opción.

Con el modo estricto activado, un comando bash clasificado como destructivo se deniega de plano, antes de cualquier pregunta. El mensaje de denegación enumera los comandos clasificados con sus motivos y dirige al modelo al flujo autorizado: ops_plan → ops_diff → ops_approve (emite un token de aprobación de un solo uso) → ops_apply. Las mutaciones destructivas ad hoc del shell ya no son posibles; cada mutación debe planificarse, compararse, aprobarse y aplicarse por el camino respaldado por el diario.

Actívalo en una configuración de confianza (ax-code.json en tu directorio de configuración de usuario, en la configuración gestionada o en una configuración de proyecto en la que el usuario haya confiado de forma explícita):

{
  "ops": {
    "strict": true
  }
}

Notas:

Interacción con la pregunta: el modo estricto sustituye la pregunta bash_destructive por una denegación dura. Con el indicador desactivado (el valor predeterminado), el comportamiento es exactamente el descrito arriba: la compuerta interactiva permanece.
Alcance: el indicador es configuración global, no por agente: se aplica a cada llamada bash de la sesión, incluidos los subagentes. El agente cloudops no puede activarlo por sí mismo; los agentes llevan permisos y prompts, no configuración.
Alcance de confianza: la configuración de proyecto no confiable y confirmada en el repositorio no puede activar el modo estricto; opta por máquina (AX_CODE_TRUST_PROJECT_CONFIG=1) o defínelo en la configuración de usuario o gestionada de confianza.
ops_apply no se ve afectado: el camino de mutación autorizado tiene su propia compuerta de token ligado al plan dentro de la herramienta y nunca consulta este indicador.

Fuente de verdad

packages/ax-code/src/agent/agent.ts: la definición del agente cloudops y la fusión de permisos
packages/ax-code/src/agent/prompt/cloudops.txt: el prompt de sistema del agente
packages/ax-code/src/tool/ops_*.ts: las seis herramientas de operaciones y sus descripciones
packages/ax-code/src/permission/index.ts: INTERACTIVE_ONLY (ops_approve, bash_destructive, isolation_escalation)
Modo sandbox: modos de aislamiento, controles de red y precedencia