Agent IA : transmettre les droits sans les élargir

Alice peut préparer un brouillon de devis, mais ne peut pas le publier. L’agent utilise un compte technique capable des deux opérations. Si le service ne vérifie que ce compte, une simple demande d’Alice peut produire une action qu’elle n’aurait jamais pu réaliser directement. Le risque devient une publication sans habilitation : l’assistance a changé les droits du parcours au lieu de seulement aider l’utilisateur à accomplir son travail.

En pratique, une action déléguée doit rester dans l’intersection des droits courants de l’utilisateur, de la capacité technique et de la délégation autorisée sur la ressource demandée. L’intégration d’un agent IA au système d’information doit porter ces éléments jusqu’au point qui décide l’action. Un nom transmis dans le prompt ou une signature valide ne remplace pas cette décision métier.

Nous vérifions dix-huit parcours manuscrits sur trois devis fictifs, avec un registre local et une enveloppe signée de laboratoire. Trois parcours sont acceptés, dont un brouillon local ; aucun ERP ou fournisseur d’identité n’est appelé. Pour une IA sur mesure qui prépare un devis, le compte technique capable de publier ne transmet pas ce droit à l’utilisateur qui peut seulement rédiger. La délégation doit préciser l’objet et les opérations encore permis au moment de l’appel.

Pour qui distinguer utilisateur et compte technique

Repérer les opérations effectuées pour une personne

Le sujet concerne une application où l’assistant lit ou prépare une action à la demande d’un utilisateur : consulter un devis, préparer une modification ou rechercher un dossier. Le serveur appelle parfois le SI avec une identité technique parce que l’interface aval l’exige. Cette nécessité de connexion ne détermine pas les droits métier de la personne. Le service doit conserver cette seconde décision même lorsque le logiciel cible ne connaît que son compte.

Commencez par classer les opérations : lecture, préparation, écriture finale et émission externe. Elles n’ont pas nécessairement le même propriétaire ou la même condition d’autorisation. Un utilisateur peut lire sans modifier, préparer sans publier, ou intervenir seulement sur ses dossiers. L’introduction de l’IA ne doit pas réunir ces capacités dans une permission générale « utiliser l’assistant » qui rendrait les distinctions précédentes inopérantes.

Nommer les missions sans utilisateur actif

Une tâche planifiée peut agir au nom d’une mission de service, sans session utilisateur courante. Elle doit alors posséder une autorisation explicite pour cette mission, ses ressources et sa durée. Lui attribuer arbitrairement le dernier utilisateur du dossier crée une identité trompeuse. La trace doit permettre de reconnaître une opération de service et une opération déléguée par une personne.

Notre banc traite seulement une délégation d’Alice à un acteur technique nommé. Il ne définit pas les droits des traitements nocturnes ou des missions autonomes. Cette limite évite de présenter une politique de délégation comme une réponse à tous les usages d’agents. Le propriétaire métier doit choisir le type de mission avant de décider comment ses droits seront représentés et revalidés.

Conserver le sujet et l’acteur de l’action

Distinguer la personne représentée du service qui agit

Le sujet est Alice, dont les droits encadrent la demande. L’acteur est svc-ia, qui exécute l’appel. La délégation D30 lie ces deux identités pour des actions et des objets définis. La RFC 8693 sur l’échange de jetons OAuth distingue délégation et impersonation, et prévoit des représentations du sujet et de l’acteur. Leur mise en œuvre dépend de l’infrastructure et de sa politique.

Notre enveloppe locale ne reproduit aucun échange OAuth ni JWT. Elle conserve ces noms pour vérifier la décision du laboratoire. L’identité d’entrée est fixée par la recette, pas authentifiée par un fournisseur. Dans une application réelle, le service doit établir la correspondance entre identité authentifiée, utilisateur métier et acteur autorisé, sans laisser le modèle fournir seul cette correspondance.

Garder l’origine des identifiants compréhensible

