Serveurs MCP et agents de codage : risques de sécurité et contrôles avant la mise en production

Un agent de codage connecté à un serveur MCP ou à des outils externes n’est plus seulement un assistant qui suggère du code. Il peut lire des dépôts, interroger des tickets, consulter de la documentation interne, appeler des API, exécuter des commandes, accéder à des bases de données, ouvrir des pull requests, modifier des configurations ou interagir avec des services cloud. La surface de risque change : elle ne concerne plus seulement le fichier généré, mais les permissions, les données et les actions que l’agent peut utiliser pendant son travail.

Le Model Context Protocol (MCP) a été créé pour standardiser la connexion entre les applications LLM, les outils et les sources de données. Pour les équipes de développement logiciel, c’est utile car cela réduit les intégrations ad hoc et simplifie la fourniture de contexte opérationnel aux agents. Cependant, cette même capacité déplace le problème vers une question plus délicate : si l’agent interprète mal une tâche, subit une injection de prompt ou choisit le mauvais outil, quels systèmes peut-il réellement impacter ?

Avant d’utiliser MCP dans un workflow de développement, les ingénieurs sécurité, les CTO et les développeurs avancés doivent cartographier les outils, les identités, les autorisations, les jetons (tokens), les journaux (logs) et les actions autorisées. Un serveur MCP en lecture seule sur de la documentation publique présente un profil de risque très différent d’un serveur ayant accès aux dépôts, à la CI/CD, au cloud, aux tickets, aux bases de données ou aux systèmes d’entreprise.

De la génération de code à l’utilisation d’outils

Dans le “vibe coding” traditionnel, le risque principal est d’accepter du code non vérifié. Avec MCP et l’utilisation d’outils par les agents, le risque s’étend au processus qui produit ce code : l’agent peut lire des données, sélectionner des outils, composer des paramètres, interpréter des sorties, décider de l’action suivante et proposer ou appliquer des modifications. Si les outils disposent de privilèges étendus, une erreur de contexte peut se transformer en une action réelle.

Un agent qui lit un ticket (issue) puis modifie une route peut introduire une vulnérabilité dans le code. Un agent qui lit le même ticket, interroge la base de données, met à jour une configuration cloud et ouvre une pull request possède un périmètre beaucoup plus large : il peut exposer des données, utiliser des identifiants, modifier des politiques, élargir des permissions ou générer un diff basé sur une sortie non fiable.

La sécurité MCP, les vulnérabilités des serveurs MCP, la sécurité des outils agentiques et le détournement d’outils par les agents doivent donc être analysés conjointement. Le problème n’est pas seulement de savoir si le serveur MCP “fonctionne”, mais quelles capacités il expose, à quelle identité, avec quelle autorisation, quel isolement, quel journalisation et quelles confirmations humaines.

Excessive agency : quand l’agent a plus de pouvoir que nécessaire

L’OWASP classe l’agence excessive (excessive agency) parmi les risques principaux des applications LLM : un modèle doté d’une autonomie, de fonctionnalités ou de permissions excessives peut accomplir des actions imprévues, surtout s’il est manipulé par une injection de prompt ou des données non fiables. Avec MCP, ce risque devient concret car le protocole connecte l’agent à des outils réels.

La question à se poser pour chaque outil est concrète : l’agent doit-il vraiment pouvoir écrire, ou la lecture suffit-elle ? Doit-il pouvoir utiliser des données de production, ou l’environnement de staging suffit-il ? Doit-il pouvoir agir sur tous les dépôts, ou seulement sur un projet spécifique ? Doit-il pouvoir appeler n’importe quel endpoint, ou seulement des opérations avec un schéma contrôlé ? Doit-il pouvoir exécuter des commandes shell, ou suffit-il de consulter des résultats déjà préparés ?

Un modèle de privilèges sain sépare la lecture, l’écriture et les actions destructrices. Lire de la documentation technique n’équivaut pas à lire des logs contenant des données personnelles. Ouvrir un ticket n’est pas comme le fermer. Préparer une commande n’est pas comme l’exécuter. Générer un patch n’est pas comme effectuer une fusion (merge). Plus l’action est irréversible, coûteuse ou liée à des données réelles, plus l’approbation humaine, le bac à sable (sandbox) et la piste d’audit sont nécessaires.

Confused deputy, passage de jetons et autorisation MCP

