Cette page est traduite de la documentation anglaise. Les commandes, identifiants et exemples sont inchangés. Runtime 7.24.4 · SDK 2.6.7. Source anglaise

Mode opérations cloud

Statut : actif Portée : état actuel Dernière revue : 2026-09-04 Responsable : runtime AX Code

Le mode opérations cloud est une posture prête à l’emploi pour administrer une infrastructure — fournisseurs cloud (AWS, GCP, Cloudflare, OVHcloud, DigitalOcean, RunPod) et équipements réseau (VyOS, Juniper Junos) — là où une erreur touche des systèmes en production et où un retour arrière git ne peut pas restaurer l’état. Il est livré comme l’agent intégré cloudops : une invite système plus une posture de permissions, que vous activez par une seule sélection au lieu de rédiger les règles à la main.

Ce que le mode vous apporte

Agent d’abord en lecture seule. L’agent cloudops commence chaque tâche par un inventaire et des exécutions à blanc, et son invite interdit toute mutation avant qu’un plan, un diff et des recettes de retour arrière n’existent.
Shell avec demande avant exécution. bash vaut ask, donc chaque commande shell est confirmée. Les verbes de mutation cloud ou réseau (famille de suppression aws/gcloud/az/doctl, kubectl delete/apply --prune, terraform apply sans fichier de plan, commit distant ssh sans commit-confirm, mutations curl contre des API de plan de contrôle) sont classés bash_destructive et portent une barrière interactive distincte, non contournable.
Outils d’exploitation de premier plan. ops_plan, ops_diff, ops_verify et ops_journal sont préautorisés ; ops_approve et ops_apply restent sur leurs chemins interactifs (plus bas).

Le flux : plan → diff → approuver → appliquer → vérifier → journal

ops_plan — ouvrir un OperationPlan : cible (fournisseur, compte, région ou équipement), intention, commande d’application exacte et contexte de commande, et étapes avec effet, réversibilité (reversible | hard | irreversible) et rayon d’impact (low | med | high). Produit un hachage canonique du plan.
ops_diff — produire et revoir l’artefact vérifiable par machine (terraform plan -out, show | compare, sortie d’exécution à blanc de la CLI) et le joindre. Pas de diff, pas d’approbation.
ops_approve — l’humain approuve le plan épinglé par son hachage. Cette barrière est seulement interactive : aucune règle joker ni aucun mode autonome ne peut la préapprouver, et aucun octroi durable « toujours autoriser » n’est proposé.
ops_apply — exécuter la mutation du plan approuvé avec le jeton d’approbation. C’est le seul chemin de mutation autorisé ; le jeton est consommé avant toute exécution.
ops_verify — exécuter les assertions déclaratives en lecture seule du plan et enregistrer la preuve de réussite ou d’échec.
ops_journal — interroger le journal d’opérations en ajout seulement, limité au projet, par projet, plan ou statut.

Activer le mode

Dans le TUI, choisissez Cloud Ops dans le sélecteur d’agents (ou mentionnez cloudops avec @ pour une tâche délimitée). Pour en faire le défaut d’un projet, ajoutez ceci à ax-code.json :

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

workspace-write confine les changements de fichiers à l’espace de travail ; network: true laisse webfetch, websearch et les CLI de fournisseurs joignables (le réseau est sinon coupé dans les modes sous bac à sable — voir Mode bac à sable). Les deux sont des réglages d’isolation de session, indépendants de l’agent : ils se configurent ici, et non dans le préréglage de l’agent.

Vous pouvez resserrer ou étendre la posture par projet sous agent.cloudops.permission, par exemple refuser des outils précis. Une configuration validée dans le dépôt ne peut ajouter que des règles de refus ; assouplir un ask vers allow doit venir de votre configuration utilisateur de confiance ou gérée, jamais du dépôt. Pour retirer entièrement l’agent, définissez "agent": { "cloudops": { "disable": true } }.

Un exemple concret

Application d’un changement de pare-feu sur un routeur VyOS :

Vous demandez : « autoriser tcp/8443 depuis 10.0.0.0/8 sur le pare-feu de bord ».
L’agent charge le skill vyos-firewall, capture la configuration actuelle via SSH (show configuration commands enregistré dans un fichier daté) et ouvre un plan avec ops_plan : une étape, effet add firewall rule, réversibilité reversible (la suppression de la règle restaure l’état), rayon d’impact med.
Il prépare le changement en mode configuration et joint le diff de l’équipement avec ops_diff.
ops_approve vous montre le hachage du plan et le changement préparé exact ; vous approuvez, et un jeton de 10 minutes est émis.
ops_apply consomme le jeton et exécute la séquence commit-confirm ; le minuteur de retour arrière automatique reste armé jusqu’à la vérification.
ops_verify contrôle la joignabilité et le fait que la règle correspond au trafic visé ; l’approbation et le résultat sont journalisés, afin qu’une requête ops_journal ultérieure reconstruise tout le changement.

