Contexte et enjeux

Les systèmes autonomes, qualifiés d’IA agentiques, sont désormais intégrés aux produits SaaS, aux plateformes cloud et aux environnements d’entreprise. Cette diffusion multiplie les points d’entrée potentiels pour des comportements non autorisés, rendant la protection « par silo » insuffisante. Okta, leader de l’identité et de l’accès, a présenté lors de son événement Oktane une réponse collective : la Blueprint Alliance. L’alliance regroupe Amazon Web Services, CrowdStrike, Salesforce et ServiceNow, ce qui montre que les acteurs de l’infrastructure, de la détection de menaces, du CRM et de l’automatisation reconnaissent la nécessité d’une couche de sécurité interopérable pour l’ensemble du stack agentique.

Architecture proposée par la Blueprint Alliance

Le modèle architectural préconisé repose sur trois piliers : identité unique pour chaque agent, contrôle granulaire des permissions et visibilité en temps réel sur les actions exécutées. Okta fournit le service Okta for AI Agents, qui attribue un identifiant cryptographique à chaque instance d’agent, stocké dans un annuaire partagé. Les partenaires de l’alliance exposent leurs signaux de risque via des API normalisées, permettant à un système de gouvernance centralisé d’agréger les alertes de behavioural anomalies détectées par CrowdStrike ou les violations de politiques de données signalées par Salesforce. Cette interopérabilité repose sur des standards ouverts (OAuth 2.0, SCIM) afin d’éviter les verrouillages propriétaires.

Mécanismes d’identification et de gouvernance des agents

Chaque agent reçoit une identité vérifiable liée à un certificat X.509, ce qui rend possible la mise en œuvre de politiques de moindre privilège (« least‑privilege »). Okta impose des scopes d’accès qui limitent les actions autorisées (lecture de bases de données, appel d’API externes, exécution de scripts). La visibilité provient d’un flux continu de logs d’audit, normalisés par le format OpenTelemetry, et consommés par les solutions de SIEM de ServiceNow. En cas de déviation – par exemple un agent qui tente d’accéder à un bucket S3 non autorisé – le moteur de corrélation déclenche immédiatement une révocation de certificat et une mise en quarantaine automatisée, arrêtant ainsi le « rogue agent » avant qu’il ne cause un impact.

Perspectives et limites

Le modèle partagé accélère la mise en place de contrôles de sécurité, mais il dépend de l’adoption généralisée des API communes et de la confiance dans les fournisseurs d’identité. Aucun indicateur chiffré n’a été publié sur le taux de détection ou la latence de réponse, ce qui rend difficile l’évaluation de l’efficacité réelle. De plus, la gestion du cycle de vie des certificats pour des millions d’agents peut générer une charge opérationnelle importante. Enfin, la gouvernance inter‑entreprises nécessite des accords juridiques sur le partage de données de risque, un aspect encore peu détaillé dans les annonces publiques.