Modèle de risque & classes de protection

La capacité totale d’un agent ne signifie pas qu’il peut tout faire. Cela signifie que le système peut décrire de manière structurée chacun de ses états et chacune de ses capacités, y compris les capacités qui restent fondamentalement interdites à un agent. Le modèle de risque est l’outil qui trace cette limite : précis, lisible par les machines et sans exception.

Zones sensibles

Certaines parties d’un système nécessitent une protection accrue, non seulement contre les attaquants externes, mais aussi contre les agents internes. Une erreur courante consiste à penser :

L’utilisateur peut le voir, donc l’IA peut aussi le voir.

Ce n’est pas exact. L’accès IA effectif résulte de l’intersection entre la permission utilisateur, la permission de l’agent, le niveau de confiance du client, la sensibilité de la ressource, la finalité et le statut de confirmation. Chacun de ces éléments est une barrière indépendante, pas seulement le rôle utilisateur.

Les zones sensibles qui doivent être particulièrement protégées comprennent :

• Données financières, coordonnées bancaires, données de paiement, détails de facturation
• Données de santé, documents médicaux, dossiers de santé, certificats
• Données salariales, salaires, primes, historique de rémunération, exécutions de paie
• Dossiers du personnel, contrats, dossiers de candidature, évaluations internes
• Données d’accès & clés API, mots de passe, clés privées, tokens d’accès
• Fonctions de suppression et en masse, suppression d’utilisateurs, suppression de tenant, export en masse
• Gestion des droits, attribution et révocation de permissions, modification de rôles
• Journaux de sécurité, audit trails, événements de sécurité, sessions actives
• Communications privées, notes confidentielles, appréciations internes
• Données fiscales et contrats, documents fiscaux, contrats à effet juridique
• Données personnelles au sens du RGPD, toutes les données identifiant une personne physique

Six classes de protection

Chaque ressource et chaque outil est assigné à l’une des six classes de protection. La classe détermine qui obtient l’accès, si un agent voit l’outil dans la discovery et quelle approbation est requise avant l’exécution.

Public

Contenu accessible publiquement sans restriction. Pas d’authentification, pas de rôle particulier, pas de confirmation requise. Adapté aux articles d’aide, aux informations produit et aux capacités système documentées.

help.article.read
public.product_info.read

Internal

Uniquement pour les utilisateurs connectés. L’authentification suffit ; pas de droits spéciaux nécessaires. Typique pour les requêtes de liste, les recherches et les vues de travail générales de son propre contexte.

project.list
contact.search

Confidential

Accessible uniquement avec un rôle explicite et un scope attribué. Une simple connexion ne suffit pas. Les données sont internes, mais pas destinées à tous les collaborateurs.

contract.read
customer_private_note.read

Sensitive

Uniquement avec une approbation supplémentaire ou une transmission de contexte restreinte. Un agent ne peut pas charger ces données dans son contexte sans vérification. Lors de la transmission à une IA, la portée doit être étroitement limitée et la finalité documentée.

salary.read
bank_account.read
health_document.read

Critical

L’IA ne peut pas agir de manière autonome dans cette classe. Chaque exécution nécessite une approbation explicite de l’utilisateur, souvent une step-up authentication. Les actions génèrent des effets externes, sont difficiles à annuler ou concernent directement des tiers.

payment.execute
user.delete
contract.send
email.send_external
security.change_permissions

Forbidden for AI

Cette classe est une limite stricte, pas une décision de politique. Les outils et ressources de cette classe sont entièrement masqués de la tool discovery pour les agents. Un agent ne peut ni les lire, ni les appeler, ni les utiliser comme référence.

password.read
private_key.read
full_database_export
raw_access_token.read

Le modèle de risque

Le modèle de risque traduit les classes de protection en règles opérationnelles pour chaque cas d’exécution. Il détermine si l’autonomie est autorisée, si une confirmation est nécessaire et quel type d’approbation est requis.

Low

Opérations purement en lecture ou actions sans effet externe permanent. Les agents peuvent appeler ces outils de manière autonome.

Medium

Des données ou des états sont créés ou modifiés, mais dans un scope étroitement défini sans effet externe. L’exécution autonome est autorisée lorsque le scope et le contexte découlent clairement du workflow.

High

Actions qui modifient des états système pertinents ou concernent d’autres utilisateurs et ressources externes. Une confirmation explicite est généralement requise.

Critical

Communications externes, paiements, suppressions, modifications de permissions. Toujours une confirmation, souvent une step-up auth. L’exécution autonome n’est pas autorisée.

Forbidden

Entièrement verrouillé pour les agents IA, ni en lecture ni en écriture. Non visible dans la discovery, non appelable, non utilisable comme référence.

Interface utilisateur d’approbation

Le modèle de risque technique n’est pleinement efficace que si l’interface utilisateur joue également son rôle. Une confirmation n’est bonne que si les informations sur lesquelles elle se fonde sont complètes.

Avant qu’un humain confirme une action critique d’un agent, il doit pouvoir clairement identifier sept choses :

1. Que veut faire l’agent ?, L’action concrète, pas l’intention de l’agent dans ses propres termes.
2. Pourquoi veut-il le faire ?, Quelle intention ou quel mandat a déclenché cette action.
3. Quelles données sont utilisées ?, Destinataires, pièces jointes, entités référencées.
4. Quels effets externes se produisent ?, Ce qui change en dehors du système : l’e-mail est envoyé, le paiement est déclenché, le document est transmis.
5. Qui est concerné ?, Personnes, entreprises, tenants, parties externes.
6. L’action peut-elle être annulée ?, Déclaration claire : réversible ou irréversible.
7. Que se passe-t-il lors de la confirmation ?, Description complète des prochains états du système.

L’exemple suivant montre à quoi ressemble une carte d’approbation complète pour l’outil emails.send_external :

L’agent attend la décision de l’utilisateur. Il ne peut pas anticiper la confirmation, définir une action par défaut ni baser l’exécution sur l’horodatage d’une approbation antérieure.