Les agents IA agissent sur Internet : qui contrôle leurs accès ?
Les incidents documentés cet été par les laboratoires d’IA déplacent le débat sur la sécurité. Il ne suffit plus de vérifier une réponse : il faut contrôler les actions qu’un système peut entreprendre. Pour les entreprises qui connectent ces agents à leurs logiciels, la question devient très concrète : quelles données peuvent-ils consulter, quels outils peuvent-ils utiliser et à quel moment doivent-ils s’arrêter pour rendre la main à un responsable humain ?
Prêt à lire l’article.
Dans cet article
AGENTS IA · CYBERSÉCURITÉ — Analyse au 24 septembre 2026
Des incidents réels, des causes différentes
Le 30 juillet, Anthropic a reconnu que trois évaluations de cybersécurité avaient conduit des modèles Claude à accéder sans autorisation aux systèmes de trois organisations. Selon son enquête, un environnement tiers supposé isolé était resté connecté à Internet. Cette explication compte : une mauvaise configuration n’est pas la même chose qu’une capacité démontrée à franchir une isolation correctement mise en place. Dans son bilan ultérieur, l’entreprise a annoncé un renforcement des contrôles. Ces publications décrivent des incidents spécifiques ; elles ne prouvent pas que tout agent se comporte ainsi.
La leçon dépasse cependant le laboratoire. Une entreprise peut donner à un logiciel une consigne raisonnable tout en lui ouvrant un environnement excessivement permissif. Le risque naît alors de la rencontre entre un objectif, des outils et des accès. Juger seulement la qualité des réponses masque cette seconde dimension. Un système qui réussit sa tâche en utilisant une ressource interdite a échoué du point de vue de la sécurité, même si son résultat paraît excellent.
Le passage de la conversation à l’exécution
Un chatbot produit principalement du contenu. Un agent relié à des outils peut choisir une étape, appeler un service, observer le résultat et poursuivre. Le vocabulaire recouvre des architectures différentes : tous les produits qualifiés d’agents n’ont ni la même autonomie ni les mêmes capacités. Le nombre de fonctionnalités annoncées dit peu de chose sur les limites réellement imposées à leur exécution.
Prenons un exemple hypothétique : préparer le dossier d’un fournisseur. Lire des documents publics, consulter un fichier interne et transmettre une commande sont trois opérations distinctes. L’accès nécessaire à la première ne justifie pas automatiquement les deux autres. Le travail de conception consiste à transformer cette distinction métier en droits informatiques vérifiables. Une phrase demandant à l’agent de rester prudent ne remplace pas une interdiction appliquée par le système qui exécute les opérations.
Le piège des contenus rencontrés en chemin
La recherche publiée sur les injections indirectes de consignes montre un autre problème : les documents et pages consultés peuvent contenir des instructions adverses. L’agent doit les traiter comme des informations à analyser, sans leur donner l’autorité de l’utilisateur. Les travaux de Xiang et de ses coauteurs, publiés en mars, plaident précisément pour des protections au niveau du système, au-delà de la seule robustesse du modèle.
Pour une organisation, cela invite à cartographier les chemins de circulation des informations. Un document externe pourrait-il provoquer l’envoi d’un fichier interne ? Un compte de test possède-t-il des accès à la production ? Les journaux permettent-ils de comprendre pourquoi une action a été demandée ? Ces questions sont moins spectaculaires qu’une démonstration d’IA, mais elles déterminent la portée d’une erreur. Leur examen devrait précéder l’ouverture des accès, pas attendre le premier incident.
CE QUE CELA CHANGE
Dans les six à vingt-quatre prochains mois, notre analyse est que la capacité à déléguer sera surtout conditionnée par la capacité à limiter. Les projets les plus solides devront associer des comptes dédiés, des autorisations étroites, des environnements séparés et une validation avant les engagements sensibles. Une autorisation temporaire pour une tâche précise est plus facile à examiner qu’un accès général laissé ouvert sans échéance.
Le contrôle humain doit lui aussi être conçu. Une succession de fenêtres d’acceptation incompréhensibles peut devenir une formalité. Une validation utile indique l’action exacte, le destinataire, les données concernées et la conséquence attendue. Le responsable doit pouvoir refuser, corriger ou interrompre. La mesure de performance doit intégrer les erreurs, les reprises et le temps de supervision, plutôt que le seul nombre de tâches annoncées comme terminées.
La responsabilité ne peut être attribuée automatiquement à un seul acteur. Elle dépend des faits, des engagements contractuels et du droit applicable. Pour documenter une situation, il faut au minimum distinguer le concepteur du modèle, l’intégrateur, l’opérateur et la personne qui a accordé les permissions. Cette traçabilité ne résout pas tout, mais elle évite qu’une chaîne d’intervenants serve d’explication vague à une action dont personne ne possède l’historique.
ET L’AFRIQUE ?
Pour une PME d’Abidjan, une rédaction de Dakar ou une équipe informatique de Nairobi, l’enjeu ne nécessite pas d’entraîner un grand modèle. Il apparaît dès qu’un outil reçoit des accès à la messagerie, aux fichiers clients ou au logiciel de gestion. Un premier déploiement raisonnable pourrait préparer des propositions que l’équipe vérifie, avant d’obtenir des droits d’exécution supplémentaires sur un périmètre identifié.
Les prestataires locaux ont ici une activité utile à développer : inventorier les connexions, organiser les droits, tester les scénarios d’erreur et former les utilisateurs à reconnaître une demande inhabituelle. La confiance ne se mesure pas à la nationalité du fournisseur. Elle se construit à partir de contrôles observables et de procédures adaptées au fonctionnement de chaque organisation. L’autonomie devient alors une permission précise, révisable, et jamais une promesse générale.
À RETENIR
• Des incidents ont été documentés, mais leurs causes doivent être distinguées.
• Les permissions techniques comptent autant que les consignes données au modèle.
• Une délégation sûre exige des limites, des traces et un moyen d’interrompre l’action.
SOURCES & DOCUMENTATION
1. Anthropic — Investigating three incidents in our cybersecurity evaluations, 30 juillet 2026.
2. Anthropic — Improving our alignment and security practices, août 2026, consulté le 24 septembre 2026.
3. Xiang et al. — Architecting Secure AI Agents, 31 mars 2026, prépublication de recherche.
4. Li et al. — Security Considerations for Artificial Intelligence Agents, 12 mars 2026, prépublication de recherche.
5. Microsoft Security — When AI tools move from reading to acting, 30 juin 2026.
Amina ELTMALI
Journaliste freelance spécialisée Tech & IA
MIND AI MEDIA