Les arguments d’un outil peuvent nommer un devis ou une action. Ils ne doivent pas redéfinir la personne qui délègue. Dans I30-05, la proposition ajoute subject=bob aux arguments alors que l’enveloppe désigne Alice. Le contrôleur refuse cette présence avec argument_identity_denied. Il ne choisit pas entre deux identités concurrentes et ne consulte pas les droits de Bob pour débloquer le devis demandé.

La règle concerne également les identifiants trouvés dans un document, une mémoire d’agent ou un résumé. Ils peuvent décrire des interlocuteurs ; ils ne créent pas une session ou un mandat. Le service doit séparer contenu à interpréter et contexte d’autorisation provenant d’une source de confiance. Cette séparation reste nécessaire si la génération est parfaitement conforme au prompt et n’a subi aucune attaque connue.

Combiner les droits sans prendre leur union

Rendre les trois conditions visibles

Alice possède quote.read et quote.draft sur QA1. L’acteur technique possède aussi quote.publish. La délégation D30 autorise lecture et brouillon de QA1. Pour publier, la capacité du compte existe, mais le droit d’Alice et la délégation ne l’autorisent pas. Le service refuse donc cette demande. L’union des trois listes aurait ajouté précisément la capacité qui doit rester absente du parcours d’Alice.

La politique du banc vérifie également la portée d’action signée dans l’enveloppe. Chaque condition peut réduire la capacité finale. Les trois listes ne suffisent donc pas sans audience, expiration, état des identités et ressource. Cette matrice décrit une règle locale explicite ; elle ne prétend pas que tous les logiciels utilisent ces noms ou qu’un compte technique doive posséder le droit de publication.

Réduire le compte même lorsque le contrôle métier existe

Conserver les droits utilisateur dans la passerelle ne justifie pas un compte technique administrateur. Le logiciel aval doit donner au service les capacités minimales de sa mission, lorsque son interface le permet. Un défaut de passerelle ne doit pas rencontrer inutilement tous les droits du SI. L’équipe doit examiner les chemins directs et les fonctions qui pourraient contourner le contrôle de délégation.

Le compte large de notre exemple sert à rendre la différence observable. Il n’est pas une configuration conseillée. Si le besoin se limite aux brouillons, la publication peut être retirée au compte lui-même. La politique utilisateur reste alors utile pour distinguer qui peut préparer quoi. Ces deux protections répondent à des niveaux différents et doivent être vérifiées avec les interfaces réellement ouvertes.

Contrôler société et dossier effectivement demandés

Refuser un objet d’une autre société

Le banc possède QA1 et QA2 en société A, et QB1 en société B. Alice appartient à A. I30-03 demande QB1 avec une enveloppe valide et une action de lecture permise ; resource_scope_denied refuse l’objet. Le service n’accepte pas une société libre transmise dans les arguments pour justifier cette lecture. L’appartenance de l’objet provient du registre de ressources, pas de la description générée.

Les attributs utiles doivent être obtenus sans divulguer au demandeur des données qu’il n’a pas le droit de lire. Le contrôle peut utiliser une interface d’autorisation ou une requête serveur bornée pour établir le périmètre. La sortie utilisateur reste un refus adapté. Un message qui reproduit le devis étranger pour expliquer pourquoi il est interdit aurait déjà traversé la frontière qu’il prétend faire respecter.

Ne pas confondre même société et même habilitation

Exemple concret : I30-04 demande QA2, qui appartient pourtant à A comme Alice. Le registre d’Alice ne lui donne que QA1, et QA2 appartient au périmètre de Bob. Le refus reste resource_scope_denied. Vérifier seulement la société aurait autorisé une lecture hors habilitation. L’objet demandé compte autant que l’action et l’entité de rattachement.

La référence OWASP sur l’autorisation recommande de vérifier les permissions à chaque requête et sur les objets concernés. Connaître ou deviner un identifiant ne crée pas un droit. Notre registre illustre cette règle avec trois objets ; un déploiement réel doit couvrir recherches, pièces jointes, exports et résultats dérivés selon son modèle métier.

