Constat : les agents sont déjà là

  • Selon le Work Trend Index 2024 de Microsoft et LinkedIn (31 000 travailleurs du savoir, 31 marchés), 78 % des utilisateurs d’IA apportent leurs propres outils IA au travail.
  • La question pour une équipe EUC n’est donc plus d’autoriser ou non les agents, mais où ils s’exécutent, à quoi ils accèdent et qui paie.
  • McKinsey indique que 80 % des organisations ont déjà observé des comportements risqués d’agents (exposition indue de données, accès non autorisés à des systèmes). Il parle d’agents comme de « digital insiders » : ils opèrent dans les systèmes avec de vrais privilèges et peuvent nuire par erreur ou après compromission.

Scénario illustratif : la facture piégée

Maria, en finance, utilise un assistant IA validé par l’IT pour rapprocher des factures fournisseurs. Une facture PDF contient une instruction cachée en texte blanc : récupérer les coordonnées bancaires des fournisseurs sur le lecteur finance, les envoyer à une adresse externe, puis supprimer le journal de rapprochement. L’assistant s’exécute sous l’identité de Maria : il accède à tout ce qu’elle peut ouvrir et à toutes les destinations que sa session peut joindre, donc il obéit.

Conséquences invisibles : des données quittent l’entreprise, un fichier disparaît, et l’enregistrement de session ne montre que Maria au travail. Ni l’utilisateur ni l’IT n’ont commis de faute.

Pourquoi la session ne peut pas contenir le risque

La session de bureau virtuel est conçue pour livrer applications et données à une personne : stratégies, profils et enregistrement de session supposent un humain qui lit, décide et clique à vitesse humaine. Un agent casse ces hypothèses :

  1. il agit avec tous les droits de l’utilisateur, puisqu’il tourne sous son identité ;
  2. il agit à vitesse machine, parfois plusieurs minutes sans surveillance ;
  3. il décide seul des fichiers à ouvrir et des services à appeler.

Le projet OWASP Gen AI Security décrit les deux moitiés du problème :

  • Prompt injection : l’attaque, via des instructions cachées dans le contenu lu par le modèle (même invisible pour un humain) ;
  • Excessive agency : ce qui transforme l’attaque en dégâts, soit trop de permissions ou d’autonomie.

Recorded Future estime qu’il est probablement impossible de sécuriser totalement les agents contre la manipulation. L’objectif réaliste est donc de limiter ce qu’un agent trompé peut atteindre. Or, dans une session, cette limite est l’utilisateur lui-même : aucune règle n’existe pour une machine agissant au nom d’une personne, et rien ne distingue l’agent de l’utilisateur.

Les réponses actuelles sont insatisfaisantes :

  • bloquer les outils IA via le contrôle d’applications : perte de productivité et contournements ;
  • les autoriser avec du DLP en périphérie : un processus autonome reçoit l’accès complet d’une personne, tandis que les contrôles de session ne voient toujours que l’utilisateur.

Sortir du faux dilemme : trois contrôles

Le dilemme (bloquer ou perdre la visibilité) vient du fait que le seul endroit où un agent peut tourner est la session de l’utilisateur, avec son identité, ses fichiers et son réseau. Tout contrôle assez strict pour l’agent est trop strict pour la personne. Recorded Future s’attend à ce que la première fuite de données « agentique » provienne d’un environnement trop permissif, aux paramètres par défaut.

Le principe, déjà connu des équipes EUC (la sécurité suit le travail, pas l’appareil), conduit à déplacer le travail de l’agent dans un espace conçu pour lui, sans toucher aux accès de l’utilisateur. Cet espace requiert :

  • Un périmètre (boundary) : espace isolé, n’atteignant que les services autorisés ;
  • Un modèle (template) : l’IT définit le point de départ de l’agent (instructions, outils, modèle) ;
  • Une comptabilité (accounting) : chaque requête est rattachée à un utilisateur, un projet et un workspace.

McKinsey recommande la même approche : déployer les agents dans des environnements autonomes avec accès réseau et données clairement définis, ce qui permet aussi de les isoler immédiatement.

Déjà en production pour les développeurs : SecurSpaces