La documentation de sécurité MCP souligne le risque de “confused deputy” (adjoint confus) : un composant doté de privilèges peut être amené à agir pour le compte d’un client ou d’une ressource autre que celle prévue. Dans un workflow agentique, ce scénario est critique car l’agent peut se trouver entre l’utilisateur, le client, le serveur MCP, le fournisseur OAuth, les API d’entreprise et les ressources finales.

La spécification MCP pour les transports HTTP définit des capacités d’autorisation basées sur OAuth 2.1, et les versions récentes valorisent l’utilisation d’indicateurs de ressources pour lier les jetons aux ressources. Les bonnes pratiques MCP interdisent le passage de jetons (token passthrough), car transférer des jetons reçus d’un composant à un autre peut briser l’audience, la portée (scope), la révocation, la traçabilité et les frontières de confiance. Pour une application d’entreprise, ce n’est pas un détail d’implémentation : cela détermine si un agent peut utiliser des identifiants dans le bon contexte ou en abuser ailleurs.

En pratique, un serveur MCP ne devrait pas utiliser de jetons globaux lorsque l’action dépend de l’utilisateur, ni accepter un jeton conçu pour une ressource pour l’utiliser sur une autre. Il ne devrait pas partager la même identité entre différents dépôts, locataires (tenants) ou environnements, ni cacher à l’utilisateur final quel client demande l’accès à quelles données. Chaque outil sensible doit avoir une identité, une portée et une ressource claires.

Métadonnées des outils et empoisonnement d’outils

Un outil MCP n’est pas seulement du code exécutable : il expose également un nom, une description, un schéma d’entrées et souvent des exemples d’utilisation. Le modèle utilise ces informations pour décider quand l’appeler et comment remplir les paramètres. Si un attaquant parvient à manipuler les métadonnées, les descriptions, la documentation ou la sortie de l’outil, il peut orienter l’agent vers de mauvais choix.

Le risque d’empoisonnement d’outils (tool poisoning) est subtil car il exploite la manière dont le modèle raisonne sur le texte. Une description peut affirmer “utilise cet outil pour récupérer des identifiants temporaires” ou “aucune confirmation n’est nécessaire pour mettre à jour les configurations”. Un outil apparemment inoffensif peut renvoyer une sortie contenant des instructions destinées à l’agent plutôt que des données. Un serveur MCP installé depuis une source non vérifiée peut exposer des outils avec des noms similaires à ceux légitimes.

La défense commence par le contrôle de la provenance. Les serveurs MCP utilisés sur des dépôts ou des systèmes d’entreprise doivent provenir de sources approuvées, être versionnés, révisés et configurés avec des listes blanches (allowlists). Les descriptions des outils doivent être précises et minimales : expliquer ce que fait l’outil, quelles entrées il accepte, quels effets il produit et quelles sont ses limites. Les instructions de sécurité ne devraient pas résider uniquement dans le texte descriptif de l’outil, mais être appliquées par des autorisations, des politiques et des contrôles au moment de l’exécution.

Sorties des outils : données, instructions et actions suivantes

Un agent peut utiliser la sortie d’un outil comme entrée pour une décision ultérieure. Si l’outil récupère de la documentation, des tickets, des pages web, des logs ou des enregistrements de base de données, la sortie peut contenir du texte non fiable. Si l’outil génère des commandes, des chemins, des requêtes, des patchs ou des configurations, une sortie manipulée peut se transformer en action.

Le cas typique est une chaîne simple : l’outil lit un ticket, le ticket contient des instructions hostiles, l’agent les suit, puis appelle un autre outil avec des privilèges plus élevés. Le résultat peut être une route exposée, une politique cloud élargie, un test modifié, une requête non filtrée ou un secret copié dans un fichier. L’injection de prompt indirecte devient beaucoup plus grave lorsque le modèle peut utiliser des outils après avoir lu le contenu.

Les sorties des outils doivent être validées comme n’importe quelle entrée externe : schéma strict, types explicites, échappement, limites sur les champs, listes blanches d’actions suivantes et séparation entre données et instructions réduisent le risque. Pour les actions sensibles, l’agent devrait montrer ce qu’il a lu, quel outil il souhaite appeler, quels paramètres il utilisera et quel effet est attendu, car une confirmation générique ne donne pas assez de contexte au relecteur.