Porter une délégation qui ne vient pas du prompt

Faire vérifier le contexte par le point d’exécution

Le service reçoit une enveloppe avec sujet, acteur, audience, expiration, identifiant et révision de délégation. Le banc signe un JSON canonique avec HMAC et une clé fictive incluse dans la recette, sans valeur opérationnelle. La signature permet uniquement de vérifier que l’enveloppe n’a pas changé selon cette recette. Elle ne démontre ni connexion d’Alice ni conformité OAuth, et ne doit pas être reprise comme architecture de production.

{
  "subject": "alice",
  "actor": "svc-ia",
  "audience": "erp-lab",
  "expires": 1100,
  "delegation_id": "D30",
  "delegation_revision": 2,
  "actions": ["quote.read", "quote.draft", "quote.publish"]
}

Ces claims sont ceux réellement vérifiés ; expires=1100 est comparé à une horloge fixe NOW=1000, sans timestamp de production. La portée technique inclut publication pour éprouver le refus métier. La délégation courante ne l’inclut pas et Alice non plus. Le service distingue donc intégrité du contexte, capacité technique et autorisation de l’action au lieu de considérer toute enveloppe signée comme un permis global.

Choisir la représentation compatible avec les interfaces disponibles

Une infrastructure peut utiliser une délégation native, un échange de jetons ou une passerelle qui applique les droits métier avant un appel technique. Le choix dépend des interfaces effectivement disponibles et des garanties d’identité. Il faut vérifier qui émet, valide et peut révoquer chaque capacité. La présence d’une API ne signifie pas qu’elle sait nativement recevoir ou appliquer les droits d’un utilisateur déléguant.

Si le SI ne connaît que le compte technique, la passerelle devient un point essentiel d’autorisation et d’audit. Elle doit éviter un chemin direct qui permettrait d’appeler l’outil sans ses contrôles. Le modèle n’a pas besoin de recevoir le secret ou le jeton pour préparer les arguments métier. La transmission du contexte de confiance et la préparation de la proposition restent deux responsabilités distinctes.

Vérifier la destination et la capacité technique

Ne pas réutiliser un contexte pour un autre destinataire

I30-07 présente une audience crm-lab au contrôleur erp-lab. La signature est valide, mais audience_denied refuse la requête avant le contrôle métier. Un contexte destiné à une autre ressource ne doit pas être accepté simplement parce que le service connaît son émetteur. La destination de la capacité doit être vérifiée au point qui la consomme.

La spécification d’autorisation MCP du 28 juillet 2026 impose notamment la vérification des jetons pour leur audience et interdit le transit de jetons d’autres ressources. Ce principe ne rend pas notre enveloppe conforme à MCP. Une intégration réelle doit prévoir les identités et capacités propres à chaque étape, sans transmettre aveuglément un jeton reçu vers un logiciel aval.

Refuser une capacité technique trop étroite sans l’élargir

I30-09 demande un brouillon avec une enveloppe dont la portée technique n’autorise que quote.read. Alice pourrait préparer QA1 et la délégation le permet, mais technical_capability_denied refuse l’appel. La capacité finale doit aussi être réalisable par le service autorisé. Le contrôle métier ne doit pas transformer un manque de portée technique en permission d’utiliser un autre compte plus puissant.

L’expiration et l’état de l’acteur sont des contrôles supplémentaires. I30-08 échoue avec credential_expired ; I30-06 avec actor_denied. Un service peut traduire ces motifs pour le parcours utilisateur sans publier les détails de ses comptes. La reprise doit utiliser une procédure d’autorisation définie, avec budget de tentatives, plutôt qu’une boucle d’agents qui cherchent un jeton ou une identité acceptée.

Revalider un droit retiré pendant une attente

Lire le droit courant au dispatch

Deuxième cas concret : Alice prépare une demande de brouillon alors que son registre révision 3 autorise lecture et préparation. Avant le dispatch, la révision 4 retire quote.draft et conserve quote.read. I30-12 garde la même enveloppe signée et la même délégation, mais le contrôleur lit le registre courant : user_permission_denied refuse le brouillon. I30-13 autorise encore la lecture et trace la révision utilisateur 4.

