Ce qui a changé et ce qui n'a pas changé dans l'authentification et l'identité pour les applications agentiques

Récemment, j'ai examiné cet article et l'authentification d'agents a été mentionnée :

Nous voyons des indices de ce à quoi cela pourrait ressembler. La dernière spécification MCP, par exemple, inclut un cadre d'autorisation basé sur OAuth 2.1, signalant une possibilité d'avancer vers la fourniture aux agents IA de jetons délimités et révocables au lieu de secrets bruts. Nous pouvons imaginer un scénario où un agent IA n'obtient pas vos clés AWS réelles, mais obtient plutôt un justificatif d'identité à durée de vie limitée ou un jeton de capacité lui permettant d'effectuer une action définie de manière étroite.

https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/

Beaucoup d'amis et de personnes ne travaillant pas dans le domaine de la sécurité ou de CIAM ont l'impression que c'est quelque chose de nouveau, mais ce n'est définitivement pas le cas. OAuth est un protocole d'autorisation standard basé sur des jetons qui implique des jetons avec des autorisations délimitées (jetons d'accès). Ceux-ci sont sensibles au temps et limités en portée, ce qui assure la sécurité et un contrôle d'accès approprié aux ressources et services. Dans le marché mondial du SaaS (avant l'IA), la plupart des solutions d'identité professionnelles sont déjà construites sur cela.

Lorsque vous connectez votre compte Google à une application tierce comme Notion ou Zoom, cela utilise OAuth pour demander uniquement les permissions nécessaires, comme l'accès à votre calendrier ou à vos contacts, sans jamais exposer votre mot de passe Google. Vous pouvez révoquer cet accès à tout moment dans les paramètres de votre compte Google. Ce modèle d'accès délégué est exactement ce pour quoi OAuth est conçu et c'est la même fondation qui est étendue aux applications agentiques aujourd'hui.

Ce qui ne change pas dans le monde agentique#

L'authentification n'est pas nouvelle, elle est toujours basée sur OAuth 2.1#

Il y a deux principaux protocoles émergents : MCP et A2A.

• MCP se concentre sur l'interaction entre les LLM et les outils et le contexte de votre application.
• A2A se concentre sur la facilitation de l'échange de tâches entre agents.

Mais en matière d'authentification et d'autorisation, les deux reposent toujours sur des standards industriels bien établis comme OAuth.

Les serveurs d'autorisation MCP DOIVENT implémenter OAuth 2.1 avec des mesures de sécurité appropriées pour les clients confidentiels et publics.