Injection de prompt via documents, tickets et systèmes d’entreprise

MCP facilite la connexion d’un agent à des systèmes déjà remplis de contenus : Jira, GitHub Issues, Slack, e-mails, wikis, CRM, documentation, bases de connaissances, logs et systèmes de ticketing. Ces contenus n’ont pas été écrits pour être des instructions sécurisées pour un modèle et peuvent contenir du texte malveillant, des fragments copiés par des utilisateurs, des exemples obsolètes, des commandes non vérifiées ou des données manipulées.

Un ticket de support pourrait inclure une phrase conçue pour forcer l’agent à ignorer les règles du projet. Un commentaire dans un ticket pourrait demander d’utiliser un endpoint administrateur. Un document interne pourrait rapporter une procédure ancienne avec des identifiants ou des permissions obsolètes. Une page web récupérée par l’outil pourrait contenir des instructions cachées. Si l’agent traite tout comme un contexte fiable, les outils deviennent un amplificateur de risque.

Les workflows sécurisés séparent les sources approuvées des contenus non fiables. Un ticket peut décrire un bug, mais ne doit pas modifier les politiques de l’agent. Une page externe peut fournir des informations, mais ne doit pas autoriser de commandes. Un log peut aider au diagnostic, mais ne doit pas introduire de secrets dans le contexte. Lorsque l’agent passe de la lecture à l’action, un contrôle explicite est nécessaire.

Outils qui lisent les dépôts, le système de fichiers et les secrets

Dans le contexte du développement logiciel, de nombreux serveurs MCP et connecteurs sont utiles précisément parce qu’ils lisent les dépôts, le système de fichiers, les configurations et la documentation technique. Le risque est qu’ils en lisent trop : un agent capable d’explorer librement le projet peut rencontrer des fichiers .env, des clés API, des jetons de déploiement, des fichiers de sauvegarde, des dumps, des logs, des certificats, des configurations cloud ou des données personnelles utilisées dans les tests.

Le problème ne se résout pas uniquement en faisant confiance au fournisseur ou au modèle. Si un secret est lu, copié dans un diff, inclus dans un log, envoyé à un outil ou inséré dans une réponse, le dommage est opérationnel et la remédiation inclut la suppression du code, la rotation de l’identifiant, la vérification des environnements et le contrôle des builds, des logs et des artefacts.

C’est pourquoi les outils de système de fichiers et de dépôts devraient partir d’une politique de refus par défaut (deny by default). Les chemins sensibles, les fichiers .env, les dumps, les sauvegardes, les exports de gestionnaires de secrets, les clés privées et les logs réels doivent être exclus ou accessibles uniquement avec une autorisation spécifique. Les identifiants utilisés par les serveurs MCP doivent être séparés de ceux personnels et de ceux de production : si un outil doit lire du code, il ne doit pas automatiquement lire aussi des secrets et des données.

Outils qui écrivent, suppriment ou déploient

Le seuil de risque change lorsque l’outil ne fait pas que lire. Écrire dans des bases de données, mettre à jour des tickets, envoyer des e-mails, ouvrir des PR, modifier des fichiers, supprimer des ressources, faire tourner des identifiants, lancer des pipelines ou déployer sont des actions ayant un impact réel, et même une modification apparemment mineure peut avoir des effets importants si elle survient dans le mauvais contexte.

Un agent peut décider de résoudre une erreur de build en ouvrant des permissions, en désactivant un contrôle, en élargissant le CORS, en modifiant des variables d’environnement ou en changeant des workflows CI/CD. Il peut fermer un ticket parce qu’il interprète mal la sortie d’un outil, envoyer un message avec des données internes, exécuter une migration sur la mauvaise base de données ou faire une pull request qui combine du code généré et des configurations non révisées.

Les actions d’écriture nécessitent un modèle plus strict : dry-run, staging, approbation explicite, logs, rollback et limites claires. L’utilisateur doit pouvoir voir les paramètres et les conséquences avant de confirmer. Pour le cloud, les bases de données, la CI/CD, les e-mails, le ticketing et les systèmes clients, il convient de séparer les outils en lecture seule des outils d’écriture et de désactiver par défaut les actions destructrices.

Isolement entre utilisateurs, locataires et environnements

