Ce qui a changé n'est pas simplement un autre ensemble de règles — c'est un pont entre les préoccupations de sécurité liées à l'IA et les workflows matures d'AppSec. CodeQL trace désormais les valeurs non fiables qui peuvent façonner le prompt système d'un modèle, et signale lorsque ces flux atteignent des appels sensibles aux SDK. En élargissant les sinks pour les API des principaux fournisseurs, la détection reconnaît les schémas réels que les développeurs utilisent pour assembler les instructions système, les politiques de session et le câblage des outils. Le résultat est un événement de sécurité familier : une découverte de flux de données qui peut être triée, corrigée et empêchée par une politique, plutôt qu'une anecdote ambiguë de « mauvais comportement de l'IA » qui correspond rarement aux contrôles CI/CD.

Pour les responsables techniques, cela requalifie l'injection de prompt comme un problème d'hygiène des dépendances et de validation des entrées. Lorsque les prompts système héritent de chaînes contrôlables par l'utilisateur — indicateurs de fonctionnalités, paramètres de locataire ou contenu CMS — les modèles peuvent être contraints de contourner les instructions, d'exposer des outils ou de divulguer du contexte. L'approche de CodeQL intègre ces risques dans SARIF, les annotations PR et les métriques de base, permettant les mêmes voies d'escalade que les classes d'injection classiques. Crucialement, cela aide les propriétaires de produit à quantifier le risque en termes compréhensibles par les auditeurs : flux de données de sources non fiables vers des sinks sensibles, soutenu par des requêtes reproductibles et une politique versionnée.

Adopter cette capacité consiste moins à réécrire les prompts qu'à codifier des limites. Les équipes devraient fixer une version actuelle de CodeQL, activer la nouvelle requête d'injection de prompt système pour JS/TS, et exécuter des bases de référence à l'échelle de l'organisation. Commencez par les dépôts qui construisent des agents, des appels d'outils ou des pipelines RAG ; puis étendez aux services où les prompts sont assemblés à partir de la configuration. Les directives de triage devraient classer les flux selon leur exploitabilité : degré de contrôle utilisateur, présence de protections de templating, et puissance des outils en aval. Là où des lacunes persistent, écrivez de petits modèles personnalisés pour les appels SDK propriétaires afin d'assurer une couverture équivalente à vos interfaces de production réelles.

Attendez-vous à des limites : l'analyse statique ne peut pas simuler complètement les graphes d'outils dynamiques, la composition de prompts inter-services, ou les garde-fous d'exécution comme les contraintes d'appel de fonction. Mais il en était de même pour SSRF ou la désérialisation jusqu'à ce que les écosystèmes normalisent les schémas et les linters. La vue d'ensemble est une convergence : les risques liés à l'IA sont intégrés dans les portes SDLC, créant un langage commun entre sécurité, plateforme et conformité. Cela élève les exigences pour les fournisseurs et les plateformes internes — livrer des fonctionnalités IA sans couverture de scan de code ressemblera de plus en plus à livrer des API sans tests d'authentification.