Votre agent doit récupérer des données depuis Google Drive, publier un résumé sur Slack et créer un ticket Jira. Requête simple. Mais quelles credentials utilise-t-il ? Doit-il avoir le droit de supprimer tout votre dossier Drive ?

Ce problème d’autorisation tue les démos d’agents avant qu’ils atteignent la production. Ce n’est pas une question de connexion des utilisateurs à votre agent (LangGraph Platform s’en charge). C’est une question d’accès de votre agent à d’autres services au nom de ces utilisateurs.

Si vous développez de vrais agents, vous avez déjà heurté ce mur. La question n’est pas « Quiest cet agent ? » C’est :« Cet agent, agissant pour cet utilisateur, peut-il effectuer cette action sur cette ressource ? »

C’est précisément cette complexité d’autorisation qui nous a poussés à créer Arcade.dev. Mais commençons par bien cerner le tableau complet.

Auth utilisateur vs auth agent : deux problèmes distincts

Avant d’entrer dans le détail de l’auth agent, posons les deux défis clairement :

Authentification utilisateur (gérée par LangGraph Platform) Il s’agit de permettre aux utilisateurs de prouver leur identité pour accéder à votre agent. LangGraph Platform gère ça très bien.

# LangGraph Platform verifies user identity
@auth.authenticate
async def authenticate(headers: dict) -> Auth.types.MinimalUserDict:
    api_key = headers.get("x-api-key")
    if not is_valid_key(api_key):
        raise Auth.exceptions.HTTPException(status_code=401)

    return {
        "identity": "user-123",        # Who is this user?
        "is_authenticated": True       # Are they allowed in?
    }

Une fois authentifiés, les utilisateurs peuvent créer des threads, exécuter des agents et accéder aux ressources de l’agent. LangGraph Platform gère tout ça et rend l’identité utilisateur disponible partout dans votre agent via config[“configuration”][“langgraph_auth_user”].

Autorisation agent (gérée par Arcade) C’est là que ça se complique. Votre utilisateur authentifié demande à l’agent de « résumer les appels commerciaux de la semaine dernière depuis Google Drive et de les poster dans #sales-team sur Slack ». Votre agent doit alors :

  • Se connecter à Google Drive (avec quelles credentials ?)
  • Se connecter à Slack (avec quelles permissions ?)
  • Le faire en toute sécurité (sans accès à tout)
  • Au nom de l’utilisateur authentifié
  • Sans créer de failles de sécurité

C’est l’auth agent. Un problème radicalement différent.

Pourquoi « identité non-humaine » passe à côté du sujet

Les éditeurs de sécurité adorent les buzzwords. « Non-Human Identity » (NHI) est leur dernier en date. La réalité :les agents ne sont pas des identités : ce sont des applications qui agissent au nom des utilisateurs.

Votre agent est une application cliente qui a besoin d’un accès délégué. Il doit accéder aux services non pas comme un nouveau type d’identité spécial, mais comme une application agissant pour un utilisateur précis. Ces schémas existent depuis près de deux décennies dans OAuth.

La difficulté ne vient pas du fait que les agents sont particuliers. C’est que la complexité des autorisations explose dès qu’un agent accède à plusieurs services de façon dynamique.

Gardez en tête la vraie question :« Cet agent, agissant pour cet utilisateur, peut-il effectuer cette action sur cette ressource ? »

Pourquoi l’auth agent au niveau du tool est essentielle

Quand votre agent appelle un tool, c’est là que la sécurité compte vraiment. Vous ne pouvez pas faire confiance au jugement de l’agent sur ce qu’il devrait ou ne devrait pas pouvoir faire. Le contrôle d’autorisation doit intervenir au moment de l’action, avec le contexte suivant :

  • Quel agent fait la requête
  • Au nom de quel utilisateur (depuis LangGraph Platform)
  • Quelle action précise il tente d’effectuer
  • Sur quelle ressource précise
  • Avec quels paramètres

Les règles pour « cet agent peut-il envoyer ce message Slack » diffèrent de « cet agent peut-il supprimer ce fichier Drive ». C’est pourquoi l’auth agent est étroitement couplée à l’exécution du tool (là où l’action se produit).

Les deux approches naïves (et pourquoi elles échouent)

La plupart des équipes démarrent avec l’une de ces deux approches boiteuses :

Approche 1 : les comptes de service

« Créons un compte de service pour notre agent avec ses propres permissions ! »

