Cas d’usage · Autorisation
Un compte technique peut disposer du plus petit rôle proposé par une application et rester beaucoup plus puissant que la mission confiée à l’agent. Le contrôle doit alors porter sur l’action demandée au moment où elle est exécutée.
L’application ne propose qu’un rôle permettant l’export : ADMIN. Ce rôle permet aussi de lire, modifier, supprimer et administrer. La mission de l’agent est plus étroite : exporter des enregistrements sélectionnés vers une destination approuvée.
Rôle technique large et politique runtime
Le compte de l’agent possède le rôle ADMIN : lire, exporter, modifier, supprimer et administrer sont techniquement possibles. Une politique runtime, placée sur le chemin, ne laisse passer que l’export ; les autres actions sont bloquées.
Une politique évaluée à chaque appel laisse passer l’export attendu et refuse le reste, sans modifier le rôle dans l’application. Elle peut aussi vérifier que la destination fait partie des destinations approuvées et que le volume reste dans les limites de la mission.
Décision d’autorisation contextuelle
Quatre entrées convergent vers le PDP : identité, action, ressource et contexte. Le PDP rend Permit ou Deny, éventuellement accompagné d’une obligation comme masquer un champ.
Les attributs suivants sont des exemples. Une architecture donnée n’en utilise qu’une partie, selon ce que le point de contrôle peut réellement voir au moment de l’appel.
Une décision n’a d’effet que si le composant qui l’applique se trouve entre l’agent et la ressource, sans chemin alternatif. Emplacements courants :
L’autorisation externalisée est la capacité centrale de ce cas d’usage.
Autorisation externalisée
Axiomatics centralise des politiques d’autorisation et évalue au runtime si une identité peut effectuer une action sur une ressource dans un contexte donné.[1] Sa documentation applique cette approche aux agents IA, aux outils MCP, aux flux RAG, aux données et aux échanges agent-to-agent.[2]
Axiomatics fournit la décision ; l’application de cette décision dépend du point d’enforcement retenu dans l’architecture.
Scénario illustratif : les règles décrites ci-dessous sont fictives. Chaque entreprise doit définir ses propres conditions d'éligibilité, limites d'autonomie et responsabilités d'approbation.
Un client demande un remboursement. L'agent IA consulte le dossier, prépare l'opération et sollicite l'API métier. Mais ce n'est pas parce que son compte technique permet de rembourser qu'il peut déclencher n'importe quel remboursement.
Contrairement à un script dont les étapes sont définies à l'avance, un agent peut choisir ses outils, modifier son approche ou chercher un autre chemin lorsqu'une opération échoue. La sécurité ne peut donc pas reposer sur ses seules instructions : elle doit contrôler l'action elle-même — quel agent demande l'opération, pour le compte de qui, sur quelle ressource, avec quel mandat et dans quelles conditions. Ce décalage entre droits techniques et autorisations effectives est détaillé dans l'analyse Ariovis sur les rôles administrateurs et les agents IA.
Avant l'exécution, un contrôle confronte l'identité et le mandat de l'agent, le dossier client, le montant, le moyen de remboursement et l'état de l'opération aux règles définies par l'entreprise.
La commande est éligible selon la politique métier. Le montant reste dans la limite d'autonomie accordée à l'agent, le moyen de remboursement est autorisé et aucun remboursement équivalent n'a déjà été exécuté.
L'agent peut déclencher le remboursement dans le périmètre autorisé, sans approbation humaine supplémentaire.
L'agent tente de rembourser une commande hors de son périmètre, de reproduire un remboursement déjà effectué ou d'utiliser une destination de remboursement interdite.
L'action est bloquée avant tout appel d'exécution. Une approbation humaine ne doit pas permettre de contourner un interdit explicite.
La demande est légitime mais correspond à une exception commerciale que la politique de l'entreprise autorise uniquement après validation.
L'agent prépare la demande avec la commande concernée, le montant, le bénéficiaire et la justification. L'orchestrateur suspend alors l'exécution et sollicite une personne habilitée.
Tant que cette personne n'a pas approuvé la demande, aucun remboursement n'est déclenché. Une approbation refusée, absente ou expirée ne permet pas d'exécuter l'opération. Si les paramètres changent, une nouvelle validation est nécessaire.
Même après accord, les conditions d'autorisation sont revérifiées avant l'appel à l'application métier.
Ces trois lignes décrivent des issues du processus métier, et non trois décisions natives d'un moteur d'autorisation. Les décisions techniques possibles sur les permissions d'un agent — réduire, suspendre, révoquer, isoler — sont détaillées dans la matrice de contrôle des permissions des agents IA.
Entre la préparation de la demande et son exécution, le contexte peut avoir changé : le dossier a évolué, le mandat n'est plus valide ou les paramètres de l'opération ont été modifiés. L'approbation porte donc sur l'opération précisément soumise au responsable ; elle ne constitue pas une autorisation générale permettant à l'agent de rembourser librement.
Avant l'appel effectif à l'API, le dispositif de contrôle vérifie que l'autorisation reste valide pour cette action précise. Si une règle d'interdiction s'applique, l'opération est refusée, même après validation humaine : l'humain valide une décision métier, et cette validation ne doit pas permettre de contourner la politique de sécurité.
L'agent formule une intention et prépare une opération ; il ne devrait pas disposer d'un accès libre et réutilisable à toutes les opérations offertes par le compte technique de l'application. Un point d'application de politique (PEP) intercepte l'opération et transmet les informations utiles à un moteur de décision (PDP), qui évalue les politiques en fonction de l'identité, du mandat, de l'action, de la ressource et du contexte disponible. Le résultat est appliqué par le PEP avant que l'appel ne produise son effet dans le système cible ; une demande nécessitant une approbation passe par un workflow distinct, puis fait l'objet d'une nouvelle vérification avant exécution.
Trois responsabilités souvent confondues se distinguent ainsi : l'agent propose une action, les politiques déterminent si elle est acceptable et l'application du contrôle conditionne son exécution. Un jeton OAuth valide, un coffre de secrets correctement configuré ou une approbation humaine ne remplacent pas ce contrôle.
La trace doit permettre de retrouver l'identité de l'agent et du demandeur humain lorsqu'il existe, la référence de la commande, les paramètres utiles, la politique appliquée et sa version, la décision et son motif, ainsi que l'identité et l'horodatage de l'approbateur lorsqu'une validation intervient.
Un identifiant de corrélation permet de relier la demande, l'approbation éventuelle et l'opération réalisée.
Enfin, il faut distinguer la décision d'autorisation du résultat réel : une décision « autorisée » ne prouve pas que le remboursement a abouti. Le statut de l'opération doit être vérifié dans le système métier. Cette distinction devient indispensable lorsqu'un agent enchaîne plusieurs opérations dans un même processus métier.
Les journaux doivent être protégés et ne conserver que les informations nécessaires à leur finalité.
À retenir : l'agent propose une action, la politique métier détermine si elle est autorisable, le workflow organise une éventuelle validation humaine et le système d'exécution applique la décision. Une approbation ne transforme jamais un droit interdit en droit autorisé.
Pour passer de l'explication à un projet concret : voir l'approche Ariovis pour sécuriser les agents IA.
Décider action par action avec PDP, PEP, attributs et contexte de délégation.
Jetons, paramètres, montants et destinations contrôlés avant l’appel.
Sources vérifiées le
Documentation éditeur
Axiomatics
Securing AI (lien externe, nouvel onglet)
Documentation Axiomatics consacrée à l'autorisation policy-driven des agents IA, outils MCP, RAG, données et communications agent-to-agent.
Vérifié le
Nous pouvons partir d’un agent existant ou d’un projet en conception pour identifier les ressources, actions et contrôles concernés.
Nous contacter