Agents offensifs : tester le confinement avant de connecter l’IA au métier
La sécurité d’un agent se mesure aussi au temps nécessaire pour lui retirer ses accès. Les observations récentes de Google fournissent un point de départ pour une recette de confinement des workflows IA, proposée ici par Underside.
1. Des intrusions observées, une portée à respecter
Le 30 octobre, Google Threat Intelligence Group et Mandiant rapportent des intrusions utilisant notamment ARTEX. Le rapport décrit l’abus d’identifiants compromis et l’automatisation de plusieurs étapes. Il qualifie les usages actuels d’encore précoces et souvent bruyants. Ces observations ne démontrent pas que toutes les attaques sont devenues autonomes.
2. Ce que cela change pour une entreprise belge ou française
Notre recommandation aux DSI : compléter la revue des droits par un exercice chronométré de retrait des accès. Une PME peut retenir un seul agent et désigner la personne autorisée à l’arrêter. Une ETI ou un grand groupe devrait coordonner exploitation, identité, sécurité et responsable métier. Une administration peut ajouter une vérification de la continuité du service. L’objectif proposé est de mesurer le délai entre une alerte, la décision de confinement et le refus effectif d’une nouvelle action.
3. Analyse Underside : séparer le modèle du pouvoir d’agir
Nous proposons de traiter chaque connecteur comme une frontière de sécurité. Un modèle local ou un cloud européen ne dispense pas de contrôler les outils auxquels l’agent accède. Pour un RAG, distinguer accès au corpus, récupération des documents et exposition de la réponse. Pour un agent Odoo Entreprise, séparer lecture, proposition et écriture : une validation doit porter sur l’action exacte, son périmètre et son destinataire. Ces scénarios sont nos recommandations ; le rapport ne signale pas une compromission d’Odoo ni une intégration particulière.
4. Un exercice de confinement reproductible
Dans un environnement de test autorisé et sur données fictives, déclencher une action bénigne avec une identité dédiée. Révoquer ensuite son accès, arrêter le workflow et tenter de reprendre la tâche depuis une file déjà alimentée. Vérifier séparément les sessions ouvertes, les jetons encore valides et les opérations programmées. Consigner les actions effectivement refusées et celles qui restent possibles. Un simple arrêt de l’interface ne doit pas servir de preuve de révocation. Le métier définit les effets acceptables et les critères bloquants avant l’exercice.
5. Conserver les preuves et organiser la reprise
Nous recommandons un identifiant commun reliant requête utilisateur, décision de l’agent, appel d’outil, autorisation et résultat métier. Limiter les données sensibles dans les journaux et documenter qui peut les consulter. Prévoir un responsable pour préserver les preuves avant de relancer le service. La reprise devrait utiliser une identité renouvelée et une configuration vérifiée, puis rejouer les actions en attente sous contrôle humain pour éviter les doublons, par exemple sur un devis ou une facture.
6. Un critère de passage en production
Pour un déploiement privé, cloud ou hybride, demander une démonstration de confinement couvrant aussi les dépendances externes et les comptes techniques. Fixer un délai cible adapté au risque plutôt que reprendre un chiffre universel. Si une écriture interdite reste possible après révocation, corriger la chaîne d’accès avant le pilote. Cette recette complète l’analyse de sécurité ; elle ne constitue pas une certification de souveraineté ou de conformité.
Priorité opérationnelle : choisir un workflow, nommer son responsable et prouver qu’une révocation bloque aussi les tâches en attente, avec des traces exploitables.
Cadrer les contrôles d’un projet IA