Sécurisation de l’entreprise agentique : Le plan d’action dans la pratique

Les agents sont performants. Ils constituent également une surface d’attaque.

Un agent d’IA n’est utile que si vous lui donnez accès à vos systèmes. Les agents utiles approuvent des remboursements, enregistrent des transactions et modifient des dossiers clients dans les systèmes que vous protégez avec le plus grand soin, accessibles via des connecteurs SaaS, des serveurs Model Context Protocol (MCP) et des API. 

Pour agir, un agent doit avoir la confiance de systèmes qu’il n’a jamais rencontrés, pour le compte d’autrui, sans qu’aucun humain n’observe le moment où il prend sa décision. Un seul agent sous supervision est facile à comprendre et à contrôler (Figure 1). 

Les difficultés apparaissent lorsque les agents passent de la phase pilote à la production et que l’adoption se généralise dans l’entreprise. Une connexion supervisée se transforme en milliers de connexions non supervisées. L’autorité accordée à chacun est définie une seule fois et de manière large, ce qui entraîne une gestion très compliquée des accès (Figure 2).

Un agent. D’innombrables outils et ressources.

Chaque lien donne accès à vos données clients, à votre propriété intellectuelle et aux systèmes opérationnels qui font fonctionner votre entreprise.

Utilisateurs × agents × conversations × outils = Chaos des accès

Chaque lien représente une surface d’attaque. L’autorisation doit gouverner chacun de ces liens, à chaque appel, à la vitesse des machines.

Ce chaos ressemble à une menace pour la sécurité, mais qui ne se manifeste pas de la manière habituelle. Les agents ne s’introduisent pas par effraction. Ils sont créés, connectés ou reçoivent des droits d’accès, et lorsque le trafic atteint un pare-feu, l’agent se trouve déjà à l’intérieur.

La vraie question : que se passe-t-il ensuite ? 

• De quel agent s’agit‑il ?
• Qui l’a autorisé ?
• Jusqu’où peut-il aller ? 
• Que peut‑il faire sur cette tâche ? 
• Comment révoquer son accès ?

Il s’agit de questions d’identité et d’autorisation, et bien que des périmètres généraux puissent être prédéfinis, il n’est pas possible d’y répondre à l’avance ; des décisions spécifiques à chaque tâche doivent être prises à l’exécution. L’autorité d’un agent doit être déterminée au moment de l’action, en fonction à la fois de l’identité humaine et de celle de l’agent. Cela garantit que l’autorisation est précisément adaptée à la tâche et que la personne responsable est associée à chaque demande. Ce principe fondamental est le socle de toute l’architecture.

Le plan d’action pour la sécurité existe. Mais pas le budget.

Le changement est déjà perceptible à l’avant-garde. Uber a récemment publié un rapport détaillé expliquant comment l’entreprise a attribué une véritable identité aux agents, en adoptant une identité d’agent cryptographique et un échange de tokens à chaque étape, permettant de transmettre la chaîne d’acteurs de l’utilisateur jusqu’à l’outil. C’est une belle preuve de la réalité du problème et qu’il est possible de connaître l’architecture. Mais il faut pour cela une équipe d’ingénierie créée et gérée en interne que la plupart des entreprises n’auront jamais. 

La leçon à retenir concerne les standards : une couche d’identités pour les agents n’est pertinente que si elle traverse les frontières entre fournisseurs et SaaS que les agents franchissent en permanence. Elle doit donc être conçue selon des standards cohérents, appliqués de manière uniforme par toutes les parties, et proposée comme une couche, et non développée séparément pour chaque entreprise. Okta for IA Agents fonctionne ainsi.

Comment Okta securise l’entreprise agentique

Okta for AI Agents transforme ce principe en couche opérationnelle : une identité vérifiable pour chaque agent, une autorisation décidée au moment de l’action et l’humain responsable identifié tout au long de la chaîne. La suite de cet article présente l’architecture en l’illustrant avec une entreprise.