Le client A2A est responsable de l'obtention des documents d'identification nécessaires (par exemple, jetons OAuth 2.0, clés API, JWT) par le biais de processus externes au protocole A2A lui-même. Cela pourrait impliquer des flux OAuth (code d'autorisation, justificatifs clients), distribution sécurisée de clés, etc.

Comme le dit Google :

Au lieu d'inventer de nouvelles normes propriétaires pour la sécurité et les opérations, l'A2A vise à s'intégrer parfaitement à l'infrastructure d'entreprise existante et aux meilleures pratiques largement adoptées.

Un agent a-t-il besoin d'une identité unique ?#

Beaucoup de contenus de battage médiatique et de FOMO poussent l'idée que, à mesure que les agents deviennent plus courants, nous avons besoin d'un système pour gérer les identités des agents.

La réponse est : oui et non.

Oui, car nous introduisons une nouvelle couche entre les humains et les machines. Il existe de réels besoins pour :

• Gérer et identifier les agents
• Attribuer des identifiants uniques
• Suivre les journaux
• Auditer les actions (savoir si une tâche a été effectuée par un humain ou un agent)

Cependant, dans la plupart des cas techniques, il n'est pas nécessaire de créer un concept formel d'« Identité d'Agent ».

Agent ≠ Utilisateur, ≠ Compte de Service.

Derrière chaque agent, il y a toujours un utilisateur et l'identité de l'utilisateur est généralement suffisante.

Aujourd'hui, la plupart des agents :

• Agissent sur la base de l'autorisation de l'utilisateur (par exemple, jetons OAuth)
• Exécutent une logique ou effectuent un appel API
• Effectuent des tâches ponctuelles et de courte durée (sans besoin de suivi)

En ce sens, l'agent est juste une fonction-en-tant-qu'outil et n'a pas besoin d'un ID unique global.

Par exemple :

• Un agent GPT appelant votre API de calendrier a seulement besoin de l'accès que vous avez accordé.
• Un agent LangChain n'a pas besoin d'une identité tant qu'il peut appeler les bons outils, cela fonctionne.

Même avant l'IA, nous avions le concept d'authentification machine-à-machine (M2M).

M2M signifie échange de données automatisé entre services, sans intervention humaine dans la boucle.

Dans ce contexte, l'authentification utilise souvent une application cliente ou un compte de service.

Si vous voulez vraiment que votre agent ait une identité (pour audit, etc.), vous pouvez utiliser l'ID de l'application et cela suffit.

Vous devez toujours définir l'architecture de votre produit#

Cela n'a pas changé. Que votre produit implique ou non des agents, l'architecture de votre système d'identité dépend de qui sont vos utilisateurs et de la façon dont votre système interagit avec eux.

Si vous construisez un produit agentique à destination des consommateurs : Vous aurez besoin de méthodes de connexion légères (email, téléphone, connexion sociale) et d'un bassin d'utilisateurs unifié pour gérer les individus qui interagissent avec votre application et ses agents. Les agents agissent au nom de ces utilisateurs en utilisant des jetons délégués (par exemple, via OAuth).

Exemple :

Imaginez que vous construisez un assistant de planification IA, ou un bot de calendrier piloté par IA.

Chaque utilisateur se connecte avec son compte Google personnel. Votre système utilise OAuth pour obtenir la permission d'accéder à leur calendrier. L'agent n'a pas sa propre identité, il utilise le jeton de l'utilisateur pour planifier des réunions, vérifier les disponibilités ou envoyer des rappels. L'architecture d'identité est simple : un seul bassin d'utilisateurs global, stockage des jetons et suivi des consentements par utilisateur.

Si vous construisez une plateforme agentique B2B :

Vous devrez prendre en charge l'identité au niveau de l'organisation, pas seulement des utilisateurs individuels. Cela inclut :

1. SSO pour les clients entreprise
2. Séparation au niveau des espaces de travail ou des locataires
3. Politiques de délégation d'agents au niveau de l'organisation (par exemple, contrôler ce que les agents peuvent faire à travers les équipes)
4. Visibilité et journaux au niveau administratif pour toutes les activités des agents au nom des employés

Exemple :

Imaginez que vous construisez une plateforme qui fournit des agents IA pour automatiser des flux de travail internes - comme un bot d'analyse de sécurité qui surveille les journaux et envoie des alertes, ou un assistant de vente qui rédige des emails à partir de données CRM.

Chaque entreprise qui utilise votre plateforme veut :

1. Se connecter avec son SSO existant
2. Contrôler ce à quoi les agents peuvent accéder (par exemple, outils internes, systèmes de documents)
3. Voir quel agent a effectué quelle tâche, sous l'autorisation de quel employé

Dans ce cas, votre architecture d'identité doit prendre en charge un design multi-locataire, des permissions d'agents définies, et des politiques spécifiques à chaque organisation. Les agents agissent toujours au nom des utilisateurs, mais les permissions et les limites d'identité sont appliquées par locataire d'entreprise.

Dans les deux cas, le modèle d'identité définit comment les agents opèrent, à quoi ils peuvent accéder, et comment votre système assure la responsabilité.

Utilisez ce guide pour vous aider à planifier votre identité et l'architecture de votre produit.

https://docs.logto.io/introduction/plan-your-architecture/b2c

https://docs.logto.io/introduction/plan-your-architecture/b2b

Vous avez toujours besoin de couches de sécurité pour protéger vos applications alimentées par des agents#

Qu'il s'agisse d'une application agentique ou non, ces couches de sécurité fondamentales sont nécessaires pour protéger vos utilisateurs et systèmes :

• Authentification multi-facteurs (MFA)

  Empêche l'accès non autorisé même si les informations d'identification sont compromises.

  Exemple : Si un agent vous aide à effectuer une action à haut risque, comme effectuer une transaction ou modifier des paramètres d'identité, il devrait garder un humain dans la boucle et utiliser MFA pour confirmer l'action avant de procéder.

• CAPTCHA

  Bloque les abus automatisés comme le bourrage d'informations d'identification ou les inscriptions pilotées par bot.

  Exemple : Afficher un CAPTCHA après 3 tentatives de connexion échouées pour prévenir les attaques par force brute.

• Contrôle d'accès basé sur les rôles (RBAC)

  Assure que les utilisateurs et les agents n'accèdent qu'à ce qu'ils sont autorisés à voir.

  Exemple : Un assistant IA dans un espace de travail d'entreprise peut lire les événements du calendrier, mais ne peut pas accéder aux données de facturation sauf s'il lui est explicitement attribué un rôle supérieur.

• Connexion sans mot de passe

  Améliore l'expérience utilisateur et réduit le risque de mots de passe faibles.

  Exemple : Laisser les utilisateurs se connecter à l'aide d'un lien magique envoyé à leur email ou d'un message biométrique comme Face ID.

Ces fonctionnalités s'appliquent aussi bien aux applications traditionnelles qu'aux applications basées sur des agents, surtout lorsque les agents commencent à opérer à travers des données et des systèmes sensibles.

Ce qui a changé dans le monde agentique#

L'authentification est plus importante que jamais#

À mesure que les agents et les flux de travail multifacteurs émergent, nous voyons de nouveaux cas d'utilisation où les utilisateurs, les agents, les API et les serveurs MCP interagissent tous. Le nombre et la variété de ces scénarios croissent rapidement, bien plus qu'auparavant.

Chaque fois que ces connexions se produisent, l'autorisation devient plus visible que jamais. Les utilisateurs doivent donner un consentement clair, et les autorisations doivent être soigneusement gérées à travers les systèmes. C'est pourquoi tout le monde parle maintenant de garder un « humain dans la boucle » pour s'assurer que les utilisateurs ont suffisamment de contrôle et de visibilité sur ce que les agents peuvent faire, et sur les périmètres pour lesquels ils sont autorisés.

Votre application IA peut avoir besoin de s'intégrer à de nombreux services externes#

L'écosystème MCP s'étend, et cela signifie que votre application n'est plus juste un service autonome : c'est une partie d'un réseau plus large et connecté.

Pour fournir un contexte riche et utile aux LLMs, vos agents peuvent avoir besoin de :

• Accéder à plusieurs serveurs MCP

  Exemple : Imaginez un chef de projet IA qui récupère des mises à jour de tâches depuis Jira, la disponibilité de l'équipe depuis Google Calendar, et des données de ventes depuis Salesforce, et chacun de ceux-ci pourrait être alimenté par un serveur MCP différent. Pour générer un résumé hebdomadaire unique, l'agent doit interagir en toute sécurité avec plusieurs sources de données. C'est là que l'authentification et l'autorisation interviennent pour protéger chaque connexion et contrôler comment les données sont partagées.

• Se connecter à des API et des outils externes

  Exemple : Un agent de support client pourrait avoir besoin de récupérer l'historique des commandes depuis Shopify, de mettre à jour les tickets dans Zendesk, et de déclencher des flux de travail dans Slack. Sans intégrations, l'agent devient isolé et inefficace.

À mesure que les agents prennent plus de responsabilités, l'intégration devient la clé de l'utilité. Votre produit IA n'est pas seulement ce qu'il peut faire par lui-même, mais ce qu'il peut accéder, orchestrer, et raisonner dans un écosystème connecté. C'est pourquoi construire pour l'interopérabilité, de manière sécurisée et flexible, est plus important que jamais.

Vous devez embrasser les standards ouverts : OAuth/OIDC sont plus importants que jamais#

À l'ère de l'IA, le besoin d'intégrations sécurisées et flexibles est en croissance. Cela rend OAuth 2.0 et OIDC plus importants que jamais.

Principaux cas d'utilisation :

• Serveurs MCP distants : Permettez aux agents tiers d'accéder en toute sécurité à votre produit en utilisant des jetons délégués.
• Intégrations tierces : Permettez à d'autres outils ou agents de se connecter à votre application (par exemple, une plateforme de gestion de projet) sans avoir besoin de justificatifs bruts.
• Développement d'agents : Construisez des agents IA qui agissent en toute sécurité au nom des utilisateurs à travers les services.
• Appareils intelligents : Utilisez OAuth/OIDC pour des choses comme les preneurs de notes alimentés par l'IA pour authentifier les utilisateurs et se connecter au cloud - surtout avec une interface utilisateur minimale.

Ces protocoles fournissent un accès sécurisé, basé sur des jetons et consenti par l'utilisateur.

C'est crucial dans un monde de systèmes agentiques et connectés. Consultez cet article pour voir pourquoi OAuth et OIDC sont importants

Concevoir pour la confiance et l'échelle à l'ère des logiciels agentiques#

À mesure que les produits agentiques évoluent, les principes fondamentaux de l'identité et de l'autorisation restent les mêmes mais le contexte évolue. Les agents introduisent de nouvelles surfaces pour la délégation, le consentement, et l'accès. C'est pourquoi s'en tenir aux standards ouverts comme OAuth, construire une architecture claire, et appliquer de solides pratiques de sécurité ne sont pas seulement de bonnes pratiques, elles sont fondamentales. Concevoir avec soin maintenant signifie que votre système s'étendra avec confiance, flexibilité, et confiance dans un futur alimenté par l'IA.