Blueprint Alliance : architecture commune pour agents IA

Du blueprint d’Okta à une architecture commune

#

En mars, j’ai écrit sur le Blueprint d’Okta pour la Secure Agentic Enterprise. Ses questions étaient volontairement pratiques : Où sont mes agents ? À quoi peuvent-ils se connecter ? Que peuvent-ils faire ? Donner à chaque agent une identité, un responsable et des connexions gouvernées constituait le point de départ. C’est toujours le cas. Mais un agent vit rarement dans l’environnement d’un seul fournisseur. Il peut être développé sur une plateforme cloud, appeler des outils via MCP, interroger les données d’un autre fournisseur, utiliser une application SaaS et confier une partie du travail à un second agent. Un seul plan de contrôle ne voit pas tout ce parcours.

Le 22 septembre 2026, Okta et onze autres membres fondateurs ont annoncé la Blueprint Alliance. AWS, CrowdStrike, Databricks, Docker, Google Cloud, Lovable, Proofpoint, Salesforce, ServiceNow, Wiz et Zscaler ont rejoint Okta, couvrant l’identité, l’IA, les données, les applications, l’infrastructure et la cybersécurité. GE Appliances et World Central Kitchen participent comme conseillers stratégiques. L’Alliance a publié un blueprint multivendeur élargi et le livre blanc Governing Agentic Execution.¹²

Pour moi, la nouveauté la plus intéressante est le changement de perspective architecturale. Le blueprint initial d’Okta expliquait comment gouverner les agents autour de l’identité. L’Alliance demande comment différents systèmes peuvent coopérer lorsqu’un agent traverse leurs frontières.

Ses quatre questions sont désormais : Où sont mes agents ? Que peuvent-ils faire ? Que font-ils ? Comment réagir ?

À la découverte et au contrôle des accès s’ajoutent l’observation continue et la réponse coordonnée. Il s’agit d’une architecture de référence et d’un engagement de l’industrie à tester l’interopérabilité, pas d’une promesse selon laquelle toutes les intégrations seraient déjà disponibles.¹

Illustration de la Blueprint Alliance tirée de l’annonce Okta.

Pourquoi les frontières entre fournisseurs comptent

#

Imaginons qu’un agent de support reçoive une demande d’un client. Il consulte une base de connaissances, lit un enregistrement dans une plateforme de données, ouvre un ticket dans ServiceNow et demande à un agent spécialisé de vérifier une exception. Son travail traverse plusieurs identités, politiques, réseaux et journaux. Si seule la première connexion est gouvernée, la délégation suivante peut perdre le contexte de l’utilisateur initial. Si seul le dernier outil est surveillé, les équipes d’intervention sauront peut-être ce qui s’est passé sans savoir qui l’a autorisé.

Les six principes du livre blanc traitent cette chaîne : considérer les agents comme des identités à part entière ; limiter l’accès à la tâche ; préserver la traçabilité de la délégation ; surveiller le comportement à l’exécution ; rendre le confinement rapide et réversible ; adapter la gouvernance lorsque les agents évoluent.²

Le document précise aussi des limites importantes. Les autorisations entièrement limitées à une tâche et la délégation traçable de bout en bout sur plusieurs sauts sont des objectifs que les outils actuels ne réalisent pas toujours. Une approche pragmatique peut associer des droits temporaires liés à la tâche et des permissions de base restreintes. Les environnements locaux et les sous-agents éphémères qui héritent du périmètre d’un agent parent peuvent être gouvernés par le confinement sur le poste et les contrôles de délégation, sans entrée distincte dans un annuaire. Un gateway, à lui seul, ne rend pas fiables les réponses d’un modèle.

Les membres construisent et testent l’interopérabilité avec MCP, OCSF, SSF, CAEP et, comme le précise le livre blanc, les HTTP Message Signatures. La publication d’intégrations de référence et de résultats de tests est prévue.¹²

Quatre questions pour tout le cycle de vie

#

1. Où sont mes agents ?

#

Impossible de revoir les accès d’un agent dont on ignore l’existence. L’inventaire doit couvrir les agents développés par vos équipes, ceux intégrés aux logiciels achetés et ceux créés par les collaborateurs. L’enregistrement devrait associer à chacun une identité distincte, une personne ou une équipe responsable, un objectif, un environnement, un état dans son cycle de vie et ses connexions. Un compte de service ou une clé API peuvent toujours intervenir, mais ne remplacent pas l’identité propre de l’agent.

Le livre blanc relie la découverte à la posture de sécurité : avant de faire confiance à un agent importé, il faut examiner la provenance du logiciel, les vulnérabilités, la configuration et même les définitions d’outils ou de skills MCP.² Il rappelle aussi que la détection dans le navigateur ou sur les postes doit respecter les exigences applicables en matière de vie privée, de droit du travail et de protection des données. J’ai approfondi le lien entre la gouvernance des agents et les exigences réglementaires dans mon article sur l’EU AI Act. L’annonce d’Oktane 2026 décrit l’enregistrement, l’import depuis AWS Bedrock et Salesforce Agentforce, ainsi que la détection dans le navigateur. La détection sur les postes a sa propre date de disponibilité prévue.³

