L'architecture a changé. Le modèle de responsabilité, non.
Pour les ingénieurs en sécurité de l'IA embauchés pour sécuriser les agents et les systèmes qu'ils utilisent. Le travail couvre l'AppSec, l'IAM, les données et la gouvernance. Le code est le point de convergence de ces responsabilités.
La sécurité cloud était autrefois considérée comme une responsabilité supplémentaire pour l'équipe existante. Puis l'architecture a suffisamment évolué pour que l'ancien modèle de responsabilité ne soit plus évolutif, et le rôle est devenu une fonction à part entière. L'IA en est à ce stade.
Un agent peut raisonner sur des données, choisir un outil, hériter de permissions et effectuer une action dans un autre système. L'identité de l'agent, les chemins de prompt, le câblage RAG et MCP, le sandboxing et le confinement à l'exécution apparaissent désormais dans les descriptions de poste d'entreprises qui intégraient auparavant ces aspects à l'AppSec. Le vide organisationnel que ces rôles comblent est la propriété de toute la chaîne. Le vide dans la revue de code est plus précis : les permissions, les journaux et les chemins de supervision humaine qui rendent la chaîne concrète sont définis dans les pull requests.
La chaîne est organisationnelle. Le diff reste un contrôle.
Les outils d'exécution surveillent l'agent. heygrc lit le changement qui lui a accordé les permissions. Les linters et SAST ne sont pas conçus pour connaître les frameworks que vous appliquez. Un test d'injection de prompt ne voit pas que le PR de la semaine dernière a supprimé la voie d'intervention ou élargi le rôle d'appel d'outil. heygrc est conçu pour examiner chaque pull request par rapport aux frameworks que vous avez sélectionnés et citer le contrôle qu'un changement affecte : identité et accès de l'agent, tenue des registres sur le fonctionnement du système, les moyens pour l'humain d'intervenir.
Les art. 12 et art. 14 sont des obligations du régime à haut risque. heygrc ne classe pas le niveau de risque de votre système et n'effectue pas votre évaluation de conformité. Savoir si ces articles s'appliquent relève de votre propre évaluation. Il ne sandboxe pas l'agent, ne teste pas l'injection de prompt, ni ne contient un appel d'outil incontrôlé à l'exécution. Il examine le changement de code par rapport aux frameworks que vous avez sélectionnés et cite le contrôle. Vous restez le juge de ce qui bloque et de ce qui est déployé.
Des modifications qui semblent être du code ordinaire.
Quelques-unes des modifications pertinentes pour les contrôles que heygrc est conçu à signaler pour ce cas, chacune citée avec la clause qu'elle touche.
Un rôle d'agent ou d'appel d'outil s'élargit à un joker
SOC 2 CC6.1La voie d'intervention humaine est retirée de la console de revue de l'agent
EU AI Act Art. 14Le journal des inférences est retiré d'un agent décisionnel
EU AI Act Art. 12
Les cadres qui comptent le plus ici.
Guide: EU AI Act pour les développeurs
heygrc signale les modifications pertinentes pour les contrôles et cite la clause afin que le problème puisse être traité dans la pull request. Il ne vous certifie pas, ne réalise pas votre audit, ni ne remplace votre propre jugement.