Gouvernance de l’IA axée sur l’identité : Sécuriser la main-d’œuvre agentique
Les agents d’IA opèrent désormais au sein de systèmes de production, interrogeant Snowflake, mettant à jour Salesforce et exécutant des logiques commerciales de manière autonome. Dans de nombreuses entreprises, ils s’authentifient en utilisant des clés API statiques ou des identifiants partagés, plutôt que des identités distinctes dans le IDP d’entreprise.
Les risques de gouvernance liés à l’authentification autonome
L’authentification des systèmes autonomes par des identifiants partagés introduit un véritable risque de gouvernance. Lorsqu’un agent exécute une action, les journaux l’attribuent souvent à une clé de développeur ou à un compte de service, au lieu d’un acteur autonome clairement défini. Cela crée une ambiguïté d’attribution et affaiblit le principe du moindre privilège. De plus, la révocation peut nécessiter de faire tourner les identifiants ou de modifier le code, plutôt que de désactiver une identité régulée.
Les identifiants partagés transforment les systèmes autonomes en identités fantômes, agissant au sein de la production sans une identité régulée dans le répertoire d’entreprise. La plupart des organisations disposent de mécanismes de surveillance, mais le problème est structurel.
La nécessité d’une gouvernance axée sur l’identité
Le fossé de gouvernance créé par les identités fantômes ne peut être comblé par du simple monitoring. Il nécessite un changement structurel dans la façon dont les systèmes autonomes sont régis. Lorsqu’un système peut récupérer des données de manière dynamique, générer des résultats probabilistes et exécuter des actions, il doit être considéré comme un acteur opérationnel.
Les principes de gouvernance pour l’IA agentique
À mesure que les systèmes autonomes intègrent les environnements de production, la gouvernance doit devenir explicite. Au minimum, trois principes sont essentiels :
- Éliminer les identifiants statiques : Les systèmes autonomes ne doivent pas s’authentifier par des clés API à long terme.
- Auditer l’acteur, pas la plateforme : Les journaux de sécurité doivent attribuer les actions à des identités autonomes spécifiques.
- Centraliser l’autorité de révocation : Les équipes de sécurité doivent pouvoir restreindre ou désactiver un système autonome via le plan de contrôle d’identité principal.
Exemple pratique : Agents soutenus par une identité
Une réponse architecturale au fossé de gouvernance d’identité est de provisionner les systèmes autonomes en tant qu’identités de première classe dans le répertoire d’entreprise. Cela nécessite une coordination entre l’orchestration des agents et l’infrastructure d’identité de l’entreprise.
Avec une intégration approfondie entre DataRobot et Okta, les organisations peuvent maintenant provisionner des agents en tant qu’identités régulées directement dans Okta. Dans ce modèle, chaque agent reçoit une identité soutenue par un répertoire, et les actions sont enregistrées pour un acteur autonome spécifique.
Conclusion
Les systèmes autonomes deviennent des acteurs visibles au sein du même plan d’identité qui sécurise les utilisateurs humains. Plutôt que d’introduire un système de sécurité IA parallèle, les organisations peuvent étendre les contrôles qu’elles exploitent déjà. L’IA de gouvernance est, en fin de compte, la gouvernance de la main-d’œuvre.