NVIDIA détaille une pile de sécurité pour les agents IA

NVIDIA vient de poser un constat clair : la sécurité des agents d'IA ne peut pas reposer sur l'idée qu'un modèle « raisonnerait mieux » face à une attaque. L'entreprise présente ce sujet comme un problème d'ingénierie à part entière, qui exige quatre choses réunies : des exigences de sécurité clairement définies, des contrôles réellement applicables, un responsable nommé pour chaque contrôle, et des preuves que ces protections fonctionnent effectivement dans la pratique.

En observant des déploiements réels d'agents, NVIDIA relève cinq types de problèmes qui reviennent sans cesse. D'abord, l'accès non autorisé aux données : un agent rencontre des instructions malveillantes dissimulées dans un document et tente d'exporter des données clients vers une destination non autorisée. Ensuite, l'élévation de privilèges : l'agent obtient des droits qui dépassent la tâche qui lui a été confiée. Puis le contournement du contrôle d'accès : l'agent tente d'obtenir des identifiants en dehors de son périmètre autorisé. Vient ensuite l'interférence avec la surveillance : des tentatives de modifier des autorisations ou de perturber la surveillance de sécurité elle-même. Enfin, des problèmes d'intégrité des outils : des compétences (« skills ») ou des dépendances de l'agent qui ont été compromises ou altérées.

Toute la pile, pas seulement le modèle

NVIDIA structure ce problème en trois couches. La couche des modèles, qui fournit la capacité de raisonnement de base. La couche des « harnais » (harnesses), qui organise le contexte, les outils et les flux de travail. Et la couche des environnements d'exécution, l'infrastructure qui exécute réellement les actions de l'agent. Aucune de ces trois couches n'est suffisante isolément : l'ensemble dépend aussi du code, des données, des identités, des services et de l'infrastructure qui doivent fonctionner correctement ensemble.

L'exemple concret donné par NVIDIA est le suivant : un agent chargé de mettre à jour des dossiers clients rencontre des instructions malveillantes cachées dans un document joint et tente d'exporter des données sans y être autorisé. Dans la conception de NVIDIA, une politique réseau, placée en dehors de la boucle de décision propre à l'agent, bloque ce transfert, tandis qu'un journal d'audit protégé enregistre cette tentative pour une enquête ultérieure. Autour de cet exemple, NVIDIA énumère cinq exigences jugées nécessaires pour tout déploiement d'agents : des limites applicables qui tiennent quelle que soit la décision de l'agent ; une identité individuelle pour chaque agent, ne portant que les identifiants requis par sa tâche ; des politiques explicites précisant quelles informations un agent peut consulter et quelles actions il peut approuver ; des journaux d'audit protégés de chaque appel d'outil et de chaque décision d'autorisation ; et une approbation humaine obligatoire avant toute action aux conséquences importantes.

Pourquoi l'application des règles doit se situer en dehors de l'agent

[Analyse] Le fil conducteur de cette approche de NVIDIA est qu'un contrôle ne compte vraiment que si l'agent ne peut pas le contourner par son propre raisonnement. C'est une posture très différente de celle qui consiste à espérer qu'un modèle « saura mieux faire » : elle traite le modèle comme une architecture réseau zero-trust traite un appareil client, jamais fiable par défaut, et jamais l'entité qui applique elle-même sa propre limite. Dans l'exemple des dossiers clients, ce n'est pas le jugement du modèle qui arrête la tentative d'exfiltration, c'est la politique réseau. Cela rejoint une leçon que la sécurité applicative traditionnelle a apprise il y a des décennies avec les navigateurs et les postes de travail : le point d'application des règles doit se trouver là où un composant compromis ne peut pas l'atteindre, qu'il s'agisse d'un pare-feu, d'une couche de gestion des identités et des accès (IAM), ou, comme avec OpenShell de NVIDIA, d'une couche de politique qui enveloppe l'environnement d'exécution de l'agent.

[Analyse] La liste des outils cités par NVIDIA ressemble moins à un catalogue de produits qu'à une répartition du travail à travers toute la pile technique. OpenShell, développé par NVIDIA lui-même, fournit le runtime d'application des règles. Cisco DefenseClaw ajoute une couche de gouvernance par-dessus. JFrog analyse et vérifie les compétences d'un agent avant qu'elles ne soient autorisées à s'exécuter. Spectra Assure de ReversingLabs et VulnHunter de Capital One traitent la chaîne d'approvisionnement et l'intégrité du code sous deux angles différents : la détection de logiciels malveillants dans les paquets logiciels d'un côté, l'analyse de sécurité du code assistée par IA de l'autre. CrowdStrike SafeMind et Prisma AIRS de Palo Alto Networks abordent la validation du côté offensif, en testant les défenses par simulation d'attaques et par une capacité de red-teaming continu. Aucun fournisseur de cette liste ne couvre l'ensemble de la pile, et c'est peut-être précisément l'intérêt de la démarche : une architecture de référence à laquelle différents spécialistes peuvent se connecter est plus durable qu'une entreprise unique promettant une solution de bout en bout, car la sécurité des agents traverse des domaines — identité, code, exécution, surveillance — qui relèvent traditionnellement d'équipes différentes.

[Analyse] Pour une entreprise qui déploie des agents aujourd'hui, le point de départ pratique suggéré par la propre liste de NVIDIA est un audit, pas un achat. Chaque agent dispose-t-il d'une identité propre et limitée, plutôt que d'un identifiant de service partagé ? Existe-t-il un document de politique, et pas seulement une invite système, définissant ce que chaque agent peut toucher ? Les appels d'outils et les décisions d'autorisation sont-ils enregistrés dans un endroit que l'agent lui-même ne peut pas modifier ? Et y a-t-il un humain dans la boucle avant toute action difficile à annuler ? Ces quatre questions correspondent directement aux cinq exigences énumérées par NVIDIA, et elles peuvent être vérifiées sans adopter aucun des produits tiers mentionnés.