La signature n’a pas expiré, mais elle ne fige pas les droits d’Alice. Ce comportement est un choix de notre politique locale, avec lecture synchrone du registre. Il ne prouve pas une propagation de révocation entre plusieurs systèmes ni un délai maximal de prise en compte. Un service distribué doit définir caches, disponibilité, invalidation et comportement lorsque l’état courant ne peut pas être établi.

Révoquer ou remplacer la délégation sans effacer le sujet

I30-14 désactive D30 : delegation_revoked refuse une lecture auparavant autorisée. I30-15 conserve une délégation active mais passe sa révision à 3 ; l’enveloppe révision 2 reçoit delegation_stale. Ces deux états demandent des reprises différentes. Une nouvelle délégation doit être établie par le service compétent, sans recycler un contexte ancien en changeant simplement son numéro dans les arguments du modèle.

L’échange de jetons ne garantit pas à lui seul la propagation des révocations : la RFC 8693 précise que cette liaison dépend de l’implémentation. La recette de déploiement doit donc provoquer retrait utilisateur, retrait de délégation et expiration à chaque frontière pertinente. Une validation humaine précédente ne conserve pas automatiquement un droit qui a disparu avant l’action ; le service doit décider ce qui reste autorisé au moment où elle sera effectuée.

Dix-huit parcours et leurs décisions observées

Comparer des contextes manuscrits au même contrôleur

Chaque parcours utilise une copie du registre initial et une mutation explicitement choisie. Le contrôleur vérifie signature, audience, expiration, origine des identités, état des acteurs, actions, objet et délégation. Il renvoie la première frontière refusée. Les codes ne décrivent pas toutes les causes qui auraient pu bloquer la demande après ce point. Aucun appel réseau ou modèle ne produit ces contextes.

Ne pas confondre acceptation de politique et action réelle

Les trois acceptations correspondent à deux lectures et un brouillon représenté par DRAFT30 dans le résultat local. Ce brouillon n’est pas enregistré dans un ERP ; aucun devis n’est publié ou envoyé. La trace de chaque acceptation conserve sujet, acteur, action, ressource et révisions courantes. Pour les quinze refus, le résultat reste absent. Le banc ne mesure pas une qualité d’inférence ou un taux d’autorisation en production.

La recette réelle doit ajouter les interfaces et les conditions de décision du métier. Créer un brouillon peut aussi exiger version du devis, valeurs admises ou confirmation selon le processus. La validité d’une délégation n’autorise pas une modification incohérente. Le contrôle d’identité répond à « qui peut agir sur quoi » ; le contrat d’action doit aussi définir « quelle transformation est admissible maintenant ».

Reprendre un refus sans choisir une autre identité

Conserver le motif sans transformer le refus en panne

Une demande hors habilitation ne nécessite pas forcément une correction technique. Elle peut être correctement refusée. Le produit doit distinguer droit absent, contexte expiré, délégation remplacée et identité inconnue. L’utilisateur peut demander l’accès par la procédure prévue ou choisir une opération qu’il possède déjà. L’assistant ne doit pas changer le sujet ou prendre un compte partagé pour poursuivre la demande initiale.

Le contrat d’outil retourne une sortie typée et une prochaine action permise. Pour un droit retiré, le repli peut conserver le brouillon de proposition sans l’exécuter et signaler que la capacité n’est plus disponible. La responsabilité de revoir l’habilitation reste au propriétaire compétent. Les détails techniques des refus doivent être accessibles aux personnes habilitées sans révéler un autre dossier à l’utilisateur.

Tracer le sujet utile sans journaliser les secrets

La journalisation relie l’entrée de mission, le sujet vérifié, l’acteur, la ressource et la version de contrat à la décision. Cette instrumentation doit permettre de reconstruire quel droit courant a été consulté au dispatch. Elle peut conserver des références ou empreintes selon le besoin, sans recopier le jeton, la clé ou tous les contenus du devis. Les permissions sur les traces font partie du dispositif.