Ça semble logique, surtout pour les systèmes RAG. Votre agent a besoin de documents internes, vous créez un compte de service avec accès en lecture à la base de connaissances. Simple, non ?

Les comptes de service fonctionnent bien pour les processus backend, mais ils sont surutilisés dans le développement d’agents faute d’alternatives.

Les comptes de service créent des failles de contournement. Imaginez que votre entreprise applique un accès basé sur les rôles aux documents. Les RH voient les données salariales, les ingénieurs voient la doc technique, les commerciaux voient les données clients. Mais votre agent RAG avec son compte de service voit tout ce à quoi on lui a donné accès. N’importe quel utilisateur peut alors interroger l’agent sur n’importe quel document, en contournant complètement vos contrôles d’accès existants.

C’est souvent pour ça que des agents qui épatent en démo n’atteignent jamais la production : les équipes sécurité (à juste titre) les bloquent dès que le risque de contournement est identifié.

L’alternative ? Des agents sévèrement bridés. Limitez les comptes de service aux informations publiques et votre agent devient une documentation glorifiée. Il récite votre FAQ mais échoue dès qu’on lui demande « Quel est le statut de ma commande ? », une question que les utilisateurs posent vraiment.

Approche 2 : les permissions complètes de l’utilisateur

« Bon, utilisons les credentials et permissions de l’utilisateur lui-même ! »

C’est plus sûr en théorie (les utilisateurs n’accèdent qu’à ce qu’ils ont déjà le droit de voir), mais en pratique, c’est extrêmement risqué.

J’ai vu Cursor tenter de supprimer mon répertoire racine. Heureusement, il n’avait pas les droits sudo. Mais voulez-vous vraiment que votre agent ait un accès complet à vos emails ? À tout votre Drive ? À votre base de données de production ?

Les utilisateurs ont peut-être le droit de supprimer des fichiers critiques ou d’envoyer des emails à toute l’entreprise. Ça ne signifie pas que leur agent doit hériter de ces permissions sans contrainte. Une hallucination ou une injection de prompt suffit pour provoquer la catastrophe. Les équipes sécurité appellent ça le « rayon d’impact ».

La bonne approche : autorisation juste-à-temps et moindre privilège

La solution repose sur trois principes clés :

1. Autorisation juste-à-tempsNe pré-autorisez pas tout à l’avance. Quand l’agent a besoin d’accéder à Slack, c’est à ce moment qu’on déclenche le flux OAuth. Les utilisateurs gardent le contrôle et n’autorisent que ce qui est nécessaire, quand c’est nécessaire.

2. Accès au moindre privilègeMême si un utilisateur peut supprimer des fichiers dans Drive, son agent ne devrait obtenir qu’un accès en lecture, sauf si la suppression est explicitement requise. Ça réduit le rayon d’impact en cas de problème. Définissez les scopes minimaux nécessaires pour chaque tool.

3. Contrôle contextuelChaque appel de tool doit faire l’objet d’une vérification d’autorisation. Cet agent précis, agissant pour cet utilisateur précis, peut-il effectuer cette action précise ? La réponse varie selon le contexte.

Complexité du monde réel

Ce que ça implique concrètement :

Gestion des tokensLes tokens OAuth expirent. Ils doivent être renouvelés. Chaque service a sa propre durée de vie. Votre agent peut être en pleine conversation quand un token expire. Il faut gérer les flux de rafraîchissement sans casser l’expérience utilisateur.

Problèmes à l’échelleVous avez besoin de tokens distincts pour chaque combinaison utilisateur × service × agent. L’utilisateur A qui utilise votre agent commercial pour accéder à Slack a besoin d’un token différent de l’utilisateur A qui utilise votre agent support. Montez à 100 utilisateurs, 10 services et 5 agents, et vous gérez 5 000 relations de tokens distinctes.

Autorisation dynamique des toolsNe forcez pas les utilisateurs à pré-autoriser chaque service dès le départ : ils abandonneront après 2-3 étapes d’auth. Gérez plutôt OAuth juste-à-temps dans votre boucle agent. L’utilisateur demande des données commerciales ? C’est là que vous demandez l’accès à Salesforce.

Granularité des scopesSlack seul dispose de dizaines de scopes OAuth. Votre agent a-t-il besoin de chat:write ou chat:write.public ? Et files:read vs files:write ? Une erreur ici, et votre agent ne fonctionne plus ou dispose de trop de droits.

Comment les développeurs LangGraph peuvent résoudre ça

