Ce que signifie l’autorité déléguée
L’autorité déléguée est l’autorisation qu’une personne, ou une organisation, donne à un agent IA pour agir en son nom. Lorsqu’un assistant réserve une réunion dans votre calendrier, crée un ticket de support à votre nom ou récupère une facture sur le portail d’un fournisseur, il exerce une autorité qui provient de vous.
Une bonne délégation a trois propriétés: elle est bornée (l’agent peut faire certaines choses, pas tout), limitée dans le temps (elle expire ou peut être révoquée) et attribuable (l’application destinataire peut identifier de quelle autorité il s’agit).
Pourquoi cela compte pour les applications
Du point de vue d’une application, une requête d’agent soulève jusqu’à trois questions distinctes:
- Quel client a envoyé cela? C’est l’identité de l’agent, que des requêtes signées peuvent établir (voir HTTP Message Signatures).
- Sous quelle autorité agit-il? C’est la délégation.
- Cette autorité suffit-elle pour cette action? C’est l’autorisation, décidée par la politique propre à l’application.
Une requête signée provenant d’un opérateur d’assistant bien connu répond correctement à la première question. Elle ne dit rien, à elle seule, sur la seconde. L’assistant peut agir pour l’un de vos utilisateurs, pour quelqu’un qui n’est pas votre utilisateur, ou entièrement de sa propre initiative. Assimiler l’identité du client à la preuve du consentement d’une personne est l’une des erreurs les plus courantes dans la conception orientée agent. Voir ce que prouvent les requêtes signées d’agents IA, et ce qu’elles ne prouvent pas.
Comment la délégation est généralement exprimée
- Autorisations de type OAuth. La personne se connecte à votre application et accorde à un agent un token avec des scopes limités, comme défini dans OAuth 2.0 (RFC 6749). Votre application sait alors exactement quelle autorité le token porte, et l’autorisation peut être révoquée (RFC 7009).
- Clés API limitées au compte qu’un utilisateur crée pour une intégration spécifique, idéalement avec des permissions étroites.
- Confirmations dans l’application pour les actions à fort impact, lorsque la personne approuve une action précise préparée par l’agent.
- Claims de délégation au niveau du token. OAuth 2.0 Token Exchange (RFC 8693) définit un claim
act(actor) qui enregistre une partie agissant pour le compte d’une autre. Les travaux plus récents sur l’expression de la délégation d’agent dans les requêtes sont encore en développement, et les applications doivent vérifier tout claim de délégation à partir de leurs propres registres plutôt que de le prendre pour argent comptant.
Idées reçues fréquentes
- "Si l’agent est vérifié, l’utilisateur l’a approuvé." La vérification identifie le client. L’approbation doit venir de la personne, via un canal en lequel votre application a confiance.
- "Un agent qui utilise la session de mon utilisateur, c’est acceptable." Cela peut l’être, mais la session a été émise pour une utilisation humaine interactive. Beaucoup d’applications préfèrent une autorisation dédiée et limitée pour l’automatisation, afin que les actions soient attribuables et révocables.
- "La délégation est totale ou inexistante." Les délégations les plus sûres sont étroites: accès en lecture de manière large, accès en écriture seulement pour des actions précises, et confirmation pour tout ce qui est irréversible.
Le lien avec Proof of Actor
Proof of Actor vous aide à voir quand une interaction est pilotée par un agent ou assistée par IA, et sur quelle base: Verified, Declared, Inferred ou Unknown. Ce contexte indique où des questions de délégation apparaissent, par exemple lorsqu’un autonomous agent agit dans une session de compte humain. Proof of Actor n’émet ni ne valide de justificatifs de délégation, et un résultat Agent n’implique jamais qu’une personne a autorisé l’action. Les autorisations, scopes et confirmations propres à votre application décident de cela, et Route vous permet d’appliquer la bonne politique par route une fois que vous avez observé du trafic réel. Pour des modèles de politique, voir concevoir des politiques au niveau de l’application pour les humains et les agents IA.
Lisez ce que les preuves peuvent et ne peuvent pas établir, ou demandez un accès anticipé.
Sources
- RFC 6749: The OAuth 2.0 Authorization Framework: autorisations limitées accordées par le propriétaire d’une ressource à un client
- RFC 7009: OAuth 2.0 Token Revocation: révocation d’un token délégué
- RFC 8693: OAuth 2.0 Token Exchange: le claim
act(actor) pour la délégation