Les systèmes agentiques sont des applications dans lesquelles des agents autonomes planifient, raisonnent et agissent à travers plusieurs services. Ces applications sont conçues pour aller au-delà des simples interactions requête/réponse.
Contrairement aux microservices traditionnels basés sur l'API, qui dépendent du schéma de la charge utile de la requête et interprètent les requêtes de manière syntaxique, les applications agentiques utilisent de grands modèles linguistiques (LLM) pour interpréter les requêtes de manière sémantique. Cela leur permet de planifier des tâches en plusieurs étapes, d'enchaîner des actions et d'invoquer plusieurs services de manière autonome au nom d'un utilisateur.
À mesure que ces systèmes évoluent, ils ressemblent de plus en plus à des applications distribuées composées d'agents faiblement couplés, de services et d'API externes fonctionnant de concert. Cette flexibilité accrue s'accompagne d'une plus grande complexité et de la nécessité d'une approche cohérente et sécurisée de l'identité.
Problèmes de sécurité posés par les systèmes agentiques
Un défi central dans ces environnements est la propagation de l'identité, garantissant que l'identité et l'intention d'un utilisateur peuvent être transmises en toute sécurité à travers les agents, les services et les outils. Sans une authentification et une autorisation fortes, un agent pourrait invoquer un service sans le bon contexte, outrepasser ses privilèges ou contourner les politiques d’entreprise.
Okta Cross-App Access fournit un moyen standard d'échanger des jetons d'identité entre les applications. Combinées au Model Context Protocol (MCP), qui donne aux agents un moyen cohérent de découvrir et d'appeler des outils, ces capacités créent un tissu de confiance qui lie les utilisateurs, les agents et les services.
Les sections suivantes illustrent un exemple d’architecture pour l’intégration d’Okta Cross-App Access avec des agents d’IA exécutés sur les services sans serveur d’Amazon Web Services (AWS), comme AWS Lambda ou Amazon Elastic Container Service, afin de résoudre ces problèmes. Vous verrez comment un utilisateur s’authentifie auprès d’Okta, comment son identité est propagée par les agents via l’échange de jetons et comment les services en aval valident et appliquent l’accès.
En combinant la plateforme d'identité d'entreprise d'Okta avec les services sans serveur et de conteneur d'AWS, les organisations peuvent permettre une collaboration sécurisée entre agents et entre agents et services à grande échelle.
Architecture de la solution
Cette section décrit un exemple de conception de bout en bout qui lie l'identité Okta aux appels agent-service sur AWS, avec MCP fournissant un protocole cohérent pour que les agents découvrent et invoquent des outils. Vous verrez les principaux composants, le flux de jetons et comment l'identité est propagée et appliquée à chaque étape.
Flux d’authentification et d’autorisation
L'architecture échantillon commence par un utilisateur interagissant avec une application client agentique, telle qu'une interface Web ou de bureau. Le client s'intègre à Okta en utilisant OpenID Connect (OIDC) pour gérer l'authentification. Une fois connecté, le client reçoit un jeton d'identification qui représente l'identité de l'utilisateur. Plutôt que d'utiliser directement ce jeton pour les appels en aval, le client utilise le SDK Cross-App Access (XAA) pour l'échanger contre une Identity Assertion Grant (ID-JAG), qui est lié à une audience en aval spécifique. Cela établit les bases d'une propagation sécurisée de l'identité à travers les applications.
L’ID-JAG est ensuite présenté à un service d’autorisation exécuté sur AWS, comme illustré dans le diagramme précédent. Ce service vérifie l’assertion et émet un jeton d’accès de courte durée et limité à l’audience. Ce jeton est spécifiquement limité à la ressource que l’agent doit appeler. En introduisant cette étape, vous pouvez appliquer des limites de confiance claires et garantir un accès minimal aux services en aval.
Avec le jeton d'accès en main, l'agent peut appeler des outils et des ressources hébergés sur des serveurs MCP. Chaque serveur MCP valide le jeton entrant avant d'effectuer toute action. Ces outils et ressources peuvent, à leur tour, appeler des ressources protégées en aval, telles que des API de service. Dans le cas où ces services s'exécutent sur AWS, ils peuvent appliquer leurs propres politiques, en s'appuyant sur les rôles IAM et en validant les revendications de jetons telles que l'identité de l'utilisateur, la portée et le locataire. Cette application en couches garantit que l'identité, l'intention et l'autorisation sont véhiculées de manière cohérente de l'utilisateur jusqu'aux systèmes dorsaux.
Considérations et meilleures pratiques
Lors de la création d'applications agentiques sécurisées, les équipes d'ingénierie doivent adopter des contrôles de sécurité rigoureux et des meilleures pratiques éprouvées. Les principes suivants fournissent une base solide pour la création sécurisée de systèmes agentiques et de serveurs MCP.
Validation de l'identité
Validez l'identité à chaque limite. Chaque agent d'IA et serveur MCP doit vérifier indépendamment les jetons d'accès, en vérifiant l'émetteur, l'audience, la portée, la signature et l'expiration. Ne vous fiez jamais uniquement à la validation en amont ; cela garantit que les agents ne peuvent pas contourner l'application en enchaînant les appels.
Gestion des jetons
Utilisez des jetons à durée de vie courte et délimités. Suivez toujours le principe du moindre privilège et limitez la portée des jetons aux autorisations minimales requises. Les jetons d'accès émis pour les agents doivent être valides pour une courte période seulement (minutes, pas heures) et liés à des outils MCP spécifiques (par exemple, documents.read vs. documents.write). Si un agent doit invoquer un autre outil, effectuez un échange de jetons pour émettre un nouveau jeton avec une portée plus étroite.
Propagation du contexte
Propager le contexte utilisateur en toute sécurité. Utilisez Okta Cross‑App Access pour transporter l'identité entre les services. Lorsque les agents invoquent des serveurs MCP, incluez des revendications telles que le sujet, l'utilisateur final (sub), la partie autorisée (azp), l'audience (aud) et l'action pour suivre l'exécution au nom de. Cela garantit que les services en aval peuvent appliquer des politiques en sachant qui a lancé la demande et pourquoi elle a été faite.
Observabilité et audit
Vérifiez et suivez les chaînes d'agents de bout en bout. Enregistrez les événements structurés et les décisions d'autorisation à chaque segment, en indiquant la trace complète de l'acteur (par exemple : utilisateur → agent → outil MCP), les étendues utilisées et les décisions prises. Utilisez des services d'observabilité tels que Amazon CloudWatch et AWS X-Ray pour suivre les requêtes à travers plusieurs agents et outils, afin de répondre à des questions telles que : « Qui a demandé à l'agent d'agir ? » Quel outil a été invoqué ? À quelles données a-t-on accédé ?
Meilleures pratiques spécifiques à AWS
- Rôles IAM: Utilisez les permissions minimales requises pour les rôles d'exécution des fonctions Lambda. Évitez de réutiliser les rôles d'exécution sur plusieurs fonctions.
- Passerelle API : Utilisez les autorisations Lambda pour protéger vos API. Activez CORS, la limitation du débit et WAF. Envisagez mTLS lors de la communication entre les composants du système.
- CloudWatch : Utilisez-le pour la journalisation centralisée avec des politiques de rétention, des métriques opérationnelles et commerciales, et un traçage de bout en bout.
- Configuration VPC : envisagez d’utiliser VPC pour un isolement réseau supplémentaire si nécessaire.
Les applications agentiques ouvrent la porte à de nouvelles façons d’automatiser les tâches et de connecter les services, mais elles introduisent également de nouvelles considérations de sécurité. Chaque agent et serveur MCP doit fonctionner avec le bon contexte utilisateur, appliquer le moindre privilège et laisser une piste d’audit claire. Sans des bases solides en matière d’authentification, d’autorisation et de propagation d’identité, ces systèmes peuvent rapidement devenir ingérables ou dangereux.
En combinant les solutions d'accès multi-applications et d'identité d'Okta avec les services sans serveur et conteneurs d'AWS, les organisations peuvent créer des systèmes agentiques qui évoluent en toute sécurité. L'approche décrite dans cet article montre comment authentifier les utilisateurs, propager leur identité via des agents, émettre des jetons délimités pour les outils MCP et appliquer la politique à chaque limite.
Le déploiement de vos agents d'IA à l'aide des technologies sans serveur d'AWS offre plusieurs avantages :
- Évolutivité et fiabilité : Vos charges de travail sont automatiquement distribuées sur plusieurs zones de disponibilité et s'adaptent de manière autonome en fonction des schémas de trafic.
- Optimisation des coûts : Modèle de tarification à l'utilisation ; vous ne payez que ce que vous utilisez.
- Infrastructure gérée : AWS gère entièrement la gestion de l'infrastructure pour vous, y compris les opérations, la sécurité et la résilience.
- Intégration : Intégrations natives avec une multitude de services AWS.
- Observabilité intégrée : Surveillance complète avec CloudWatch et X-Ray.
Pour en savoir plus, explorez la documentation Okta Cross-App Access et les services AWS serverless.
Ressources
- Okta Cross-App Access
- Spécification MCP
- Documentation AWS Lambda
- Documentation AWS SAM
- Documentation de la passerelle API