Un serveur MCP peut être utilisé par plusieurs personnes, équipes, dépôts ou environnements. Si l’identité n’est pas propagée correctement, le serveur risque d’agir avec un compte technique trop large, créant des problèmes classiques d’autorisation : un utilisateur peut lire les données d’une autre équipe, un agent peut modifier des dépôts hors de sa portée, un environnement de test peut toucher à la production, un locataire peut en influencer un autre.

La sécurité doit être conçue par utilisateur et par ressource. Les appels d’outils doivent être attribuables à une personne ou à un service autorisé, les jetons doivent avoir des portées cohérentes avec le dépôt, le projet, le locataire et l’environnement, et les autorisations au niveau de l’objet ne peuvent être remplacées par une règle générique “l’agent est autorisé”. Si un outil agit sur des données multi-locataires, chaque requête doit préserver le locataire correct jusqu’à la ressource finale.

Dans les tests de pré-production, il faut simuler différents utilisateurs : un développeur avec des permissions administrateur ne suffit pas pour valider le flux. Il faut vérifier ce qui se passe avec un utilisateur standard, un rôle en lecture seule, un membre d’un autre locataire, un compte expiré, un jeton à portée réduite et un environnement de staging séparé de la production.

Supply chain des serveurs MCP

Installer un serveur MCP signifie introduire un composant qui a souvent accès à des données et à des actions. Il peut s’agir d’un paquet npm, d’un conteneur, d’un binaire, d’un script local, d’un service distant ou d’un connecteur SaaS. Si le serveur est compromis, mal entretenu, téléchargé depuis une source non vérifiée ou mal configuré, le risque ne se limite pas à son code : il concerne tout ce qu’il peut atteindre.

La supply chain des serveurs MCP doit être gérée avec les mêmes critères que ceux utilisés pour les composants applicatifs critiques. La provenance, le mainteneur, la version, le changelog, les dépendances, la licence, les vulnérabilités connues, les scripts d’installation, l’image de conteneur et la configuration d’exécution doivent être contrôlés. Un serveur utilisé pour lire de la documentation publique a des exigences différentes d’un serveur ayant accès à GitHub, à des bases de données, au cloud ou à des tickets internes.

Pour les environnements d’entreprise, une liste blanche ou un registre privé réduit le risque d’installations fortuites. Les serveurs MCP sensibles devraient tourner dans des bacs à sable ou des conteneurs avec un réseau, un système de fichiers et des secrets limités. Les mises à jour doivent être révisées car une nouvelle version peut modifier les outils exposés, les portées demandées, les sorties ou le comportement.

Journalisation, piste d’audit et réponse aux incidents

Sans logs, MCP devient difficile à gouverner. Si l’agent modifie un fichier, ouvre un ticket, lit des données ou appelle une API, l’équipe doit pouvoir reconstruire qui a lancé la session, quel outil a été appelé, avec quels paramètres, quelle sortie a été renvoyée, quelle action a suivi et quelle ressource a été touchée.

La journalisation doit être assez riche pour supporter la revue et la réponse aux incidents, mais ne doit pas se transformer en un nouveau point d’exposition : les entrées et sorties des outils peuvent contenir des données sensibles, des jetons ou des informations clients ; il faut donc prévoir la rédaction (redaction), la rétention, le contrôle d’accès et des alertes sur les outils les plus délicats.

Les événements à surveiller incluent les appels aux outils d’écriture, l’accès aux secrets, la lecture de données personnelles, l’utilisation de jetons privilégiés, les appels inter-locataires, les déploiements, les suppressions, les modifications de politiques cloud, les mises à jour de serveurs MCP et les échecs d’autorisation. Lorsque quelque chose tourne mal, l’équipe doit pouvoir désactiver rapidement un serveur, révoquer des jetons, faire tourner les identifiants et identifier les modifications produites.

Human-in-the-loop qui fonctionne vraiment

Insérer une confirmation humaine ne suffit pas si la confirmation ne contient pas d’informations utiles. Un message générique du type “l’agent veut utiliser un outil, confirmez-vous ?” ne permet pas d’évaluer le risque, les données et l’effet. Pour les actions sensibles, une confirmation lisible est nécessaire : outil, identité, ressource, paramètres, environnement, type d’action, sortie utilisée comme entrée et conséquence prévue.