Une implémentation type d’entreprise agentique 

Prenons l’exemple de Streamward Inc., une entreprise fictive représentative des clients avec lesquels nous collaborons. Un utilisateur formule une demande via un assistant conversationnel, et un orchestrateur principal d’agent analyse l’intention puis délègue les sous-tâches au sein du maillage selon les capacités métier (Figure 3). Pour accéder aux systèmes en aval, aux API propriétaires et aux services tiers, les agents utilisent différents types de ressources à l’exécution : serveurs MCP, points de terminaison REST régis par des spécifications OpenAPI et entrepôts de données cloud natifs.

Exemple d’architecture avec maillage multi‑agents

• Salesforce Agentforce : gère l’analyse du pipeline CRM, l’analyse des leads et la recherche de comptes.
  • Serveur MCP connecté : il compare les identifiants de compte Salesforce aux données de facturation en temps réel via un serveur MCP ERP d’entreprise, en appelant get_customer_payment_history.
• Amazon Bedrock AgentCore : exécute la RAG (Retrieval Augmented Generation) sur les connaissances de l’entreprise.
  • Serveur MCP connecté : se connecte à une base de données vectorielle AWS Aurora PostgreSQL via MCP pour effectuer des recherches sémantiques, en appelant query_knowledge_base et fetch_unstructured_contract_pdf.
• Google Vertex AI : exécutions low-code pour automatiser les workflows clients.
  • Gateway OpenAPI connecté : achemine les appels via un gateway Workday et ServiceNow compatible OpenAPI, en appelant read_latest_incident_tickets et en déclenchant create_workday_expense_claim.

Les quatre principales failles de sécurité dans l’implémentation

Nous allons maintenant suivre une requête ordinaire à travers ce maillage afin de mettre en évidence les failles de sécurité courantes : une consultation de la base de connaissances de l’entreprise qui doit accéder à la base de données. Sans une structure d’identité centralisée, cela présente quatre faiblesses, comme l’illustre le token porté par l’agent (Figure 4). La faille se trouve dans ce qui manque au token.

Shadow AI

Les agents internes ou tiers exécutés dans Amazon Bedrock AgentCore sont souvent configurés ou déployés par des équipes sans être enregistrés via le fournisseur d’identité (IdP). Comme un kit SDK de sécurité n’est pas injecté dans ces environnements, les agents se lancent dynamiquement et se connectent aux ressources internes à la périphérie des politiques d’accès de l’entreprise. Leurs tokens bruts indiquent un client machine, mais ne comportent pas de déclaration iss (émetteur), aucun humain validateur, et aucun propriétaire responsable de leur cycle de vie. Vous ne pouvez tout simplement pas gouverner un agent Bedrock que vous n’avez jamais émis.

Accès à privilèges excessifs 

La déclaration scope dans le token d’un agent non géré représente un risque excessif. Pour permettre à l’agent Bedrock de se connecter à la base de données cible sans interrompre en permanence le flux d’exécution pour se réauthentifier à chaque limite de système, les développeurs ont tendance à attribuer à l’agent un compte de service étendu à longue durée de vie. Le périmètre du token englobe une surface administrative permanente et large, bien supérieure à ce qu’exige une requête textuelle spécifique. Chaque périmètre excessif crée une voie d’accès vulnérable à l’injection de prompt ou à l’exfiltration de données, mais la révocation de l’agent interrompt tous les autres workflows automatisés utilisant ce même compte de service.

Attribution d’identité et délégation

Lorsque la recherche passe de Bedrock AgentCore au serveur cible Aurora DB MCP, l’identité se réduit entièrement à un principal machine générique. Le moteur de base de données enregistre l’appel d’un compte de service à query_knowledge_base(), sans indiquer l’identité de l’opérateur humain à l’origine de la tâche ni celle du sous-agent spécifique exécutant la requête. Sans filiation de délégation cryptographique à l’intérieur du token, la frontière de la ressource ne peut pas appliquer les autorisations de données au niveau utilisateur, ce qui entraîne une suppression complète de l’identité et une rupture de la piste d’audit.

