Contexte et enjeux
ServiceNow positionne son AI Control Tower comme le point de convergence de la gouvernance des agents IA en production. Selon Bhakti Pitre, vice‑présidente de la sécurité de la plateforme IA, la décision de désactiver un agent ne peut se réduire à un simple bouton « kill switch ». Elle doit intégrer le risque technique et le processus métier soutenu par l’agent. L’entreprise cite un scénario concret : un agent autorisé à appliquer une remise maximale de 10 % a été détourné pour offrir 100 % de remise, illustrant le besoin d’un déclenchement de coupe‑feu conditionné par l’impact business.
Architecture du AI Control Tower
Le dispositif repose sur cinq étapes clairement définies : découvrir, observer, gouverner, sécuriser et mesurer. Ces phases structurent le flux de données depuis la détection d’un agent jusqu’à l’évaluation de son comportement. ServiceNow mappe chaque agent aux processus métier qu’il alimente, ce qui permet de relier les métriques de performance à des indicateurs de risque. L’intégration de Veza, fournisseur de technologie d’identité sécurisée, intervient à l’étape de sécurisation : elle ajuste dynamiquement les permissions excessives en fonction du contexte d’utilisation identifié.
Parallèlement, ServiceNow collabore avec Okta pour protéger les jetons de session et les identités des agents. Cette coopération vise à garantir que la révocation d’un token ne compromet pas les flux légitimes, tout en offrant une couche d’authentification unifiée entre les différents fournisseurs de services cloud.
Analyse des mécanismes de containment
Le modèle de décision de ServiceNow repose sur une corrélation entre le niveau de risque et le type d’action de containment. Un agent qui cesse de produire des résultats peut simplement être mis en pause pour enquête, tandis qu’un agent qui génère des actions commerciales anormales (ex. remise de 100 %) déclenche une révocation totale. Cette granularité repose sur la capacité du système à observer les métriques d’usage en temps réel et à les comparer aux seuils définis par les processus métier.
Le recours à Veza permet de réduire la surface d’attaque en limitant les privilèges au strict nécessaire, conformément au principe du moindre privilège. En ajustant les permissions, le système évite que la simple désactivation d’un agent ne crée de dépendances critiques non résolues dans d’autres services. L’interopérabilité avec Okta assure que les identités des agents restent cohérentes à travers les points d’accès, limitant ainsi les vecteurs de compromission liés aux jetons volés ou réutilisés.
Limites et perspectives
Le cadre présenté ne détaille pas les critères quantitatifs utilisés pour classer le risque, ni les seuils exacts qui déclenchent chaque type de réponse. Cette absence de métriques publiques complique l’évaluation de la robustesse du modèle et laisse place à des interprétations variables selon les organisations. De plus, la dépendance à des fournisseurs tiers (Veza, Okta) introduit une chaîne de confiance supplémentaire qui doit être auditée régulièrement. Enfin, l’évolution rapide des agents autonomes pourrait rendre les étapes fixes du Control Tower obsolètes, imposant une mise à jour continue des politiques de gouvernance.
