5 min read Sécurité agents

Agents IA et sécurité des accès : comment éviter qu'ils atteignent des données auxquelles ils ne doivent pas accéder

Agents IA et sécurité des accès : comment éviter qu'ils atteignent des données auxquelles ils ne doivent pas accéder

Le 1er février 2026, des chercheurs en sécurité de Wiz ont découvert que Moltbook, un réseau social viral où des agents IA publient, commentent et échangent entre eux, exposait l'intégralité de sa base de données. La cause : un backend Supabase mal configuré, sans politique de sécurité au niveau des lignes, avec une clé API visible dans le code JavaScript côté client. Résultat : 1,5 million de clés API en clair, OpenAI, Anthropic, AWS, GitHub et Google Cloud confondus, et plus de 4000 conversations privées entre agents accessibles à quiconque trouvait l'endpoint.

Moltbook illustre un problème plus large que sa propre négligence de configuration. L'étude NeuralTrust menée en 2025 auprès de 160 CISOs rapporte que 19,5% d'entre eux ont connu au moins un incident de sécurité confirmé lié à des agents IA. Une autre enquête, plus largement relayée, menée en 2026 auprès de plus de 900 dirigeants et praticiens techniques, avance un chiffre bien plus élevé : 88% rapportant au moins un incident confirmé ou suspecté, un écart qui s'explique probablement par un critère plus large ("suspecté" en plus de "confirmé") et une méthodologie d'échantillonnage moins rigoureuse. Quel que soit le chiffre auquel on accorde le plus de crédit, la tendance est la même : le déploiement d'agents avance plus vite que la mise en place des contrôles d'accès qui devraient l'accompagner.

Le réflexe contre-intuitif à corriger : la plupart des équipes pensent que le risque vient de la compromission du modèle lui-même, un agent "piraté" par une injection de prompt sophistiquée. Le pattern qui revient dans les incidents documentés, Moltbook compris, est plus banal : un agent correctement construit mais sur-privilégié dès sa configuration initiale, à qui personne n'a retiré les accès dont il n'avait pas besoin.

Cadenas ouvert entouré de clés dispersées à l'intérieur d'un périmètre percé, symbolisant des accès non maîtrisés
Un agent sur-privilégié transforme une simple injection de prompt en compromission de l'ensemble de l'environnement connecté.

Ce que Moltbook révèle sur le scoping

L'incident n'est pas qu'une histoire de mauvaise configuration technique. Les clés API exposées appartenaient à des agents individuels qui, dans l'architecture de la plateforme, avaient accès à des permissions largement supérieures à ce que leur tâche réelle nécessitait. Un agent conçu pour publier et commenter n'avait aucune raison de porter des credentials donnant accès à des ressources cloud tierces dans les conversations qu'il échangeait.

C'est le symptôme classique du sur-provisionnement : accorder à un agent une identité unique avec un large périmètre d'accès, plutôt que des permissions étroitement bornées à la tâche en cours. Quand cette identité est compromise, exposée, ou manipulée par injection de prompt, le rayon d'impact correspond à l'ensemble du périmètre accordé, pas à la tâche que l'agent était censé exécuter.

Le principe de moindre privilège, appliqué au runtime

Le modèle de permissioning hérité des systèmes utilisateurs classiques ne transfère pas directement aux agents. Un utilisateur humain reçoit un rôle stable dans le temps. Un agent gagne à recevoir une portée d'accès qui se définit à l'exécution, tâche par tâche, et qui expire avec elle.

Cela se traduit par une identité dédiée par agent plutôt qu'un compte de service partagé, une liste d'outils autorisés restreinte au strict nécessaire pour la tâche en cours, et des credentials à durée de vie limitée qui expirent automatiquement une fois la tâche terminée plutôt que des clés statiques valables indéfiniment.

Quatre cartes présentant les piliers de sécurité des accès : identité, allowlist, credentials éphémères, audit trail
Les quatre piliers du scoping d'accès pour un agent IA en production.

Sandboxing des actions et traçabilité

Restreindre les permissions ne suffit pas si les actions de l'agent ne sont pas isolées et enregistrées. Un agent qui exécute des commandes, appelle des API ou modifie des données devrait le faire dans un environnement d'exécution cloisonné, où une action imprévue reste contenue plutôt que de se propager vers des systèmes adjacents.

Chaque action devrait générer une trace d'audit immuable : quel agent, quelle tâche, quel outil, quelles données touchées, à quel moment. Cette traçabilité n'est pas qu'une exigence de conformité a posteriori. Elle permet de reconstruire la chaîne d'événements en cas d'incident, et de détecter des patterns d'usage anormaux avant qu'ils ne dégénèrent en incident.

Détecter l'escalade avant l'exploitation

Un agent bien scopé au démarrage peut dériver. Une tâche mal cadrée qui pousse l'agent à demander des permissions supplémentaires, une chaîne d'appels d'outils qui élargit progressivement le périmètre d'action, ou une injection de prompt qui tente de faire sortir l'agent de son rôle initial sont des signaux à surveiller activement, pas seulement à corriger après coup.

Le design du rayon d'impact devrait se faire en amont, au moment de connecter l'agent à ses outils et sources de données, pas après un premier incident. La question à poser pour chaque connecteur ajouté est simple : si cet agent est compromis ou manipulé, jusqu'où peut-il aller avec cet accès précis ?

Avant de connecter un agent à des données sensibles

Quatre vérifications suffisent avant la mise en production d'un agent ayant accès à des données sensibles. L'agent dispose-t-il d'une identité propre, distincte de tout compte de service partagé ? La liste d'outils autorisés correspond-elle strictement à ce que la tâche exige, sans marge de confort ajoutée par précaution ? Les credentials expirent-ils automatiquement à la fin de la tâche plutôt que de rester valables en permanence ? Un audit trail complet permet-il de reconstruire chaque action a posteriori ?

Un agent sans ces quatre garanties peut fonctionner parfaitement en conditions normales, jusqu'au jour où il ne le fait plus. Moltbook n'était pas un projet négligé, c'était un produit viral avec plus d'un million d'utilisateurs agents. Le scoping d'accès n'est pas un luxe réservé aux systèmes critiques, c'est une condition de base pour tout agent connecté à autre chose que des données publiques.

À mettre en route cette semaine

Listez tous les agents actuellement en production ou en pilote avancé et vérifiez, pour chacun, s'il porte une identité propre ou un compte de service partagé. Un compte partagé entre plusieurs agents doit être scindé en priorité.

Auditez la liste d'outils et de connecteurs accessibles à votre agent le plus exposé. Retirez tout accès qui dépasse ce que sa tâche actuelle exige, même si cet accès "pourrait servir plus tard".

Vérifiez la durée de vie des credentials utilisés par vos agents. Des clés statiques valables indéfiniment doivent migrer vers des credentials à expiration automatique en priorité sur les agents ayant accès à des données sensibles.

Testez votre capacité de reconstruction post-incident : si un agent agissait de façon anormale demain, combien de temps faudrait-il pour retracer chaque action qu'il a effectuée ? Si la réponse dépasse quelques minutes, l'audit trail est la priorité immédiate.

Conclusion

Moltbook n'est pas un cas isolé, c'est un signal amplifié par sa viralité. Le scoping d'accès, les credentials éphémères et l'audit trail ne sont pas des mesures à réserver aux systèmes critiques une fois qu'un incident s'est produit. Ce sont les conditions de base pour tout agent connecté à autre chose que des données publiques, et l'article sur la gouvernance du risque agentique élargit cette logique du contrôle d'accès statique vers la gouvernance à l'exécution.

Sources : As of July 2026

Godwin AVODAGBE