Aucune gouvernance

Lorsque l’agent déclenche une invocation d’outil ou une lecture de base de données inattendue, le token de machine non gérée ne contient ni l’identité de la transaction ni le contexte du consentement humain. L’action s’exécute de manière fluide, sans pause de l’exécution pour approbation, laissant les équipes sécurité totalement dans l’ignorance. Par la suite, il devient impossible d’établir un lien cryptographique entre la transaction automatisée et un responsable humain, ce qui signifie qu’il n’est pas possible de prouver légalement qui a autorisé tel ou tel transfert de données.

La plupart des entreprises corrigent un ou deux de ces éléments.

Les quatre principales failles de sécurité observées dans le token

Gardez cette demande en mémoire. L’exemple détaillé présenté plus loin dans cet article montre l’agent Agentcore accédant à l’outil Aurora DB MCP, cette fois avec Okta dans le parcours, et réussissant sans rencontrer aucune des quatre erreurs.

Okta for AI Agents corrige les failles de sécurité 

Okta transforme la zone de confiance en une couche de gouvernance intégrée au chemin d’exécution (Figure 5). Streamward achemine tout le trafic MCP via un Runtime Agent Gateway en ligne, le point d’application de la politique (PEP), avec Okta comme point de décision de la politique (PDP) en arrière-plan. L’agent ne détient jamais d’identifiant brut pour les outils MCP. Voici le concept du point de contrôle concrétisé : chaque requête s’arrête à un point qui connaît les identités concernées et détermine, à l’instant, ce qui est autorisé.

Exemple d’architecture maillée multi‑agents avec Okta for IA Agents

Le flux d’accès sécurisé, étape par étape

La requête finale adressée à tout outil backend comprend une identité vérifiable qui intègre à la fois le contexte humain (la déclaration sub) et le principal de la charge de travail agent (la déclaration act). 

Voici la même requête à la base de connaissances que précédemment, cette fois exécutée via Okta. Le schéma ci-dessous en retrace l’ensemble du processus, et les étapes suivantes détaillent chaque phase, en montrant comment le token est construit et échangé tout au long du parcours (Figure 6).

Flux d’accès sécurisé de bout en bout

La requête finale adressée à tout outil backend comprend une identité vérifiable qui intègre à la fois le contexte humain (la déclaration sub) et le principal de la charge de travail agent (la déclaration act). 

Étape 1 : Utilisateur humain vers le front-end

L’utilisateur se connecte au portail de Streamward via un flux OpenID Connect (OIDC), et Okta émet un token d’accès utilisateur standard.

Étape 2 : frontend vers l’orchestrateur

Le frontend traite le prompt en langage naturel et transmet le contexte de la tâche à l’orchestrateur principal d’agent, en transportant le token d’accès utilisateur en tant que token au porteur.

Étape 3 : orchestrateur vers Okta, échange A2A

L’orchestrateur détermine que la tâche nécessite un traitement analytique dans Bedrock AgentCore via l’agent Corp-Knowledge-Agent. Il transmet le token utilisateur et le champ d’application demandé au terminal de token d’Okta (/oauth2/v1/token) et lance le flux Cross-App Access (XAA) (Identity Assertion Authorization Grant). Okta évalue la politique d’accès de l’agent et renvoie un token ID-JAG à usage unique et de courte durée (urn:ietf:params:oauth:token-type:id-jag), restreint à la tâche.

Étape 4 : orchestrateur vers Okta, échange de tokens

L’orchestrateur crée une assertion client avec la clé privée de l’orchestrateur et échange le token ID-JAG au serveur d’autorisation personnalisé attribué à l’agent Agentcore cible. Okta évalue la politique d’accès utilisateur à cet endroit et renvoie un token d’accès limité destiné à l’agent Corp-Knowledge-Agent.

Étape 5 : outil d’orchestration vers Bedrock AgentCore

