Control Plane : l'agent écrit, le pipeline exécute
Un agent IA ne doit jamais être à la fois auteur et exécuteur. AIDO sépare strictement les rôles : qui écrit, qui approuve, qui orchestre, qui exécute, qui vérifie. Plus jamais de SSH direct en prod.
Le mécanisme — la séparation des rôles
GitLab CI/CD
Trace, gate (MR review), audit trail, artifacts. Ne prend pas de décision technique.
Runner Docker
Déploie via ansible/playwright dans un sandbox isolé. Pas de discrétion : exécute le pipeline.
Règle d'or : l'agent fait un git push, c'est tout. L'exécution passe par le pipeline. S'il veut déployer, il trigger l'API GitLab — jamais de connexion directe.
Le modèle complet sépare cinq rôles : Author (écrit), Approver (le GO, humain ou mandaté), Orchestrator (trace et gate), Executor (déploie), Verifier (le verdict indépendant — c'est la colonne Runtime Intelligence). Chaque mandat est scopé : plan hashé, cibles, TTL, capabilities minimales, révocation. Le modèle ne transforme jamais une intention en privilège et ne s'accorde pas son propre GO.
Sandbox isolation
Le Runner Docker n'est pas qu'un exécuteur, c'est un sandbox de sécurité : chaque job = un conteneur éphémère, secrets injectés au runtime (masked + protected), pas d'accès réseau hors cibles. Si le code généré par l'IA plante ou dérape, le conteneur est détruit sans impact sur l'hôte ni les serveurs.
Tracabilité structurelle vs convention
| Convention (fragile) | Structure (garanti) |
|---|---|
| « Mets à jour pipeline.json » | Le job log EXISTE, point |
| « Stocke le screenshot » | artifacts: paths: [*.png] |
| « Suis les 6 étapes » | 6 stages dans .gitlab-ci.yml |
| « Respecte la procédure » | Le pipeline EST la procédure |
Votre IA déploie-t-elle en direct ?
Auditons votre control plane : où l'agent exécute sans gate, comment poser la séparation des rôles.
Réserver mon audit AIDO de 30 min