La découverte n’est qu’une première étape. L’inventaire vieillit dès qu’une équipe clone un agent, change son modèle, ajoute un outil ou le déplace entre environnements. Le test pratique consiste à vérifier que chaque nouvelle connexion correspond à une identité enregistrée et attribuée, et que les agents orphelins sont retrouvés lorsque leur responsable change de poste ou quitte l’entreprise.

2. Que peuvent-ils faire ?

#

La réponse exige plus qu’une liste d’applications accessibles. Un agent peut avoir le droit de lire un dossier, mais pas de modifier un moyen de paiement ; d’appeler un agent spécialiste, mais pas de déléguer davantage ; d’agir pour un utilisateur, mais dans la limite des droits de cette personne. La frontière des permissions doit accompagner la tâche, y compris dans les appels en aval.

C’est là que Cross App Access (XAA) et la délégation par jeton deviennent concrets. Dans ma présentation des modèles d’accès et mon analyse technique, je compare XAA à Secure Token Service, aux clés prépartagées et aux comptes de service. La question essentielle est de savoir si la ressource peut vérifier l’identité d’un agent autorisé et conserver le contexte de la personne pour laquelle il agit. Un jeton OAuth devrait être limité en audience, périmètre et durée de vie ; la ressource doit toujours appliquer ses propres règles d’autorisation. Un jeton valide n’autorise pas, à lui seul, toutes les actions d’un outil.

Le livre blanc prévoit également la séparation des tâches, la revue des accès et la gestion du cycle de vie.² Pour un sous-agent, les droits effectifs devraient correspondre à l’intersection entre ses propres permissions et celles de l’utilisateur ou de l’agent délégant. Il faut aussi limiter la profondeur et l’ampleur de la délégation. Les politiques fondées sur l’intention constituent un niveau avancé : le document met en garde contre l’usage du texte littéral du prompt comme seul indice de l’intention.² À Oktane 2026, Okta a annoncé la disponibilité des connexions entre agents et des Resource Access Certifications. Configuration Designer arrive bientôt : il permettra de visualiser les connexions entre agents et ressources afin de gouverner, limiter et auditer chaque délégation.³

Parmi les annonces récentes d’Okta, Agent SSO intègre Cross App Access aux offres principales d’Okta SSO pour les agents compatibles. Il est disponible depuis août 2026.⁴ Il montre comment introduire l’identité des agents dans un modèle d’accès existant ; je détaillerai le produit et son flux technique dans un prochain article.

3. Que font-ils ?

#

Une revue des accès indique ce qu’un agent pourrait faire. La télémétrie d’exécution indique ce qu’il a fait. Une enquête a besoin de l’identité de l’agent, de l’identité humaine lorsqu’elle existe, de la ressource cible, de l’outil et de l’opération, de la décision de la politique, de l’horodatage, de la chaîne de délégation et d’un identifiant de corrélation. Il faut suffisamment de contexte pour distinguer un processus normal d’une séquence inattendue, sans enregistrer inutilement des prompts ou des données sensibles.

Le livre blanc distingue les gateways IA/LLM, MCP, de sécurité, pour agents et API : chacun observe une frontière différente, et l’API de destination doit encore autoriser ses propres requêtes.² Il prévoit également l’isolation de l’environnement d’exécution, la détection des injections de prompt, la prévention des fuites de données, l’usage des données selon leur finalité et le traçage. Les journaux devraient être collectés à la frontière d’exécution avec masquage des secrets et des données personnelles. Les signaux de risque corrélés relient ces contrôles : aucun gateway ne voit tout à lui seul.

Autre annonce récente, Agent Gateway place les contrôles d’identité et les politiques sur le chemin des appels aux outils.⁵ Il illustre la contribution possible d’un fournisseur au pilier de l’exécution de l’Alliance.

4. Comment réagir ?

#

Lorsqu’un agent commence une séquence suspecte, une alerte ne suffit pas. Il faut pouvoir réduire proportionnellement le débit des appels, révoquer des jetons ou des sessions, isoler l’environnement concerné, préserver les preuves et rétablir le service après une nouvelle attestation. Le livre blanc privilégie la réponse efficace la moins perturbatrice : arrêter un processus peut détruire des informations utiles encore en mémoire. Il souligne aussi qu’un kill switch n’est crédible que si l’environnement hébergeant l’agent peut réellement suspendre ou isoler celui-ci.²

Un signal de risque émis par un outil de surveillance devrait identifier l’agent et la session assez précisément pour qu’un autre plan de contrôle agisse et renvoie une confirmation. SSF et CAEP sont des briques pertinentes, mais l’annonce ne démontre pas que les douze fournisseurs partagent déjà des processus de confinement opérationnels.¹²