L’outil d’orchestration transmet le token limité dans le cadre de l’appel agent à agent (A2A) effectif à l’agent Agentcore Corp-Knowledge-Agent. AgentCore vérifie le token et autorise la poursuite de l’appel dans le contexte de l’agent orchestrateur et de l’identité humaine initiatrice.

Étape 6 : AgentCore vers le gateway

Corp-Knowledge-Agent invoque l’outil query_knowledge_base sur le serveur Aurora DB MCP via le gateway, en transmettant le token entrant et l’autorisation souhaitée (champ d’application) pour l’outil sortant.

Étape 7 : gateway vers Okta, Cross-App Access 

Le gateway initie de nouveau le flux XAA, en soumettant le token entrant et le champ d’application demandé au terminal de token d’Okta (/oauth2/v1/token). Okta évalue la politique d’accès de l’agent et renvoie un token ID-JAG à usage unique et de courte durée, restreint à la tâche.

Étape 8 : gateway vers Okta, échange de tokens 

Le gateway crée une assertion de client avec la clé privée de l’Agentcore Corp-Knowledge-Agent et échange le token ID-JAG auprès du serveur d’autorisation personnalisé attribué au serveur Aurora DB MCP cible. Okta évalue la politique d’accès de l’utilisateur à cet endroit et renvoie un token d’accès limité destiné au serveur MCP.

L’outil final reçoit une demande qu’il peut attribuer de manière complète : qui est la personne, quel agent est intervenu, son champ d’application, ainsi qu’une déclaration de traçabilité (act) qui relie l’ensemble de la chaîne à un seul enregistrement. L’autorité était déterminée à l’exécution, limitée à la tâche, et jamais dissociée de la personne qui en était responsable.

Les quatre principales failles de sécurité résolues par l’architecture

En orientant le flux d’exécution de Bedrock AgentCore via cette architecture standardisée, Streamward neutralise efficacement les quatre erreurs d’identité courantes qui compromettent les configurations d’agent non gérées :

Remédier à la Shadow AI 

Au lieu de permettre à Bedrock Corp-Knowledge-Agent de circuler sans contrôle dans le fournisseur d’identité central sans émetteur vérifiable, l’agent est enregistré directement dans Universal Directory en tant que principal de charge de travail distinct. La gouvernance IT conserve une propriété clairement définie sur son cycle de vie et une visibilité sur ses connexions réseau.

Remédier aux accès à privilèges excessifs 

Au lieu de fonctionner avec un compte de service large et permanent doté d’autorisations persistantes qui exposent l’ensemble de la couche de base de données aux risques d’attaques par injection de prompt, l’agent reçoit un token à durée de vie limitée, généré dynamiquement lors de l’exécution. Ses champs d’application sont croisés de manière mathématique et réduits strictement à l’opération unique sur la base de données requise pour ce bloc d’exécution spécifique (Aurora-DB:read).

Empêcher l’usurpation d’identité 

En intégrant directement la chaîne de délégation et ses étapes act dans le contexte du token, l’identité ne se réduit pas à un identifiant machine générique. La limite de ressource permet de suivre précisément la traçabilité de la garde, en empêchant l’effacement de l’identité et en appliquant les contrôles de données conformément aux véritables autorisations de la personne à l’origine de l’action.

Appliquer la gouvernance

Chaque étape de l’échange de tokens génère des événements explicites et structurés (app.oauth2.token.grant.id_jag) liés à un identifiant de transaction immuable. Cet historique d’audit permanent fournit aux équipes de conformité et de résolution des incidents la preuve de l’identité de la personne ayant autorisé chaque action automatisée.

Les composants Okta for IA Agents

Examinons les composants Okta for AI Agents impliqués dans la solution ci-dessus.

Registre et découverte des agents  

Ce composant transforme des agents autonomes inconnus en principaux de charge de travail connus et vérifiables en les enregistrant dans Universal Directory, où chacun se voit attribuer un cycle de vie, un propriétaire humain identifié et une place dans la politique. 

