Qu’est-ce qui rend un agent IA plus risqué : la puissance du modèle qu’il utilise, ou le nombre de capacités qu’on lui a accordées ? Cette deuxième variable, moins souvent discutée que la première, mérite qu’on s’y attarde, en particulier pour les petites structures qui n’ont ni équipe de sécurité dédiée ni budget pour un audit approfondi.
La notion de surface d’attaque, empruntée à la sécurité informatique classique, s’applique directement aux abilities déclarées pour un agent : chaque capacité ajoutée est un point d’entrée supplémentaire, et le risque global ne se contente pas de s’additionner — il se combine, certaines abilities devenant dangereuses uniquement en présence d’autres.
Ce qu’est la surface d’attaque appliquée aux abilities
Une ability isolée, correctement restreinte par son permission_callback, présente un risque limité et généralement bien identifiable. Le problème apparaît quand plusieurs abilities, chacune raisonnable prise séparément, se combinent pour permettre une action que personne n’avait anticipée lors de la conception individuelle de chacune.
Un exemple concret de combinaison risquée
Une association culturelle organisant des expositions temporaires avait déclaré, au fil du temps et de différents projets, quatre abilities distinctes : lecture des fiches d’œuvres, modification des descriptions, export de la liste des inscrits à une visite guidée, et envoi de notifications aux inscrits. Prises séparément, chacune semblait raisonnable.
Comment ces quatre abilities pouvaient se combiner
Un agent disposant simultanément de ces quatre capacités pouvait, en théorie, exporter la liste des inscrits à une visite, puis leur envoyer une notification contenant une information erronée si une description modifiée par erreur avait été intégrée automatiquement dans le message. Aucune de ces quatre abilities prise seule ne permettait ce scénario ; leur combinaison, si.
// Avant : quatre abilities disponibles simultanément pour le même rôle
wp_register_ability( 'expo/lire-oeuvres', array( /* ... */ ) );
wp_register_ability( 'expo/modifier-description', array( /* ... */ ) );
wp_register_ability( 'expo/exporter-inscrits', array( /* ... */ ) );
wp_register_ability( 'expo/notifier-inscrits', array( /* ... */ ) );
// Après : deux rôles distincts, aucun agent ne cumule les quatre capacités
// Le rôle "agent_contenu" garde lire-oeuvres et modifier-description
// Le rôle "agent_communication" garde exporter-inscrits et notifier-inscritsLe fonctionnement de la correction appliquée
La séparation en deux rôles distincts, chacun limité à deux abilities cohérentes entre elles, a supprimé la combinaison risquée sans retirer aucune fonctionnalité utile. Un agent de contenu ne peut plus notifier qui que ce soit ; un agent de communication ne peut plus modifier une description d’œuvre.
- Le principe suivi : regrouper les abilities par intention fonctionnelle, jamais par simple commodité de configuration.
- Un même agent conversationnel peut appeler successivement les deux rôles si nécessaire, mais chaque rôle reste cloisonné côté permissions.
- Aucune régression fonctionnelle n’a été observée après cette séparation, contrairement à une crainte initiale de l’équipe.
Ce que cela signifie pour une petite structure sans expertise en sécurité
Une association ou une petite entreprise sans compétence de sécurité dédiée peut appliquer une règle simple, sans expertise particulière : avant d’ajouter une nouvelle ability à un rôle existant, se demander si cette capacité, combinée aux abilities déjà accordées à ce même rôle, ouvre une possibilité nouvelle et non désirée. Si la réponse n’est pas claire, un nouveau rôle séparé reste la solution la plus sûre.
Le risque d’un agent ne se mesure pas ability par ability, mais à la combinaison de ce qu’il peut faire à la fois : deux capacités anodines isolément peuvent, ensemble, ouvrir une porte que personne n’avait prévue.
En résumé
Limiter le nombre d’abilities accordées à un même rôle n’est pas une question de méfiance envers l’agent ou le modèle utilisé, mais une discipline de conception qui réduit mécaniquement les combinaisons possibles, donc les scénarios imprévus. Pour une petite association sans moyens de sécurité dédiés, cette discipline reste accessible : elle ne demande ni budget ni expertise technique poussée, seulement la rigueur de séparer les rôles selon l’intention plutôt que selon la facilité de configuration.