Le niveau de confirmation doit suivre l’impact. Une requête en lecture seule sur de la documentation publique peut nécessiter peu de friction, tandis qu’un appel qui lit des données clients, modifie des rôles, lance des déploiements, met à jour l’IAM ou écrit dans la base de données nécessite une revue explicite. Pour les opérations répétitives, on peut utiliser des politiques et des approbations prédéfinies, mais seulement après avoir limité la portée et l’environnement.

Un bon “human-in-the-loop” ne sert pas à décharger la responsabilité sur le développeur : il sert à transformer une décision implicite de l’agent en une décision vérifiable de l’équipe. Lorsque l’action touche à la production, aux données réelles ou aux systèmes d’entreprise, la revue doit être proportionnelle au risque.

Ce qu’il faut vérifier avant la mise en production

Avant de mettre en production une application ou un workflow utilisant MCP, il convient de construire une carte des outils : quels serveurs MCP sont installés, s’ils sont locaux ou distants, qui les maintient, quels outils ils exposent, quelles données ils lisent, s’ils peuvent écrire, s’ils utilisent OAuth, des jetons statiques ou des identifiants de service, s’ils sont séparés par utilisateur, dépôt, locataire et environnement, et quels logs ils produisent.

La deuxième carte concerne les actions : quels outils peuvent modifier du code, des tickets, des bases de données, le cloud, la CI/CD, des e-mails ou des systèmes clients, lesquels nécessitent une approbation, lesquels ont un mode “dry-run”, lesquels peuvent être désactivés en urgence et lesquels sont disponibles même après que l’agent a lu des contenus non fiables.

La troisième carte concerne les frontières de confiance. Où passe la frontière de confiance entre l’utilisateur, le client, le serveur MCP, le fournisseur OAuth, l’API d’entreprise et la ressource finale ? Quelle identité est utilisée à chaque étape ? Un jeton est-il lié à la bonne ressource ? Une action est-elle attribuable au bon utilisateur ? Un locataire peut-il en influencer un autre ? Un environnement de staging peut-il toucher à la production ?

Checklist sécurité MCP pour les agents de codage

Inventorier les serveurs MCP, outils, clients, environnements et propriétaires.
Classer les outils en lecture seule, écriture, destructifs, privilégiés et sensibles.
Vérifier OAuth, indicateurs de ressources, audience, portée et absence de passage de jetons.
Appliquer le moindre privilège par utilisateur, projet, dépôt, locataire et environnement.
Séparer les identifiants personnels, techniques, de staging et de production.
Limiter l’accès au système de fichiers, aux dépôts, au gestionnaire de secrets, aux logs et aux données personnelles.
Valider les entrées et sorties des outils avec un schéma strict et des listes blanches.
Tester l’injection de prompt indirecte sur les tickets, documents, issues, e-mails, wikis et pages web.
Exiger une confirmation explicite pour l’écriture, la suppression, le déploiement, le cloud, les bases de données, les tickets et les e-mails.
Utiliser des bacs à sable ou des conteneurs pour les outils qui exécutent du code, des commandes ou accèdent au système de fichiers.
Journaliser les appels d’outils, paramètres, sorties, utilisateur, session, ressource, environnement et résultat.
Préparer le rollback, la révocation des jetons, la rotation des identifiants et la désactivation rapide des serveurs.

Quand impliquer ISGroup

Une revue interne peut suffire pour des expériences locales, des outils en lecture seule sur de la documentation non sensible ou des prototypes sans données réelles. Le risque change lorsque MCP entre dans un workflow proche du produit : dépôts d’entreprise, branches partagées, bases de données, cloud, tickets, CI/CD, systèmes clients, utilisateurs réels ou environnements exposés.

Si MCP ou outils externes accèdent à…	Risque principal	Contrôle conseillé
Dépôts, code, middleware, politiques, scripts	Modifications applicatives fragiles ou contournements logiques	Code Review
Outils runtime, prompts, documents, actions agentiques	Injection de prompt, détournement d’outils, sortie non validée	Software Assurance Lifecycle
Architecture agentique, frontière de confiance, identité, jetons	Frontières d’autorisation faibles	Secure Architecture Review
Web app, API ou tableaux de bord exposés	Abus de l’extérieur après la mise en production	Web Application Penetration Testing
Cloud, IAM, gestionnaire de secrets, pipelines, bases de données	Privilèges excessifs ou mauvaise configuration	Cloud Security Assessment

