Questa pagina è tradotta dalla documentazione inglese. Comandi, identificatori ed esempi restano invariati. Runtime 7.24.4 · SDK 2.6.7. Testo inglese

Modalità operazioni cloud

Stato: Attivo Ambito: stato attuale Ultima revisione: 2026-09-04 Responsabile: runtime di ax-code

La modalità operazioni cloud è una postura già pronta per amministrare l’infrastruttura — provider cloud (AWS, GCP, Cloudflare, OVHcloud, DigitalOcean, RunPod) e dispositivi di rete (VyOS, Juniper Junos) — dove un errore tocca sistemi vivi e il rollback git non può ripristinare lo stato. È distribuita come agente integrato cloudops: un prompt di sistema più una postura di autorizzazioni che attivi con una sola selezione, invece di scrivere le regole a mano.

Che cosa ti dà la modalità

Agente prima in sola lettura. L’agente cloudops inizia ogni compito con inventario e prove a secco, e il suo prompt vieta la mutazione prima che esistano un piano, un diff e ricette di rollback.
Shell con domanda prima dell’esecuzione. bash è impostato su ask, quindi ogni comando di shell viene confermato. I verbi mutanti di cloud e rete (famiglia delete di aws/gcloud/az/doctl, kubectl delete/apply --prune, terraform apply senza un file di piano, commit remoto ssh senza commit-confirm, mutazioni curl contro le API del control plane) sono classificati bash_destructive e portano una soglia interattiva separata, non aggirabile.
Strumenti di operazioni di prima classe. ops_plan, ops_diff, ops_verify e ops_journal sono pre-consentiti; ops_approve e ops_apply restano sui loro percorsi interattivi (sotto).

Il flusso: piano → diff → approvazione → applicazione → verifica → journal

ops_plan — apri un OperationPlan: bersaglio (provider, account, regione o dispositivo), intento, comando di apply esatto e contesto del comando, e passi con effetto, reversibilità (reversible | hard | irreversible) e raggio di impatto (low | med | high). Produce un hash canonico del piano.
ops_diff — produci e revisiona l’artefatto verificabile dalla macchina (terraform plan -out, show | compare, output di dry-run della CLI) e allegalo. Senza diff, niente approvazione.
ops_approve — la persona approva il piano fissato dall’hash. Questa soglia è solo interattiva: nessuna regola jolly e nessuna modalità autonoma possono pre-approvarla, e non viene offerta una concessione durevole «consenti sempre».
ops_apply — esegui la mutazione del piano approvato con il token di approvazione. È l’unico percorso di mutazione sanzionato; il token viene riscattato prima che qualcosa venga eseguito.
ops_verify — esegui le asserzioni dichiarative di sola lettura del piano e registra l’evidenza di successo o fallimento.
ops_journal — interroga il journal delle operazioni, in sola appendice e circoscritto al progetto, per progetto, piano o stato.

Attivare la modalità

Nella TUI, scegli Cloud Ops dal selettore degli agenti (oppure menziona con @ cloudops per un compito circoscritto). Per renderla predefinita di un progetto, aggiungi a ax-code.json:

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

workspace-write confina le modifiche dei file al workspace; network: true tiene raggiungibili webfetch, websearch e le CLI dei provider (la rete è altrimenti spenta nelle modalità con sandbox — vedi Modalità sandbox). Entrambe sono impostazioni di isolamento della sessione, indipendenti dall’agente, quindi si configurano qui e non dentro il preset dell’agente.

Puoi stringere o estendere la postura per progetto sotto agent.cloudops.permission, per esempio negare strumenti specifici. La configurazione committata nel repository può solo aggiungere regole di negazione; allentare un ask in allow deve venire dalla configurazione utente attendibile o gestita, mai dal repository. Per rimuovere del tutto l’agente, imposta "agent": { "cloudops": { "disable": true } }.

Un esempio concreto

Applicare una modifica del firewall a un router VyOS:

Chiedi: «consenti tcp/8443 da 10.0.0.0/8 sul firewall di bordo».
L’agente carica la skill vyos-firewall, cattura la configurazione corrente via SSH (show configuration commands salvato in un file datato) e apre un piano con ops_plan: un passo, effetto add firewall rule, reversibilità reversible (la cancellazione della regola ripristina lo stato), raggio di impatto med.
Prepara la modifica in modalità di configurazione e allega il diff del dispositivo con ops_diff.
ops_approve ti mostra l’hash del piano e la modifica esatta preparata; approvi, e viene emesso un token di 10 minuti.
ops_apply riscatta il token ed esegue la sequenza commit-confirm; il timer di rollback automatico resta armato fino alla verifica.
ops_verify controlla la raggiungibilità e che la regola corrisponda al traffico previsto; sia l’approvazione sia il risultato finiscono nel journal, così una query ops_journal successiva ricostruisce l’intera modifica.

Se l’applicazione fosse fallita al passo 5, il token sarebbe esaurito: il passo 4 andrebbe rieseguito prima di qualsiasi nuovo tentativo.

