Ce que signifie l'autorisation d'agent
L'autorisation d'agent est la décision sur ce qu'un agent IA est autorisé à faire : quels routes il peut appeler, quelles données il peut lire, quelles actions il peut effectuer et à quel volume. Elle se distingue de l'identité de l'agent, qui consiste à établir quel agent, ou l'agent de quel opérateur, effectue la requête.
Les deux notions sont faciles à confondre parce qu'elles arrivent souvent ensemble. Une requête signée vous indique qui l'a envoyée. Elle ne vous dit pas si cet émetteur doit être autorisé à modifier un compte, passer une commande ou exporter des données. L'identité est une preuve ; l'autorisation est une politique. Notre article sur ce que prouvent les requêtes d'agent IA signées, et ce qu'elles ne prouvent pas détaille la différence.
Pourquoi la distinction compte
Les applications distinguent déjà l'authentification de l'autorisation pour les utilisateurs humains : la connexion prouve qui vous êtes, et les rôles et permissions décident ce que vous pouvez faire. Les agents ont besoin de la même séparation, avec un niveau de vigilance supplémentaire :
- L'identité peut être forte alors que l'autorisation est absente. Un crawler avec une signature de message HTTP parfaitement valide n'a aucun droit intrinsèque d'appeler un endpoint d'écriture.
- L'autorisation peut exister sans identité forte. Un agent qui utilise la clé API d'un client est autorisé par cette clé, même si rien n'identifie le logiciel agent qui la détient.
- La personne derrière l'agent compte. Quand un agent agit pour quelqu'un, la question devient de savoir si cette personne lui a donné mandat (voir autorité déléguée).
Réduire ces notions à un seul contrôle conduit à deux types d'échec : bloquer une automatisation légitime parce qu'elle n'a pas de connexion humaine, ou faire confiance à un agent bien identifié pour des actions qu'il n'était pas censé accomplir.
Comment l'autorisation est généralement exprimée
La plupart des applications autorisent les agents à l'aide de mécanismes qu'elles possèdent déjà :
- Identifiants et scopes. Des clés API ou des jetons OAuth 2.0 avec des scopes limités à ce dont l'intégration a besoin. Les serveurs MCP utilisent le même modèle : la spécification d'autorisation MCP traite un serveur protégé comme un serveur de ressources OAuth 2.1.
- Politique au niveau des routes. Des routes en lecture seule ouvertes aux agents connus ; des routes d'écriture nécessitant un identifiant lié à un compte.
- Niveaux de risque. Des actions à faible impact autorisées largement, des actions à fort impact nécessitant des identifiants plus forts, une confirmation ou une revue.
- Limites de débit et quotas par opérateur, par identifiant ou par route.
Les preuves d'identité de l'agent alimentent ces décisions comme un signal parmi d'autres. Pour une approche détaillée, voir concevoir des politiques au niveau de l'application pour les humains et les agents IA. Cela permet de traiter différemment un opérateur vérifié et un client anonyme, mais la permission elle-même provient toujours de votre politique.
Idées reçues courantes
- « Agent vérifié signifie autorisé. » La vérification attribue une requête. Votre politique décide encore ce que la partie attribuée peut faire.
- « Les agents devraient être bloqués sauf s'ils prouvent qu'ils sont humains. » De nombreux agents sont des participants légitimes. La vraie question est de savoir ce que chaque type d'acteur doit être autorisé à faire, route par route.
- « L'autorisation peut être déduite du comportement. » Le comportement peut augmenter ou réduire la confiance dans le type d'acteur présent. Il ne doit pas, à lui seul, accorder une permission.
Comment Proof of Actor le gère
Proof of Actor répond à la question de la preuve : quel type d'acteur est présent, sur quelle base (Verified, Declared, Inferred ou Unknown), et ce qui est connu et ce qui ne l'est pas. Le produit ne décide volontairement pas de la permission. Un résultat Agent, même vérifié, n'implique jamais une autorisation. Dans Route, votre application combine le résultat d'acteur avec ses propres identifiants, scopes et niveaux de risque pour allow, adapt, challenge, review ou limit chaque interaction, en commençant en mode observation afin que vous puissiez vérifier les résultats avant d'appliquer quoi que ce soit.
Apprenez-en plus sur la façon dont les décisions s'intègrent dans votre application, consultez les cas d'usage pour les APIs et les serveurs MCP, ou demandez un accès anticipé.
Sources
- RFC 6749: The OAuth 2.0 Authorization Framework: jetons avec scope pour les clients
- MCP specification 2026-07-28: Authorization: autorisation basée sur OAuth pour les serveurs MCP
- RFC 9421: HTTP Message Signatures: ce qu'une requête signée établit