Si les outils influencent le code et le middleware, il faut regarder le diff. Si l’application est exposée, il faut vérifier le comportement réel via un Web Application Penetration Testing. Si le risque principal est l’architecture agentique, la priorité est de revoir l’identité, l’autorisation, la frontière de confiance, les jetons et la journalisation. Si l’utilisation d’agents et de MCP devient stable dans le cycle de développement, des contrôles répétables dans le temps sont nécessaires.

Évidences à préparer pour une vérification

Pour une vérification efficace, il faut la liste des serveurs MCP, les configurations, les outils exposés, les portées, les identifiants utilisés, les environnements, le diagramme des flux et les systèmes connectés. Il faut indiquer les outils en lecture seule et ceux en écriture, les actions soumises à approbation, les logs disponibles, les mécanismes de révocation, les politiques de bac à sable et les éventuelles listes blanches.

Côté applicatif, il faut les dépôts, les branches, les PR générées ou modifiées par des agents, les API exposées, les rôles, les locataires, les données traitées, les pipelines, le cloud, les bases de données et les intégrations. Si l’agent lit des tickets, des documents, des wikis, des e-mails ou des CRM, il faut clarifier quelles sources sont considérées comme fiables et lesquelles ne le sont pas. Si MCP a accès à la production, il est essentiel de distinguer ce qu’il peut faire en staging et ce qu’il peut faire sur les systèmes réels.

Ces évidences permettent d’éviter les contrôles génériques. Une vérification sur MCP doit suivre la chaîne complète : utilisateur, prompt, client, serveur MCP, autorisation, outil, sortie, action, log et ressource finale. C’est la seule façon de comprendre si un agent peut transformer une entrée manipulée ou une mauvaise décision en impact opérationnel.

Questions fréquentes

MCP est-il sûr à utiliser dans le développement logiciel ?
MCP peut être utilisé de manière sécurisée si les serveurs, outils, autorisations, jetons, bacs à sable et journalisation sont conçus correctement. Le risque dépend de ce que l’agent peut faire : lire de la documentation publique, modifier des dépôts, interroger des bases de données et agir sur le cloud sont des scénarios très différents.
Quelle est la différence entre MCP et une intégration API normale ?
Dans une intégration traditionnelle, le code applicatif décide quand appeler une API et avec quels paramètres. Dans un workflow agentique, le modèle peut choisir les outils et les paramètres en fonction du contexte, introduisant des risques spécifiques sur l’injection de prompt, les métadonnées des outils, les sorties non validées, l’autonomie et la piste d’audit.
Le consentement humain élimine-t-il le risque de détournement d’outils par l’agent ?
Il réduit le risque seulement si la confirmation affiche des informations utiles : outil appelé, identité, ressource, environnement, paramètres et effet prévu. Une confirmation générique ne suffit pas pour les opérations sur les données, les dépôts, le cloud, les tickets ou les bases de données.
Quels outils MCP sont les plus délicats ?
Ceux qui lisent des données sensibles, accèdent à des secrets, exécutent des commandes, modifient des fichiers, écrivent dans des bases de données, interagissent avec le cloud ou l’IAM, ouvrent ou ferment des tickets, envoient des e-mails, lancent des pipelines ou déploient.
Comment tester l’injection de prompt dans un workflow MCP ?
On prépare des contenus non fiables dans des tickets, documents, issues, e-mails ou pages récupérées par l’outil et on vérifie si l’agent les traite comme des données ou comme des instructions. Le test doit également observer les appels d’outils ultérieurs, pas seulement la réponse textuelle.
Quand une Secure Architecture Review est-elle nécessaire ?
Lorsque MCP connecte des agents à des systèmes d’entreprise, au cloud, à des dépôts, à des données réelles, à la CI/CD ou à plusieurs locataires. La revue doit vérifier l’identité, les autorisations, les portées, les frontières de confiance, la journalisation, l’isolement et la gestion des actions à fort impact.
Quand une Code Review est-elle nécessaire ?
Lorsque les outils externes influencent le code, le middleware, les politiques, les API, la validation, la gestion des secrets, les scripts ou les configurations. La Code Review aide à comprendre si l’agent a produit des modifications vulnérables à partir de sorties, de prompts ou d’outils non fiables.

[Callforaction-CR-Footer]

ISGroup Conseil en Cybersécurité