Une trace qui n’identifie que svc-ia rendrait tous les parcours indiscernables. Une trace qui n’identifie qu’Alice masquerait le service et la délégation utilisés. Conserver les deux aide à diagnostiquer une régression de workflow ou une erreur de configuration. Le banc vérifie ces champs dans ses trois acceptations ; il ne valide pas une collecte distribuée, une durée de conservation ou une politique juridique complète.

Erreurs fréquentes dans la transmission des droits

Traiter un nom connu comme une identité autorisée

Un agent peut retrouver un nom dans l’ERP, un document ou sa mémoire et le reprendre dans les arguments. Ce nom décrit une personne ; il n’établit pas que la demande vient d’elle. La correspondance avec la session vérifiée doit être imposée côté service. Une identité inconnue doit provoquer une abstention ou un parcours d’authentification défini, pas un rapprochement approximatif effectué par le modèle.

Paradoxalement, une signature techniquement correcte peut faciliter une fausse confiance si le service ne vérifie pas ce qu’elle représente. I30-16 utilise une enveloppe signée avec un sujet inconnu et reste refusé. I30-17 modifie le sujet sans nouvelle signature et échoue plus tôt. L’intégrité du contexte et la reconnaissance de l’utilisateur sont deux contrôles distincts ; aucun ne démontre seul son habilitation sur QA1.

Conserver un droit ancien dans la mémoire de l’agent

Un résumé peut indiquer qu’Alice pouvait préparer un devis lors de la première étape. Cette information historique ne doit pas faire autorité après retrait du droit. La reprise consulte les registres courants et la version de délégation avant un nouvel effet. Les agents doivent recevoir le verdict du service plutôt qu’un état mémorisé « autorisé » qu’ils interpréteraient comme une capacité permanente.

Les sources d’un RAG peuvent expliquer une règle d’accès, avec citations et contexte ; elles ne délivrent pas un mandat. Une procédure retrouvée peut être dépassée ou ne pas correspondre au dossier demandé. L’outil d’autorisation applique les droits effectifs et les règles du système, même si une réponse générée affirme le contraire. Une nouvelle version de prompt ne doit jamais devenir la seule barrière entre une proposition et une action SI.

Plan d’action pour une délégation vérifiable

Partir de deux opérations et de leur périmètre métier

Choisissez une lecture et une préparation dont le métier sait définir les habilitations. Identifiez personnes, acteur technique, objets et conditions de délégation. Le propriétaire SI confirme ce que l’interface cible peut appliquer nativement ; l’équipe applicative décrit les contrôles qu’une passerelle doit porter. Il faut pouvoir nommer le point où une proposition devient une action autorisée avant de choisir le modèle ou son format d’outil.

1. Cartographier sujet, acteur, action et ressource. Distinguer société, dossier et attributs sensibles ; conserver les cas où l’utilisateur peut lire sans préparer, ou préparer sans publier.
2. Établir l’origine de confiance des identités. Définir la représentation de délégation et son destinataire ; interdire aux arguments générés de remplacer le sujet ou l’acteur imposés par le service.
3. Vérifier droits utilisateur, capacité technique et délégation sur l’objet courant. Provoquer accès inter-entités, accès intra-entité interdit, audience étrangère et identité inconnue avec des attentes explicites.
4. Revalider au dispatch et à la reprise après attente. Tester retrait de droit, désactivation, expiration et remplacement de délégation ; définir un repli lorsque le registre courant est indisponible.
5. Exploiter refus et traces sans secrets. Attribuer les reprises, borner les tentatives et rejouer les cas lorsque comptes, contrats, registres ou interfaces changent.

Le livrable comprend matrice de droits, parcours défavorables et résultats effectivement observés. Le budget doit couvrir la vérification d’identité et son exploitation, pas seulement la génération de réponse. La latence et le coût de consultation des droits sont mesurés sur l’architecture retenue. Notre registre en mémoire ne permet pas d’estimer ces valeurs pour un SI distribué ou un annuaire réel.