Vous vous êtes lancé dans le développement d’agents pour créer des workflows intelligents, pas pour gérer des tokens OAuth. L’écosystème LangChain vous donne l’essentiel : LangGraph pour l’orchestration des agents, LangGraph Platform pour l’hébergement et la scalabilité, LangSmith pour l’observabilité.

Mais il manque quelque chose : la couche d’autorisation des tools.

Pour combler ce manque, il faudrait construire des flux OAuth pour chaque service (avec leurs bizarreries respectives malgré OAuth qui se veut un « standard »). La gestion des tokens entre utilisateurs et services. Les politiques d’autorisation. La logique de rafraîchissement. Les contrôles de sécurité.

Beaucoup d’équipes s’y lancent. Des mois plus tard, elles débuggent encore des cas limites OAuth au lieu de livrer des agents.

Ou vous pouvez utiliser Arcade.

La réalité de l’implémentation

Pour implémenter vous-même une autorisation juste-à-temps correcte, il faudrait construire :

  • Gestion des flux OAuth (initiation, callbacks, gestion d’état)
  • Gestion du cycle de vie des tokens pour toutes les combinaisons utilisateur/agent/service
  • Application des politiques d’autorisation au niveau du tool
  • Logique de rafraîchissement des tokens sans casser l’exécution de l’agent
  • Gestion des erreurs pour les tokens expirés ou révoqués
  • Journalisation des audits pour la conformité

Des milliers de lignes d’infrastructure complexe avant même d’aborder la logique de votre agent.

Voici à quoi ressemble la même fonctionnalité avec Arcade :

# Get the authenticated user from LangGraph Platform
user_id = config["configuration"]["langgraph_auth_user"]["identity"]

# All the complexity above, handled by Arcade
result = arcade_client.tools.execute(
    tool_name="Slack.SendMessage",
    input={
        "channel": "#general",
        "message": "Hello World!"
    },
    user_id=user_id  # Who the agent is acting for
)

Ce qui se passe en coulisses :

  1. LangGraph Platforma déjà authentifié l’utilisateur
  2. Votre agentenvoie la requête à Arcade
  3. Arcadevérifie si votre agent dispose de tokens OAuth valides pour Slack pour cet utilisateur
  4. Sinon,Arcadedéclenche le flux OAuth (dans votre boucle agent)
  5. Votre agents’authentifie auprès de Slack avec des scopes limités
  6. Arcadeexécute l’action avec les autorisations appropriées et la journalise
  7. Arcadegère ces tokens pour les utilisations futures

Vous pouvez utiliser des tools préconstruits depuis notre bibliothèque ou créer les vôtres avec notre Tool Development Kit. Vous configurez les tools. Arcade garantit le moindre privilège. Vos utilisateurs gardent le contrôle. Votre agent reste fonctionnel. Vos équipes sécurité restent satisfaites.

Conçu pour fonctionner parfaitement avec l’ensemble de l’écosystème LangChain.

En résumé

L’auth agent concerne la façon dont votre agent accède à d’autres services au nom des utilisateurs. C’est lié à l’auth utilisateur, mais distinct : l’auth utilisateur porte sur la façon dont les utilisateurs accèdent à l’agent.

Les approches naïves (comptes de service et credentials utilisateur complets) créent des failles de sécurité ou des angles morts. La bonne approche utilise une authentification agent basée sur OAuth, avec accès juste-à-temps et moindre privilège.

Arcade et LangGraph Platform gèrent cette complexité pour les développeurs, permettant à vos agents LangGraph d’accéder en toute sécurité aux services internes et externes tout en laissant les utilisateurs authentifiés aux commandes.

Commencez à construire des agents sécurisés dès aujourd’hui

Votre prochaine étape :Ajoutez un accès externe sécurisé à votre agent LangGraph en moins de 10 minutes.

  1. Partez de votre agent LangGraph existant (avec l’auth utilisateur LangGraph Platform déjà configurée)
  2. Créez un compte sur Arcade sur arcade.dev sans carte bancaire
  3. Suivez notre guide d’intégration LangGraph pour ajouter Arcade à votre agent
  4. Ajoutez votre premier tool (nous recommandons de commencer par Slack ou Google Drive)
  5. Testez le flux OAuth regardez votre agent s’authentifier correctement auprès des services externes

Prêt à livrer des agents sécurisés ?

Arrêtez de construire de l’infrastructure OAuth. Commencez à construire des agents qui fonctionnent vraiment.

Démarrer gratuitement →

Vous utilisez déjà LangGraph ? Notre guide LangGraph prend 10 minutes.