Si l’application avait échoué à l’étape 5, le jeton aurait disparu : l’étape 4 devrait être refaite avant tout nouvel essai.

Sémantique du jeton d'approbation

Usage unique — consommé de façon atomique au début de ops_apply ; un jeton déjà consommé, inconnu ou expiré échoue sans rien exécuter.
Limité par une durée de vie — 10 minutes par défaut, 60 au maximum. L’expiration est contrôlée de façon paresseuse au moment de la consommation ; il n’y a pas de balayage en arrière-plan.
Lié au plan — le jeton est émis contre le hachage sha256 canonique du plan, qui inclut la commande d’application exacte, la commande d’instantané facultative et le répertoire de travail. Une dérive d’arguments et les jetons présentés pour un autre plan sont rejetés avant consommation, ce qui empêche le rejeu, la confusion entre plans et la substitution de commande.
Révélé une seule fois — le jeton brut apparaît exactement une fois dans le résultat de ops_approve et n’est jamais persisté (seul son sha256 est stocké).
Pas de restitution — une application échouée ou expirée ne rend pas le jeton. Un nouvel essai exige une nouvelle approbation via ops_approve.

Modèle de sécurité

bash_destructive reste la barrière des mutations ponctuelles. Le flux d’exploitation couvre le changement planifié ; les commandes destructives isolées passent encore par le classifieur destructif et sa barrière interactive, et aucune règle de permission ne peut les approuver automatiquement.
ops_approve est seulement interactif, comme isolation_escalation et bash_destructive : il demande toujours, même sous des jeux de règles d’autorisation joker et en mode autonome sans interface.
Le journal est en ajout seulement du point de vue de l’agent et limité au projet ; il survit aux sessions et n’est pas supprimé en cascade lors de la suppression d’une session.
Les paquets de skills portent les procédures des fournisseurs. cloud-ops-aws, cloud-ops-gcp, cloud-ops-cloudflare, cloud-ops-digitalocean, cloud-ops-runpod, vyos-firewall et junos-firewall contiennent les listes de contrôle d’abord en lecture seule, les étapes planifier-avant-de-muter et les motifs de retour arrière ; l’agent charge le paquet correspondant avant d’opérer une surface. OVHcloud et les autres fournisseurs sont couverts par les serveurs MCP configurés et leur documentation, pas par des chaînes CLI improvisées.
Les authentifiants n’atteignent jamais l’enregistrement. Les affectations d’authentifiants en ligne dans les entrées bash persistées sont masquées avant d’atteindre le journal d’événements.

Mode strict

Par défaut, une commande bash classée destructive (la famille bash_destructive : verbes de mutation cloud ou réseau, rm -rf, git push --force et le reste de la liste du classifieur) reçoit une demande interactive non contournable — l’utilisateur peut approuver la commande ponctuelle, et elle s’exécute. Le mode strict retire cette option.

Avec le mode strict activé, une commande bash classée destructive est refusée d’emblée, avant toute demande. Le message de refus liste les commandes classées avec leurs raisons et oriente le modèle vers le flux autorisé : ops_plan → ops_diff → ops_approve (émet un jeton d’approbation à usage unique) → ops_apply. Les mutations shell destructives ponctuelles ne sont plus possibles du tout ; chaque mutation doit être planifiée, différenciée, approuvée et appliquée par le chemin appuyé sur le journal.

Activez-le dans une configuration de confiance (ax-code.json dans votre répertoire de configuration utilisateur, une configuration gérée, ou une configuration de projet à laquelle l’utilisateur a explicitement fait confiance) :

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

Remarques :

Interaction avec la demande : le mode strict remplace la demande bash_destructive par un refus ferme. Avec l’indicateur désactivé (le défaut), le comportement est exactement celui décrit plus haut : la barrière interactive demeure.
Portée : l’indicateur est une configuration globale, pas par agent — il s’applique à chaque appel bash de la session, y compris les sous-agents. L’agent cloudops ne peut pas l’activer lui-même ; les agents portent des permissions et des invites, pas la configuration.
Périmètre de confiance : une configuration de projet non fiable, validée dans le dépôt, ne peut pas activer le mode strict ; activez-le par machine (AX_CODE_TRUST_PROJECT_CONFIG=1) ou définissez-le dans une configuration utilisateur ou gérée de confiance.
ops_apply n’est pas affecté : le chemin de mutation autorisé a sa propre barrière de jeton lié au plan, à l’intérieur de l’outil, et ne consulte jamais cet indicateur.

Source de vérité

packages/ax-code/src/agent/agent.ts — définition de l’agent cloudops et fusion des permissions
packages/ax-code/src/agent/prompt/cloudops.txt — invite système de l’agent
packages/ax-code/src/tool/ops_*.ts — les six outils d’exploitation et leurs descriptions
packages/ax-code/src/permission/index.ts — INTERACTIVE_ONLY (ops_approve, bash_destructive, isolation_escalation)
Mode bac à sable — modes d’isolation, contrôles réseau et priorité