Comme les agents non gérés apparaissent plus rapidement qu’ils ne peuvent être enregistrés manuellement, Identity Security Posture Management (ISPM) les détecte dans l’ensemble des environnements cloud et des réseaux MCP, y compris les agents no-code qui resteraient autrement invisibles, et associe chacun d’eux à un propriétaire. Un agent que vous ne pouvez pas voir est un agent auquel vous ne pouvez pas attribuer d’autorisation ni de responsabilité.

Onboarding automatique des agents

Les agents développés sur Salesforce, AWS, Microsoft et ServiceNow sont importés directement dans Universal Directory, ce qui permet au registre de rester synchronisé avec leur apparition.

Cross App Access 

XAA utilise l’Identity Assertion Authorization Grant afin d’éviter la suppression de l’identité lors de parcours multi-étapes. Au lieu qu’un agent agisse en tant que compte de service anonyme, l’humain (la déclaration sub) et l’agent (la déclaration act) circulent tous deux dans le token (Figure 7), produisant une déclaration d’acteur qui constitue une chaîne plutôt qu’un seul principal. XAA permet de maintenir le lien entre l’autorisation et une personne réelle lorsque la demande franchit les frontières entre fournisseurs.

Le flux XAA

Consentement intermédiaire

Pour un premier accès agent à SaaS au nom d’un utilisateur, le service d’émission de tokens sécurisé (STS) d’Okta gère le consentement de manière dynamique. L’agent marque une pause pendant que l’utilisateur autorise l’accès une seule fois, hors bande, avant que l’appel ne se poursuive. Le consentement est établi au niveau de la couche d’identités plutôt qu’intégré à chaque agent, de sorte que même un agent que vous ne pouvez pas modifier bénéficie de ce contrôle.

Autorisation entre agents  

Dans un maillage d’agents, Okta intervient à chaque transfert. Une seule étape permet de configurer la connexion entre deux agents (Figure 8), et l’autorisation effective correspond à l’intersection des droits de l’utilisateur et de ceux de l’agent appelant, ce qui signifie qu’un sous-agent ne dépasse jamais la combinaison du moindre privilège. La déclaration actor imbriquée s’étend de l’utilisateur humain à chaque agent jusqu’au service final, avec une autorité contrôlée par les politiques à chaque étape et en maintenant la personne responsable dans la chaîne.

Configuration de la connexion de ressource agent à agent dans Okta

Audit centralisé

Étant donné qu’un agent n’est pas une personne morale et ne peut pas répondre de ses actions, la personne responsable doit pouvoir être identifiée au bout de chaque chaîne. Une piste consigne chaque transaction avec des événements d’octroi explicites qui attestent de l’identité de l’auteur et de la personne représentée (Figure 9) ; il s’agit du registre qu’un régulateur, un tribunal ou un conseil d’administration demandera.

Okta System Log pour l’audit centralisé

Contrôle sécurisé à l’exécution

Okta déploie le Runtime Agent Gateway en ligne comme point central d’application des politiques (PEP) devant les ressources en aval, Okta jouant le rôle de point de décision des politiques (PDP) pour chaque requête (Figure 10).

Le Runtime Agent Gateway

• Serveur MCP virtuel : le gateway se présente comme un serveur MCP permettant aux organisations de sécuriser les agents low-code et no-code qui accèdent aux ressources de l’entreprise sans que ces agents aient besoin de communiquer nativement avec l’échange de tokens.
• Isolation des identifiants : le gateway masque les jetons XAA de courte durée et les jetons SaaS intermédiaires de plus longue durée, de sorte que ces identifiants de ressource ne sont jamais exposés aux agents.
• Sécurité des appels d’outils en ligne : les plateformes low-code acheminent chaque appel d’outil sortant via le gateway, qui intercepte l’appel, vérifie la relation à l’aide de politiques granulaires à la vitesse du réseau, puis injecte un secret backend à durée de vie limitée en périphérie avant l’exécution. Le token qu’il émet est généré au moment de la demande, limité à la tâche, destiné à l’audience et révocable en quelques secondes. C’est l’inverse des identifiants permanents pouvant être retrouvés dans un fichier et réutilisés.