Écrire le comportement lorsque l’autorisation ne peut pas être établie

Le runbook décrit entrée sans identité reconnue, sortie refusée, registre indisponible et délégation périmée. Le contrat attribue la responsabilité de reprise au bon propriétaire, avec une limite de tentatives et une voie humaine. L’absence de réponse du contrôle ne doit pas se transformer en droit accordé. Une préparation peut rester visible pour examen sans déclencher la modification du SI.

La recette représentative vérifie aussi les chemins indirects : pièce jointe, export, recherche et reprise par une tâche. Elle doit établir si les contrôles restent appliqués lorsque le modèle choisit un autre outil ou lorsqu’une action quitte le processus interactif. L’autorisation doit suivre la capacité jusqu’au point d’exécution pertinent ; un contrôle visible dans l’écran ne suffit pas si l’API permet de contourner le même droit.

Guides entre identité, API et décision métier

Insérer la délégation dans le contrat d’intégration

L’intégration d’un agent aux contextes et actions ERP/CRM place identité et permissions parmi les conditions de l’outil métier. Le sujet vérifié ne suffit pas sans ressource, transformation et résultat. Le service doit conserver cette chaîne lorsque la proposition traverse plusieurs interfaces avant de produire un effet.

Cette chaîne permet de localiser la décision manquante. Une capacité technique valide peut être refusée sur l’utilisateur ; une délégation valide peut encore porter une proposition métier incorrecte. Relier ces états rend la supervision plus utile que la seule réussite HTTP d’un appel. Le propriétaire du processus peut alors comprendre quelle vérification a autorisé la préparation et laquelle reste nécessaire avant son effet final.

Séparer protocole d’outil et autorisation de changement

La frontière d’autorisation entre MCP et API montre que changer de protocole ne remplace pas la politique métier. Le contrôle d’une action IA sur des données périmées examine l’autre dimension de reprise : la proposition peut rester dans les droits tout en portant sur un état qui a changé.

Les deux vérifications doivent se rejoindre au bon moment. Un droit conservé n’autorise pas à confirmer un ancien montant ; une donnée fraîche ne permet pas d’agir avec un droit retiré. Le dossier de décision garde identité, délégation, version métier et confirmation selon le contrat. Ces conditions peuvent conduire à une reprise humaine différente, sans fusionner tous les refus dans une erreur technique indistincte.

Conclusion : faire agir l’assistance dans les droits courants

Le compte technique donne au service une capacité de connexion et d’action. Il ne remplace pas les droits de l’utilisateur représenté. Une délégation vérifiable conserve sujet, acteur, destination, action et ressource, puis confronte cette demande aux droits courants. L’assistance peut ainsi préparer ce que la personne est autorisée à faire, sans hériter indirectement de toutes les capacités du compte aval.

Les dix-huit parcours fictifs rendent visibles cette intersection et ses refus. Un devis de la même société reste interdit lorsqu’il n’appartient pas au périmètre d’Alice. Le retrait du droit de brouillon bloque la préparation mais conserve la lecture permise. L’enveloppe signée ne fige pas ces droits. Trois acceptations et quinze refus vérifient la politique locale ; aucun système d’identité ou ERP de production n’est évalué.

L’intégration IA au système d’information doit éprouver cette frontière avec les interfaces disponibles, y compris après attente, révocation et changement d’outil. Le résultat attendu est une décision explicable et une reprise attribuée, avec des traces qui relient personne et service sans exposer leurs secrets.

Dawap accompagne la délégation d’une IA sur mesure à vos logiciels à partir d’un utilisateur autorisé à préparer un brouillon sur un objet précis. Avec l’équipe SI, nous séparons ses droits de ceux du compte technique et testons une révocation pendant la mission. Le raccordement au fournisseur d’identité et à l’interface métier doit ensuite montrer où cette restriction est vérifiée, et qui reprend la demande lorsque le droit requis a disparu.