La plupart des agents en production fonctionnent encore avec des moyens d’authentification rudimentaires : clés API partagées, comptes de service ou identifiants intégrés. Cela peut convenir à de petites flottes chargées de tâches non critiques, mais ne tient plus dès qu’une orchestration multi-agents intervient dans des paiements, des dossiers médicaux ou des infrastructures privilégiées. Lorsqu’un serveur MCP ou une base de données en aval reçoit une requête authentifiée par une clé, impossible de savoir quel agent ou quelle personne a demandé l’action. Les équipes finissent alors soit par accorder une confiance excessive, soit par tout verrouiller au point de bloquer les processus.
Agent Identity de TrueFoundry repense le problème : chaque agent devient une entité dotée d’un justificatif vérifiable, délivré par TrueFoundry ou adossé à votre fournisseur d’identité (IdP), comme Okta, Microsoft Entra, OIDC ou SPIFFE. Cette identité est indépendante de l’environnement d’exécution et de l’hébergement : les agents exécutés sur Bedrock AgentCore, Vertex AI, LangGraph ou des services personnalisés peuvent donc être gouvernés sans modification du code. La passerelle prend en charge le cycle de vie des jetons, leur mise en cache et leurs échanges, éliminant ainsi la gestion spécifique des jetons dans chaque implémentation d’agent.
Surtout, Agent Identity ne se contente pas d’identifier l’agent : la solution précise aussi pour qui il agit. La passerelle propose le transfert direct du jeton, les identifiants client OAuth2 (l’agent agit en son nom propre) et l’échange de jetons « au nom de » (OBO), qui associe le contexte de l’agent à celui de l’utilisateur dans un jeton destiné au système en aval. Le système de référence peut ainsi appliquer les permissions propres à chaque utilisateur lors de la dernière étape, sans devoir faire confiance au code intermédiaire ni dupliquer la logique d’authentification dans chaque agent.
Pour les équipes plateforme et sécurité, les avantages sont concrets et immédiats : des listes d’autorisation précises (qui peut appeler un agent), des permissions de sortie à portée limitée (modèles, serveurs MCP ou outils auxquels l’agent peut accéder), la révocation d’un accès sans effets collatéraux et des pistes d’audit de bout en bout attribuant les actions à l’agent et à l’utilisateur concerné. Ces capacités accélèrent la réponse aux incidents, limitent les déplacements latéraux en cas de compromission d’un agent et facilitent la conformité en reliant les actions à des identités clairement responsables.