L’incident du Pentagone n’est pas un échec de l’IA, mais un échec du contrôle d’accès

Qui a réellement exposé les données: l’agent IA, ou la personne qui lui a remis les clés ? Il est tentant de lire l’incident du Pentagone comme l’histoire d’une machine incontrôlable qui s’aventure dans un réseau protégé. D’après ce qui a été rapporté jusqu’ici, c’est un humain qui l’y a fait entrer et qui lui a tenu la porte.

Ce qui a été rapporté

Selon Wired, un employé d’Accenture aurait connecté un environnement de production sécurisé à son compte Claude personnel afin qu’un agent IA écrive et déploie du code. D’autres médias, comme CDO Magazine, indiquent que cela aurait pu exposer des identifiants de connexion et des informations sur le réseau. Le récit de Wired repose sur des sources anonymes et, d’après le résumé publié sur aiweekly.co, l’agent a tourné sur le réseau du département de la Défense pendant environ deux mois avant que quiconque l’identifie.

Le média allemand Golem affirme que des données ont apparemment quitté le système. Certains sites plus modestes vont plus loin et évoquent des informations de renseignement exposées, mais nous prendrions ces détails avec prudence tant que rien de plus solide n’apparaît. Il s’agit toujours d’une allégation, et l’étendue exacte de l’exposition n’est pas établie.

L’agent a fait ce que font les agents

Prenons le détail le plus accablant: l’agent aurait travaillé avec des droits d’administration. Un agent capable d’écrire et de déployer du code a besoin d’identifiants pour cela. Il a utilisé ce qu’on lui a donné. Accuser ici l’« IA », c’est comme reprocher à un livreur d’être entré dans un immeuble après que quelqu’un lui a remis un passe-partout.

Selon nous, la défaillance intéressante est humaine, et elle est ancienne. Les informations disponibles n’expliquent pas pourquoi l’employé a agi ainsi, mais le schéma est connu: quelqu’un se saisit d’un outil en lequel il a confiance et le branche à quelque chose qu’il n’aurait jamais dû toucher. Remplacez l’agent par un compte de stockage cloud personnel ou un script sur un ordinateur portable domestique, et vous obtenez une histoire semblable. Ce qui a changé, c’est que l’outil agit désormais de lui-même, vite, et avec les autorisations qu’on lui accorde.

C’est pourquoi c’est plus dangereux que le shadow IT auquel nous sommes habitués. Un tableur oublié reste là, inerte. Un agent doté de droits de déploiement continue à travailler et, dans ce cas, il aurait continué pendant environ deux mois.

Les agents ont besoin d’identités, pas d’identifiants empruntés

La solution concrète n’est pas d’« interdire les agents ». Elle consiste à les traiter pour ce qu’ils sont: un nouveau type d’acteur sur le réseau. À notre avis, cela suppose quelques mesures peu glamour:

• Une identité propre. Un agent ne devrait jamais fonctionner avec le compte de son utilisateur humain, et encore moins avec un compte administrateur. Si quelque chose tourne mal, les journaux doivent indiquer « l’agent X a fait ceci », et non « Alice a fait ceci ».
• Un périmètre étroit. Un accès en lecture à un seul dépôt est une demande raisonnable. Un accès administrateur à un environnement de production n’est pas un point de départ.
• Révocable et de courte durée. Des identifiants qui expirent d’eux-mêmes et peuvent être désactivés en une seule opération transforment un incident de deux mois en incident de deux heures.
• De la visibilité. Le détail qui nous marque, ce sont les deux mois. D’après les informations rapportées, l’agent a tourné dans un environnement sécurisé pendant tout ce temps avant d’être identifié. Cela ressemble autant à une faille de surveillance qu’à une faille de permissions.

Notez que rien de tout cela ne concerne le modèle. Cela s’appliquerait de la même façon à n’importe quel outil autonome, quel que soit son fournisseur.

Chez les sous-traitants, les règles sont les plus minces

L’autre leçon est organisationnelle, et nous spéculons ici sur la façon dont ces failles apparaissent généralement, sans décrire ce qui s’est passé dans ce cas. Un sous-traitant se trouve entre les politiques de deux entreprises, et chacune peut supposer que l’autre règle le problème. L’employeur peut dire que les règles du client s’appliquent sur les systèmes du client, tandis que le client peut supposer que toute personne munie d’un badge a été informée. Ajoutez un sous-traitant pressé par une échéance, avec un abonnement d’IA personnel qui lui facilite la tâche, et la tentation est évidente.

Nous nous attendons, et c’est une prévision, à ce que l’usage des agents soit inscrit noir sur blanc dans les contrats de sous-traitance: quels outils sont autorisés, sur quels systèmes, avec quels comptes, et quelle journalisation. Personne ne devrait avoir à deviner qu’un compte d’IA personnel n’a pas sa place sur un système de production sécurisé. Les règles qui n’existent que comme du bon sens ne résistent pas à une échéance.

Il faut aussi noter qu’Anthropic, dont l’outil est au cœur des titres, apparaît dans les informations comme le produit choisi par l’employé, et non comme la partie qui a pris la décision d’accès. Cette distinction compte, même s’il est légitime de demander au fournisseur quelles garanties il propose pour les usages en entreprise et dans le secteur public.

Notre verdict

Si vous dirigez une équipe, ne passez pas cette semaine à débattre de la sécurité des agents. Passez-la à découvrir quels agents vos collaborateurs utilisent déjà, avec les comptes de qui et avec quelles permissions. Donnez ensuite à ces agents des identités propres, limitées et à durée de vie courte, et consignez par écrit les règles pour les sous-traitants. L’épisode du Pentagone, si les informations se confirment, est l’avertissement bon marché. Le prochain pourrait ne pas l’être.