Okta décrit aujourd’hui la désactivation d’un agent depuis la console d’administration comme un blocage des nouvelles sessions. À Oktane, l’entreprise a aussi annoncé l’extension prévue du Kill Switch à Agent Gateway, pour révoquer les jetons actifs et interrompre les sessions en cours des agents connectés par le gateway.³ La distinction compte dans un plan de réponse aux incidents : empêcher un nouvel accès et arrêter un accès existant sont deux contrôles différents.

L’architecture en quatre piliers publiée sur le site de la Blueprint Alliance. Le PDF de l’architecture permet de l’examiner de plus près.

Que tester en premier dans l’entreprise ?

#

Le livre blanc propose une séquence utile : établir d’abord une télémétrie normalisée ; découvrir et enregistrer les agents ; ajouter les couches d’autorisation ; instrumenter l’exécution avant d’automatiser la réponse ; puis éprouver le confinement.² Je l’appliquerais à un agent traversant deux systèmes, sur une tâche aux permissions limitées. Ensuite, je parcourrais les quatre questions de bout en bout :

1. Inventaire et responsabilité : pouvez-vous identifier l’agent, son environnement, son modèle ou sa version, son responsable et toutes les connexions prévues ? Que devient cette identité si le responsable quitte l’entreprise ?
2. Autorisation et délégation : l’agent peut-il prouver son identité ? S’il agit pour un utilisateur, chaque ressource conserve-t-elle ce contexte et applique-t-elle un périmètre plus étroit que tous les droits de cet utilisateur ?
3. Preuves d’exécution : les journaux relient-ils la demande de l’utilisateur, l’identité de l’agent, l’appel de l’outil, la décision de la politique et la ressource cible ? L’équipe de sécurité peut-elle repérer une séquence d’outils hors de la tâche approuvée ?
4. Réponse et rétablissement : pouvez-vous bloquer une nouvelle connexion, révoquer une connexion active, préserver les preuves et réactiver l’agent après une revue documentée ?

J’ajouterais un test destiné à échouer : demander à l’agent d’appeler un outil en dehors de son périmètre. Le résultat attendu est une opération refusée et un événement d’audit compréhensible. Un second test peut modifier le responsable de l’agent ou désactiver son identité. Ces exercices montrent les discontinuités entre identité, gateways, applications et réponse aux incidents bien mieux qu’une diapositive remplie de cases cochées.

Les enseignements tirés de l’usage interne des agents chez Okta apportent une dimension opérationnelle. Jenna Cline décrit l’enregistrement des agents dans Universal Directory, dont Dex, le collaborateur numérique interne, et la limitation de leurs droits en fonction de la personne servie. Elle explique aussi le choix de quelques agents plus capables plutôt qu’une prolifération incontrôlée, et la réduction du nombre d’outils visibles par chaque agent.⁶ Ce dernier choix peut réduire à la fois l’exposition et le contexte d’outils envoyé au modèle, mais doit être mesuré dans chaque processus.

Les cinq scénarios « Blueprint in Action » du livre blanc sont explicitement des illustrations composites.² Son architecture d’exécution complète par ailleurs la sécurité des modèles et de la chaîne d’approvisionnement.

Ce que je suivrai ensuite

#

Le site de la Blueprint Alliance et son livre blanc sont de bons points de départ. La prochaine étape que je souhaite voir est une interopérabilité publiée et reproductible : un agent enregistré dans un système, un appel délégué vers un deuxième, un signal de risque venant d’un troisième et une réponse ciblée avec une piste d’audit complète. L’Alliance prévoit de publier des intégrations de référence et des résultats de tests.¹

La leçon pratique est déjà claire. La sécurité des agents IA concerne tout leur cycle de vie. L’identité établit qui est l’agent ; l’autorisation limite ce qu’il peut faire ; les signaux d’exécution montrent ce qu’il fait ; la réponse détermine ce qui arrive lorsqu’il dévie. L’Alliance donne aux fournisseurs des questions communes auxquelles répondre ensemble. Okta for AI Agents (O4AA) contribue aux quatre réponses : découverte et enregistrement des agents, gouvernance des connexions et des accès, visibilité sur les activités et contrôles de réponse, comme la désactivation et le confinement. Agent SSO et Agent Gateway sont deux annonces récentes qui s’inscrivent dans cette démarche plus large.³

Si vous construisez un agent aujourd’hui, à laquelle de ces quatre questions est-il le plus difficile de répondre dans votre environnement ? Je serais curieux de savoir où vos outils d’identité et de sécurité perdent encore le fil. Dites-le-moi dans les commentaires ou sur LinkedIn.

Sources et lectures complémentaires

#

• Annonce de la Blueprint Alliance, site de l’Alliance et livre blanc
• Annonce d’Agent SSO, présentation technique d’Agent Gateway et disponibilités annoncées à Oktane 2026
• Enseignements tirés de l’usage interne des agents chez Okta
• Documentation Okta sur Cross App Access et présentation OAuth de Cross-App Access
• Mes articles précédents : blueprint initial, modèles d’accès des agents IA, analyse technique et considérations de conformité