L’Accès Aux Outils Change Le Risque
Un agent IA qui rédige du texte ne présente pas le même risque qu’un agent capable d’interroger une base de données, de modifier une configuration cloud ou de déclencher un déploiement. Dès qu’il utilise des outils, une mauvaise sortie du modèle peut devenir une action opérationnelle.
La question utile n’est donc pas de savoir si l’agent paraît autonome. Il faut connaître son identité, les données et outils auxquels il accède, ainsi que les actions qu’il peut exécuter dans les conditions présentes. Des autorisations larges ou un compte partagé compliquent la prévention comme l’enquête.
Le Risque D’Une Autonomie Excessive
OWASP définit l’autonomie excessive (LLM06:2025) comme la capacité d’un système fondé sur un LLM à effectuer des actions dommageables après une sortie inattendue, ambiguë ou manipulée. Trois causes reviennent souvent :
- Fonctionnalité excessive : Accès à des outils ou intégrations qui dépassent le rôle défini de l’agent.
- Permission excessive : Accès en lecture ou en écriture à des données et systèmes en dehors du périmètre prévu de l’agent.
- Autonomie sans limite : La capacité d’exécuter des actions à fort impact sans autorisation ni validation secondaire.
Un agent de support qui doit seulement vérifier l’état d’une commande ne devrait pas utiliser des identifiants capables de modifier ou supprimer des enregistrements. L’autorisation dépasse la finalité de l’action, quelle que soit la qualité du modèle.
Une Architecture D’Agents Centrée Sur L’Identité
Traitez chaque agent comme un composant doté d’une identité. Appliquez les contrôles de gestion des identités et des accès d’un compte de service, puis ajoutez les conditions de politique propres à la décision soutenue.
1. Les Agents Ont Besoin D’Une Identité Explicite
Un agent ne doit pas hériter des identifiants de son développeur ni de toutes les autorisations de l’application hôte. Donnez-lui une identité de service distincte, limitée à un rôle opérationnel et révocable sans interrompre les autres services.
2. Le Principe Du Moindre Privilège S’Applique Aussi Aux Agents
Limitez chaque agent aux données, outils, environnements et actions nécessaires. Séparez les droits de lecture, de recommandation, d’approbation et d’exécution. Cette séparation réduit les conséquences d’une compromission ou d’une erreur.
3. Exiger Une Approbation Éclairée Pour Les Actions À Fort Enjeu
Pour une action comme la suppression de données ou la modification d’une configuration de production, utilisez une exécution par étapes tant que les preuves ne justifient pas une automatisation plus étroite :
- L’agent prépare ou rédige l’action.
- La proposition est transmise à un approbateur nommé avec les preuves, l’effet attendu et l’option de reprise.
- L’exécution ne se poursuit qu’après une approbation explicite consignée dans un dossier de décision.
L’approbation est inutile si la personne manque d’autorité, de contexte ou de temps. Le flux doit préciser qui approuve quoi et ce qui se passe en son absence.
Une Gouvernance Dans Le Chemin D’Exécution
La gouvernance doit faire partie du chemin d’exécution. Pour chaque action, le système devrait pouvoir présenter l’identité de l’agent, les preuves et la politique en vigueur, l’origine de l’autorité déléguée et le résultat.
Commencez par l’aide à la décision ou une recommandation soumise à approbation lorsque la limite reste incertaine. N’élargissez l’automatisation qu’après avoir testé l’application des politiques, la supervision et la reprise dans des conditions représentatives.
Si une action d’agent reste difficile à autoriser ou à défendre, Evodant peut aider à définir ses exigences de preuve, d’autorité et de reprise. Planifiez une consultation.