AI Control Tower : ServiceNow présente un chantier en cours

Détecter les risques de sécurité

L’éditeur ajoute progressivement des algorithmes de détection d’injection de prompts, de fuite de données sensibles (PII) et de déviation des agents IA. « Nous les mettons à disposition auprès des clients au sein d’une phase nommée Innovation Lab pour les tester à plus large échelle », déclare Bhakti Pitre, vice-présidente AI Security Product chez ServiceNow.

« Nous avons choisi ces trois volets de détections après avoir mené un sondage auprès de 500 clients en leur demandant quels sont les risques majeurs qu’ils souhaitent surveiller », poursuit-elle. « 80 % d’entre eux ont évoqué la fuite de données PII. Les injections de prompts arrivaient en numéro deux sur la liste et en trois la détection des agents déviants, qui ne suit pas les objectifs lui ayant été donnés ».

Ensuite, Bhakti Pitre et ses équipes ont comparé cela avec les recommandations OWASP en matière de LLM et d’IA agentique. « Nous avons en quelque sorte trouvé le juste milieu, entre ce que veulent les clients et ce qui leur est recommandé », résume-t-elle. ServiceNow couvre ainsi sept des dix patterns listés par l’OWASP.

Une partie de ces fonctionnalités sont permises par l’intégration de Traceloop, selon Joe Davis, vice-président directeur AI Platform & Product Engineering chez ServiceNow. L’éditeur a finalisé l’acquisition de la startup éponyme il y a deux mois. L’outil permet surtout de récupérer les traces et de s’assurer des niveaux de conformité et sécurité en presque temps réel.

Pour l’heure, cette capacité de traçage est valable à l’échelle de ServiceNow. « Nous avons lancé une fonctionnalité en mars en phase d’Innovation Lab qui permet de suivre des agents IA à travers différentes plateformes, à l’aide de la convention OpenTelemetry pour les LLM », indique Bhakti Pitre.

Les fonctions incubées dans l’Innovation Lab en mai entreront en disponibilité générale en août prochain.

Tout cela permettait jusqu’alors à ServiceNow de proposer des tableaux de bord pour rendre visibles les projets IA et faciliter leur contrôle.

Contrôler la conformité et les investissements

C’est également l’objet du volet « risques et conformité ». Outre les mécanismes de détection évoqués plus haut, ServiceNow a adapté sa brique de suivi de conformité à l’AI Control Tower. L’éditeur applique l’AI Risk Management Framework du NIST et le cadre de classification des risques de l’AI Act européen. Ainsi, les entreprises peuvent identifier les projets conformes et non conformes, mais également planifier les efforts légaux de remédiation avant le passage en production d’un système IA.

Pour autant, les risques liés à la chaîne logistique, à savoir si une entreprise utilise, fournit, distribue ou importe un système d’IA, ne sont que partiellement surfacés, principalement en lien avec la réglementation RGPD et la norme PCI DSS. C’est l’une des parties de l’AI Act encore difficiles à appréhender par les entreprises.

La partie la plus usitée par les quelques entreprises qui ont déployé l’AI Tower semble être le volet de mesure de retour sur investissement. Oliver De Wilde, directeur de la transformation IT chez Hitachi en Suisse, explique qu’il a principalement mis en œuvre cette capacité au sein du groupe japonais. Elle permet de juger si la DSI « a mis ses œufs dans le bon panier » en matière d’IA. « Le risque financier n’est pas réellement lié aux limites de puissances de calcul », a-t-il expliqué. « En revanche, le fait de dépendre d’un hyperscaler, d’un petit nombre de fournisseurs et data centers entraîne un risque de verrouillage ». C’est aussi un moyen de prioriser les cas d’usage suivant la valeur mesurée des déploiements progressifs là où les ressources de développement sont, elles, restreintes.

Actuellement, les estimations des gains en heure et en dollars sont dépendantes d’algorithmes de scoring mis au point par l’éditeur. Ils s’appuient sur des estimations qu’il conviendra de personnaliser pour en profiter pleinement.