Semantica del token di approvazione

Monouso — riscattato in modo atomico all’inizio di ops_apply; un token consumato, sconosciuto o scaduto fallisce senza eseguire nulla.
Vincolato al TTL — predefinito 10 minuti, massimo 60. La scadenza si controlla in modo pigro al momento del consumo; non c’è uno spazzino in background.
Vincolato al piano — il token è emesso contro l’hash sha256 canonico del piano, che include il comando di apply esatto, il comando di istantanea facoltativo e la directory di lavoro. La deriva degli argomenti e i token presentati per un piano diverso vengono rifiutati prima del consumo, il che impedisce il replay, la confusione tra piani e la sostituzione dei comandi.
Rivelato una volta — il token grezzo compare esattamente una volta nel risultato di ops_approve e non viene mai persistito (si memorizza solo il suo sha256).
Nessun rimborso — un’applicazione fallita o scaduta non restituisce il token. Un nuovo tentativo richiede una nuova approvazione tramite ops_approve.

Modello di sicurezza

bash_destructive resta la soglia per le mutazioni estemporanee. Il flusso di operazioni copre il cambiamento pianificato; i comandi distruttivi una tantum colpiscono comunque il classificatore distruttivo e la sua soglia interattiva, e nessuna regola di autorizzazione può approvarli in automatico.
ops_approve è solo interattivo, come isolation_escalation e bash_destructive: chiede sempre, anche sotto insiemi di regole che consentono con jolly e in modalità autonoma senza interfaccia.
Il journal è in sola appendice dal punto di vista dell’agente e circoscritto al progetto; sopravvive alle sessioni e non viene eliminato a cascata quando si cancella una sessione.
I pacchetti di skill portano i runbook dei provider. cloud-ops-aws, cloud-ops-gcp, cloud-ops-cloudflare, cloud-ops-digitalocean, cloud-ops-runpod, vyos-firewall e junos-firewall contengono le checklist prima in sola lettura, i passi di piano prima della mutazione e i motivi di rollback; l’agente carica il pacchetto corrispondente prima di operare su una superficie. OVHcloud e gli altri provider sono coperti tramite server MCP configurati e la loro documentazione, non tramite catene di CLI improvvisate.
Le credenziali non raggiungono mai il registro. Le assegnazioni di credenziali in linea negli input bash persistiti vengono redatte prima di arrivare al log degli eventi.

Modalità rigorosa

Per impostazione predefinita, un comando bash classificato come distruttivo (la famiglia bash_destructive: verbi mutanti di cloud e rete, rm -rf, git push --force e il resto dell’elenco del classificatore) riceve una domanda interattiva non aggirabile: l’utente può approvare il comando una tantum e questo viene eseguito. La modalità rigorosa rimuove quell’opzione.

Con la modalità rigorosa attiva, un comando bash classificato come distruttivo viene negato subito, prima di qualsiasi domanda. Il messaggio di negazione elenca i comandi classificati con le loro ragioni e indirizza il modello al flusso sanzionato: ops_plan → ops_diff → ops_approve (emette un token di approvazione monouso) → ops_apply. Le mutazioni di shell distruttive estemporanee non sono più possibili; ogni mutazione deve essere pianificata, confrontata, approvata e applicata attraverso il percorso sostenuto dal journal.

Attivala nella configurazione attendibile (ax-code.json nella directory di configurazione utente, nella configurazione gestita, o in una configurazione di progetto che l’utente ha esplicitamente ritenuto attendibile):

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

Note:

Interazione con la domanda: la modalità rigorosa sostituisce la domanda bash_destructive con un rifiuto netto. Con il flag spento (il predefinito), il comportamento è esattamente quello descritto sopra: la soglia interattiva resta.
Ambito: il flag è configurazione globale, non per agente: si applica a ogni chiamata bash della sessione, inclusi i subagenti. L’agente cloudops non può attivarla da solo; gli agenti portano autorizzazioni e prompt, non configurazione.
Ambito di fiducia: la configurazione di progetto non attendibile e committata nel repository non può attivare la modalità rigorosa; aderisci per macchina (AX_CODE_TRUST_PROJECT_CONFIG=1) oppure impostala nella configurazione utente o gestita attendibile.
ops_apply non ne è toccato: il percorso di mutazione sanzionato ha la propria soglia di token vincolata al piano dentro lo strumento e non consulta mai questo flag.

Fonte di verità

packages/ax-code/src/agent/agent.ts — la definizione dell’agente cloudops e l’unione delle autorizzazioni
packages/ax-code/src/agent/prompt/cloudops.txt — il prompt di sistema dell’agente
packages/ax-code/src/tool/ops_*.ts — i sei strumenti di operazioni e le loro descrizioni
packages/ax-code/src/permission/index.ts — INTERACTIVE_ONLY (ops_approve, bash_destructive, isolation_escalation)
Modalità sandbox — modalità di isolamento, controlli di rete e precedenza