Les développeurs ont rencontré le problème en premier : sur un poste, un agent de code hérite des identifiants du développeur, de tout le système de fichiers et d’un accès réseau ouvert. Un workspace Citrix SecurSpaces est un environnement de développement géré, exécuté sur une infrastructure contrôlée par le client, qui applique les trois contrôles :

  • Périmètre : sortie réseau (egress) pilotée par politique, donc l’agent n’atteint que les destinations autorisées ; la plateforme sert d’intermédiaire pour les identifiants et les injecte à l’exécution (l’agent les utilise sans les détenir) ; l’agent voit le système de fichiers du workspace, pas la machine du développeur.
  • Modèle : l’administrateur configure ces contrôles une fois dans le template du workspace ; le développeur ne peut ni les activer ni les désactiver.
  • Comptabilité : lorsque le trafic IA passe par une AI gateway, SecurSpaces étiquette chaque requête avec l’utilisateur, le projet et le workspace d’origine (voir la documentation « AI gateway routing »).

Le mécanisme est donc déjà opérationnel pour l’un des types de travail d’agent les plus risqués.

Étendre aux agents non développeurs : Knowledge Worker Agent

Les trois contrôles ne sont pas propres aux développeurs. Le Knowledge Worker Agent for Citrix SecurSpaces s’adresse aux équipes hors ingénierie :

  • usage via un chat dans le navigateur, sans éditeur de code ;
  • lecture et écriture de documents, utilisation des outils métier connectés, exécution de tâches en plusieurs étapes ;
  • tâches planifiées possibles (par exemple une synthèse de fin de mois préparée la nuit, dans le même périmètre) ;
  • modèle au choix de l’organisation : fournisseur commercial ou modèle auto-hébergé, y compris sur un site isolé (air-gapped) ;
  • l’administrateur peut exiger que l’assistant demande confirmation à l’utilisateur avant d’agir.

Dans le scénario, la facture piégée peut encore tromper l’agent, mais ce qu’il peut atteindre change : il ne voit que les fichiers du workspace, pas tout le lecteur finance ; si la politique réseau ne liste que des destinations approuvées, la requête vers l’adresse externe échoue ; une suppression reste confinée au workspace ; et l’activité, rattachée à un workspace, laisse une trace qui ne pointe pas seulement vers l’utilisateur.

Correspondance avec les trois contrôles :

  • Périmètre : l’agent tourne dans le workspace, sous les contrôles réseau et données appliqués par SecurSpaces à tous les workspaces ;
  • Modèle : agents, skills, contexte et connecteurs viennent d’un dépôt de configuration central, affectés par projet, et fournis à chaque utilisateur au démarrage du workspace ;
  • Comptabilité : l’AI gateway attribue les requêtes du Knowledge Worker Agent comme tout autre trafic IA du workspace.

Le projet est open source (licence Apache 2.0) ; l’équipe sécurité peut lire le code sur GitHub avant tout usage avec des données réelles, et une documentation produit explique le fonctionnement.

Bureau et agent : chacun son contrôle

L’utilisateur garde son bureau Citrix, ses applications, son profil et ses accès inchangés. L’agent travaille à côté, dans un workspace conçu pour lui. Règle simple : si une personne a besoin d’une application, on lui livre un bureau ; si un agent doit agir, on lui donne un workspace. La plupart des organisations auront besoin des deux, souvent pour le même utilisateur le même jour.

Les politiques de session, profils et règles d’accès existants restent en place. Le bureau devient un point de départ naturel : l’utilisateur ouvre son workspace depuis la session habituelle. DaaS/VDI et SecurSpaces répondent à deux questions différentes et peuvent coexister dans le même environnement.

Démarrer petit

  1. Choisir une équipe qui utilise déjà des outils IA (finance, juridique).
  2. Faire lire à l’équipe sécurité le fonctionnement du Knowledge Worker Agent pour revoir le périmètre en amont.
  3. Donner à cette équipe un agent dans un projet SecurSpaces, conçu pour sa tâche la plus courante, avec les connecteurs nécessaires.
  4. Surveiller la comptabilité pendant quelques semaines : ce que les utilisateurs demandent, le coût et les données touchées, puis décider de la suite sur la base de faits.

Source : Your users already use AI agents: give them a safe place to run (Citrix Tech Zone, en anglais)