La visibilité est une chose, mais ServiceNow cherche surtout la mise en contrôle des actifs IA.

Des « kill switches » pour stopper les attaques visant les serveurs MCP et les LLM

 Sur scène, Bill McDermott, président et CEO de ServiceNow, a vanté l’existence de « kill switches » pour éviter les débordements en cas d’attaque, de déviation ou de surconsommation. Dans les faits, un seul d’entre eux est actif dans le cadre du lancement de la mise à jour Australia. Il sert à couper temporairement le trafic de la gateway réservé aux serveurs MCP. « Si nous constatons un trafic inhabituel, par exemple un grand nombre de tentatives d’accès en échec, nous pouvons suspendre tout le trafic au niveau de la passerelle ou à l’échelle du serveur MCP », explique Ashley Snyder, senior principal outbound product manager chez ServiceNow.

Une autre passerelle IA permettra de faire la même chose au niveau des LLM. « Nous la lancerons au cours du troisième trimestre 2026 », précise-t-elle.

Cette passerelle, Guardian, existe déjà pour les LLM, les assistants et les agents IA de l’éditeur, ajoute Bhakti Pitre.

« Concernant les kill switches, supprimer l’accès à la passerelle LLM et aux outils ne suffit pas », insiste-t-elle. « Il faut également que cela s’applique aux jetons [tokens] d’accès et d’identité ». Il s’agira alors de révoquer les accès et les permissions en cas de suspicion.

C’est l’une des raisons pour lesquelles ServiceNow a acquis Veza. « Nous travaillons également avec des partenaires », assure Bhakti Pitre, tout en omettant sciemment de les nommer.

L’avenir, la révocation des identités et des accès des agents IA

Pour l’instant, à travers l’AI Control Tower, ServiceNow a le moyen de distinguer ses agents IA qui agissent au nom des usagers et ceux qui travaillent de manière autonome.

« Au sein de ServiceNow, il y a des agents “worker” et des agents “helper”. L’agent worker possède sa propre identité, de ses droits d’accès et va effectuer des tâches de manière autonome », décrit-elle. « L’agent helper est un assistant invoqué par l’utilisateur. On lui attribue l’identité de l’usager et les permissions associées. Dans ce cas, nous utilisons une technique très intéressante appelée “masquage de rôle”, explique-t-elle. Ce mécanisme applique le principe du moindre privilège aux agents invoqués depuis Now Assist afin de limiter l’accès aux actifs IA mentionnés plus haut.

« Si le masquage des rôles est appliqué à un flux de travail agentique, à un agent IA ou à un outil s’exécutant en tant qu’utilisateur dynamique, le composant s’exécute avec des rôles limités à l’intersection des rôles de l’utilisateur qui l’invoque et des rôles figurant dans la liste approuvée pour le masquage des rôles », lit-on dans la documentation de ServiceNow.

« C’est important, car cela veut dire que tous mes rôles ne sont pas transférés à l’agent », souligne Bhakti Pitre.

Il faudra pouvoir appliquer ce mécanisme à des agents tiers. Tous n’ont pas encore la même vision des identités d’un agent IA. De ce que comprend LeMagIT, l’approche de ServiceNow se rapproche de celle de Google Cloud et de Microsoft, mais il faut encore pouvoir rendre ces mécanismes interopérables. De même, le spécialiste de l’ITSM cherche à affiner les niveaux de contrôle dont il dispose sur la gestion des outils. L’idée de révoquer l’accès aux outils, une fois une sous-tâche terminée, sans attendre la fin de l’exécution d’un flux agentique plaît à Bhakti Pitre.

Armis, acquis pour 7,75 milliards de dollars, ajoutera des fonctionnalités pour suivre les déploiements des agents IA et des LLM sur des équipements IT et OT. L’éditeur n’a pas détaillé ses plans sur ce point, hormis qu’il permettra de surfacer automatiquement les actifs IA, en partenariat avec Microsoft (Agent 365) et Palo Alto Networks.