Prochaines étapes : fonctionnalités avancées d’Okta for IA Agents

Ce que cette architecture offre aujourd’hui constitue le socle : chaque agent dispose d’une identité vérifiable, et son autorité est déterminée à l’exécution et limitée à la tâche. 

La première phase d’un arrêt d’urgence (kill switch) global est déjà en place, avec le Shared Signals Framework (SSF) pour transformer un signal de risque en révocation, qui s’étendra à une interruption coordonnée et en temps réel sur l’ensemble des systèmes connectés, un contrôle que les tokens à durée de vie limitée ne peuvent pas offrir seuls.

Ensuite, c’est le même principe de plan de contrôle étendu aux aspects de la vie d’un agent encore non couverts : les questions que les équipes de gouvernance posent déjà concernant l’accès humain, sont désormais posées aux agents.

• Certification d’accès des agents : chaque autorité d’agent fait l’objet du même processus d’attestation et de révision que tout autre accès, les propriétaires de ressources confirmant les droits à conserver et révoquant ceux devenus obsolètes. 
• Graphe d’accès des identités aux ressources : retrace l’ensemble du parcours reliant une personne, en passant par chaque agent agissant en son nom, jusqu’aux ressources et aux champs d’application accessibles à chacun, afin de visualiser l’étendue des risques avant qu’un incident ne survienne et d’identifier clairement la cible à révoquer le cas échéant. 
• Approbation humaine : lors du provisioning et lors de l’exécution d’une action sensible, une personne reste impliquée dans la prise de décisions là où cela est le plus important. 
• Autorité non supervisée : les agents commencent à acquérir une autorité non supervisée en fonction de leur comportement, plutôt que sur la base d’une confiance accordée d’emblée.

Rien de tout cela n’est un nouveau plan de contrôle. Il s’agit du même plan, étendu de la création d’un agent jusqu’au moment où son autorité est réévaluée, restreinte ou retirée.

Plan d’action pour l’entreprise agentique sécurisée

Prenez du recul, l’architecture répond aux trois questions que se pose chaque équipe sécurité (Figure 11) :

1. Où sont mes agents ? Ceux que l’entreprise a créé et ceux qui sont apparus spontanément. 
2. À quoi peuvent-ils se connecter ? Des serveurs MCP et applications SaaS à d’autres agents, comptes de service et systèmes d’enregistrement hérités. 
3. Qu’ont-ils le droit de faire ? Décidé à l’exécution, transmis à une personne lorsque cela est important, et révocable si cela ne se déroule pas comme prévu.

Ces trois questions constituent la discipline opérationnelle qui sous-tend le plan d’action de l’entreprise agentique.

Le plan d’action Okta pour la sécurisation des agents d’IA à grande échelle

Des entreprises comme Uber ont montré la nécessité de mettre en place ce type de gouvernance pour les agents d’IA.  Mais toutes les entreprises n’ont pas besoin de concevoir cette architecture elles-mêmes.

Le fil conducteur à chaque niveau est le même : l’identité constitue le plan de contrôle, l’autorisation est déterminée à l’exécution et limitée à la tâche, la personne responsable accompagne la requête, et l’ensemble repose sur des standards ouverts afin de garantir l’interopérabilité quel que soit le fournisseur avec lequel un agent interagit. 

Considérer les agents comme des identités à part entière selon ces principes constitue la meilleure approche pour protéger l’entreprise agentique, et Okta for IA Agents en fait une couche à adopter plutôt qu’un système à développer pendant un an.  L’architecture présentée dans cet article est conçue pour être adoptée, pas pour être développée. 

Découvrez comment Okta et Auth0 protègent les agents d’IA, ou contactez notre équipe.