L'incident a réveillé une équipe qui avait construit l'intégralité de son modèle d'accès AWS sur la conviction que seuls des humains prudents détenaient des clés de production. Avec l'intégration des agents d'IA dans le flux de travail de chaque développeur, cette conviction s'est avérée fausse. L'entreprise a réagi en érigeant un « courtier d'accès » (access broker) qui impose à toute opération de niveau production de passer par une étape d'approbation humaine.
Comment l'accident s'est produit
Un ingénieur a demandé à un agent de codage IA de générer un script de pipeline. L'agent a hérité du rôle IAM de production de l'ingénieur — une identité AWS capable de créer, modifier et supprimer des stacks CloudFormation. Le script s'est exécuté, a créé une stack dans l'environnement de production, puis l'a immédiatement supprimée en tant qu'étape de « nettoyage ». Comme l'opération a contourné le pipeline CI/CD standard, le moteur de politique qui contrôle normalement ces changements ne l'a jamais vue.
La plateforme de surveillance, configurée pour signaler tout rôle effectuant une action privilégiée en dehors du pipeline approuvé, a déclenché une alerte dès que la stack a été supprimée. Aucun service n'a été interrompu, mais l'alarme a mis en évidence un scénario où un nom de ressource mal saisi ou un prompt d'IA défectueux aurait pu effacer une infrastructure critique.
La détection, l'équipe l'a réalisé, n'est pas la prévention. Si l'IA avait supprimé la mauvaise stack, un désastre aurait suivi.
Pourquoi l'ancien modèle d'identifiants a échoué
L'approche précédente de l'organisation reposait sur des sessions de courte durée protégées par l'authentification multi-facteurs (MFA). En théorie, un développeur demandait une session, effectuait une tâche, et les identifiants expiraient automatiquement. En pratique, une fois qu'une session était lancée sur un ordinateur portable, elle persistait pendant toute la durée de fonctionnement de la machine. Chaque processus — suites de tests, scripts en arrière-plan et désormais agents d'IA — réutilisait ces identifiants sans aucun contrôle supplémentaire.
Ce problème d'« identifiants ambiants » (ambient credentials) a ancré le rôle IAM de production dans la station de travail du développeur. L'agent d'IA, s'exécutant comme un sous-processus dans le même shell, héritait des mêmes permissions et pouvait agir sur les ressources de production tout comme un humain.
Le courtier d'accès : un nouveau gardien
Pour briser la chaîne des identifiants ambiants, l'équipe a repensé la manière dont les rôles de production sont assumés. Au lieu de permettre à n'importe quelle identité de développeur d'assumer directement un rôle privilégié, ils ont introduit une entité unique et étroitement contrôlée : un courtier d'accès interne.
Flux de demande
- Portail Web – L'ingénieur ouvre un portail en libre-service, sélectionne le niveau d'accès requis (lecture seule, développeur ou administrateur) et fournit une justification.
- Approbation Slack – La demande est publiée dans un canal Slack dédié où un approbateur désigné doit explicitement accorder la permission.
L'étape Slack agit comme un second facteur sur une plateforme différente du terminal où l'agent d'IA s'exécute. Comme l'approbation doit avoir lieu dans une interface utilisateur distincte, un script autonome ne peut pas achever le flux de travail de lui-même.
Accès hiérarchisés
- Lecture seule (Read-only) – Les utilisateurs peuvent consulter les ressources et les journaux, mais ne peuvent rien modifier.
- Développeur (Developer) – Destiné aux tâches de support et aux ajustements d'infrastructure ; ce niveau bloque les actions destructrices telles que la suppression de stack ou l'accès direct aux données clients.
- Administrateur (Administrator) – Privilèges complets, réservés aux interventions d'urgence et accordés uniquement après un examen de niveau supérieur.
En canalisant tous les accès de production via le courtier, l'équipe a concentré le risque dans un service unique et fortement défendu au lieu de disperser des identifiants privilégiés sur chaque ordinateur portable.
Ce que le courtier empêche réellement
L'objectif principal du courtier est d'empêcher l'exploitation silencieuse des identifiants ambiants par les agents d'IA. Même si un humain approuve une demande, cette approbation est une décision consciente ; l'IA ne peut pas fabriquer cette étape. Par conséquent :
- Suppressions involontaires – L'IA ne peut plus émettre une commande de suppression à moins qu'un humain n'ait explicitement autorisé la session.
- Dispersion des identifiants (Credential sprawl) – Les clés de production ne résident plus sur les machines des développeurs, réduisant ainsi la surface d'attaque pour les acteurs malveillants internes et externes qui pourraient compromettre un ordinateur portable.
L'équipe souligne que le système n'élimine pas l'erreur humaine ; une approbation malavisée peut toujours causer des dommages. Il élimine toutefois le risque « silencieux » d'un code autonome agissant sur des ressources de production sans aucun point de contrôle humain.
À retenir
Lorsque les agents d'IA reçoivent les mêmes identifiants sans restriction que les ingénieurs humains, ils héritent du pouvoir de perturber la production — souvent sans que personne ne s'en aperçoive. En centralisant les accès privilégiés derrière un broker qui impose un canal d'approbation humain distinct, une équipe peut empêcher les scripts autonomes de semer le chaos en silence, même si une erreur humaine peut toujours causer des problèmes. Le véritable gain de sécurité réside dans l'élimination des identifiants ambiants, et non dans le contrôle de chaque décision individuelle.