Les tests de sécurité par IA peuvent-ils remplacer le SAST, le DAST et les tests d'intrusion ?

La vraie question est de savoir où un agent mérite votre confiance. Je lui fais confiance pour élargir la couverture des revues, relier des indices entre plusieurs fichiers, générer des tests ciblés et transformer une trace de scanner difficile à lire en correctif compréhensible par un développeur. Je ne lui fais pas confiance pour déduire les règles d'autorisation d'une entreprise à partir des noms de routes, prouver que chaque frontière entre tenants tient, ou décider qu'un étrange parcours financier est abusif sans qu'une personne ait énoncé la règle. Considérez l'agent comme un réviseur actif au sein d'un programme de tests à plusieurs niveaux, pas comme le programme lui-même.

Une revue par agent est un interprète, pas une nouvelle catégorie de test

Un agent d'IA change la façon dont les preuves sont collectées et comprises, il ne crée pas un nouveau type de preuve. S'il lit le code source sans exécuter l'application, il réalise une forme souple de revue statique. S'il envoie des requêtes vers une cible en cours d'exécution, il fait des tests dynamiques. S'il explore des objectifs, change de tactique et suit des comportements inattendus, il ressemble à un testeur d'intrusion, mais cette ressemblance ne lui donne ni son autorité ni son contexte métier.

Cette distinction compte lorsqu'un fournisseur affirme que son agent « remplace les scanners ». Demandez ce que le système peut réellement observer. Reçoit-il le dépôt complet, le code généré, les options de build, les politiques d'infrastructure et les fichiers de verrouillage des dépendances ? Peut-il s'authentifier comme plusieurs utilisateurs et vérifier l'état de la base de données après chaque requête ? Sait-il quelles actions sont interdites par la politique plutôt que simplement absentes de l'interface ? Une explication bien présentée ne peut pas réparer des données manquantes.

Les agents savent vraiment relier des signaux faibles. Une règle classique peut signaler qu'un paramètre de requête atteint un générateur de requêtes. Un agent peut examiner l'encapsuleur, remarquer qu'un appel omet le prédicat du tenant, rédiger une requête de test et expliquer pourquoi l'assistant supposé sûr ne l'est pas dans ce chemin. Il peut aussi écarter un cas lorsque la valeur passe par une véritable API paramétrée. C'est un meilleur triage, pas la preuve que l'analyse statique ou dynamique est devenue obsolète.

La frontière nette se situe entre revue et vérification. La revue demande : « Cette implémentation semble-t-elle dangereuse au vu des éléments que je peux observer ? » La vérification demande : « Dans des conditions définies, cet acteur peut-il provoquer un résultat interdit ? » L'IA aide dans les deux cas, mais un contrôle de sécurité doit indiquer quelle affirmation il formule. Les équipes souffrent lorsqu'une observation de revue éloquente est promue au rang d'exploit vérifié, ou lorsqu'une tentative d'exploitation échouée est prise pour une preuve de sûreté.

Le comportement des modèles ajoute une autre distinction : la capacité ne garantit pas la répétabilité. Un agent peut découvrir un chemin subtil lors d'une exécution et le manquer après un changement de modèle, de prompt, d'index de récupération ou de politique d'outils. Conservez les prompts, les autorisations d'outils, les fichiers récupérés, les requêtes générées et l'identifiant du modèle lorsqu'un résultat compte. Transformez ensuite les découvertes confirmées en tests dont la condition de réussite ne dépend pas de la redécouverte de sa propre idée par le modèle.

Le SAST conserve la couverture reproductible du code source

Le SAST reste le moyen le moins coûteux d'appliquer des contrôles stables à chaque changement dans une grande base de code. Il peut recenser les sources et les destinations, imposer des API interdites, inspecter le flux de données et signaler la révision exacte qu'il a analysée. Une règle déterministe produit le même résultat demain, ce qui importe lorsqu'un contrôle de publication a besoin d'une raison vérifiable pour accepter ou refuser.

Un agent ajoute un contexte dont un moteur de règles manque souvent. Il peut suivre des encapsuleurs propres au projet, lire les commentaires avec scepticisme, comparer un gestionnaire à ses voisins et proposer une requête pour un nouveau motif. Il peut repérer des omissions suspectes, par exemple neuf points de terminaison qui appellent authorizeProject() alors qu'un dixième charge directement l'enregistrement. Il est également utile lorsque du code généré ou un framework inconnu met en échec un ensemble de règles standard.

Mais la couverture du code source par un agent est généralement plus difficile à prouver. Les fenêtres de contexte, le classement de récupération, les fichiers ignorés, les artefacts générés et les délais d'expiration des outils peuvent laisser du code non lu. Demander « examine ce dépôt pour détecter les injections » ne démontre pas que chaque destination a été atteinte. Un rapport SAST peut au moins indiquer quels fichiers, quelles règles et quelle révision ont été analysés. Un agent a besoin d'un registre de couverture équivalent avant de pouvoir prendre en charge un contrôle obligatoire.

NIST SP 800-218 formule ici une recommandation raisonnable : utilisez l'analyse de code tôt et vérifiez manuellement les fonctionnalités et mesures de sécurité. La valeur vient de l'association. Des règles stables détectent les formes de défauts connues à chaque commit ; l'agent examine les exceptions, écrit des tests de régression ciblés et aide à ajuster les règles quand le même motif revient. Retirer le SAST parce que l'agent a trouvé plusieurs bogues astucieux échange une étendue mesurable contre des anecdotes impressionnantes.

Le SAST voit aussi du code qu'un test en cours d'exécution n'atteindra peut-être jamais : chemins d'erreur, indicateurs de fonctionnalité, utilitaires de migration, points de terminaison d'administration dormants et branches propres à une plateforme. Il ne peut pas vous dire si l'environnement déployé active ces chemins. Cette incertitude est une raison d'ajouter des preuves d'exécution, pas d'abandonner la couverture statique.

Il existe des limites à ce qui doit figurer dans une règle SAST bloquante. Un motif précis pour une primitive cryptographique interdite peut bloquer immédiatement. Une heuristique large qui demande si un contrôle d'autorisation « semble suffisamment proche » devrait en général créer une tâche de revue jusqu'à ce que l'équipe mesure sa précision. Les agents peuvent aider à transformer une heuristique en règle en collectant de vrais exemples, des contre-exemples et les fonctions d'encapsulation courantes de cette base de code. Le contrôle reste ainsi strict sans apprendre aux développeurs à l'ignorer.

Les correctifs générés méritent le même examen que les constats. Un modèle peut faire taire une trace de contamination en ajoutant une validation à la mauvaise couche, intercepter une exception puis échouer en mode ouvert, ou remplacer un appel dangereux en modifiant le comportement. Exécutez la preuve originale sur le correctif, lancez les tests fonctionnels habituels et examinez le nouveau contrôle à l'endroit où la confiance est établie. Un nouveau scan propre prouve seulement que la règle d'origine ne correspond plus.

Le DAST prouve un comportement que le dépôt ne peut pas révéler

Le DAST observe l'application qui s'exécute réellement, y compris les règles de proxy, les en-têtes, la sérialisation, les middlewares d'authentification, les valeurs par défaut du framework et les erreurs de déploiement. Une revue du code source peut dire qu'un point de terminaison semble protégé. Un test dynamique peut montrer que la route de production contourne le middleware parce qu'une passerelle réécrit son chemin.

C'est là qu'un agent peut rendre les tests dynamiques bien moins grossiers. Donnez-lui une description d'API, des identités de test, des périmètres autorisés et un environnement jetable, et il peut construire des séquences de requêtes au lieu d'envoyer des charges utiles génériques partout. Il peut transmettre un identifiant de ressource d'une réponse à la suivante, renouveler une session, comparer deux rôles et vérifier si une écriture a modifié les lectures ultérieures. Le DAST classique peine souvent avec ces parcours à état.

L'agent a toujours besoin de limites d'exploitation strictes. Un crawler ne sait pas si l'envoi d'un e-mail, la création d'une expédition ou l'appel d'une intégration payante est sans danger. Un environnement de test peut encore se connecter à de vrais services. Définissez les hôtes, comptes, débits de requêtes, actions destructrices et conditions d'arrêt autorisés hors du prompt du modèle, puis imposez-les dans l'exécuteur. Une phrase qui dit « évitez les actions dangereuses » n'est pas un contrôle.

Gardez une base dynamique classique pour les contrôles bien compris, comme les en-têtes de sécurité, les fichiers exposés, les entrées réfléchies, les sondes d'injection courantes et la configuration TLS. Ces contrôles sont peu coûteux, comparables d'une version à l'autre et faciles à suivre dans le temps. Laissez l'agent consacrer son budget aux chemins authentifiés et aux comportements en chaîne. Si les deux systèmes couvrent la même sonde simple, conservez celui dont les preuves sont plus claires et la variabilité plus faible.

Le DAST peut aussi donner une fausse impression d'exhaustivité, car il ne signale que ce qu'il a atteint. Enregistrez avec le résultat la couverture des routes, les identités utilisées, les indicateurs de fonctionnalité et les données initiales. Un scan propre avec un compte presque vide prouve très peu pour une application dont les branches dangereuses n'apparaissent qu'après une approbation, une invitation, une facturation ou une importation de données.

La configuration de l'authentification mérite ses propres preuves. Notez comment le test a obtenu chaque session, quels seconds facteurs ou contrôles d'appareil ont été contournés dans l'environnement de test et si les jetons ont les mêmes revendications et la même durée de vie que les jetons de production. Un jeton administrateur créé à la main peut ouvrir une couverture utile tout en sautant exactement les transitions de session et de privilèges qu'il faut tester. Gardez ces raccourcis visibles dans le rapport.

Les nouveaux tests dynamiques doivent commencer par la séquence de requêtes enregistrée, pas par un nouveau crawl autonome. Rejouez la preuve confirmée sur le build corrigé, vérifiez que l'effet interdit a cessé, puis faites varier les entrées proches afin de détecter un filtre trop étroit. Laissez ensuite l'agent explorer. Cet ordre distingue « le correctif bloque l'exploit connu » de l'affirmation plus large selon laquelle toute la catégorie de défauts a été supprimée.

Les tests d'autorisation ont besoin d'identités et de résultats interdits

L'autorisation ne consiste pas à constater qu'un point de terminaison a renvoyé 403 une fois. Un test utile indique qui agit, quel objet est ciblé, quelle opération est tentée et quel résultat doit rester impossible. Un agent peut générer les combinaisons, mais le propriétaire produit et le réviseur sécurité doivent fournir la politique.

OWASP ASVS indique que les applications doivent appliquer le contrôle d'accès dans une couche de service de confiance et respecter le moindre privilège pour les fonctions et les données. Je suis d'accord avec l'exigence de couche de service, mais les équipes la vérifient souvent trop étroitement. Elles testent le gestionnaire HTTP visible et oublient les tâches en arrière-plan, les exports, les index de recherche, les abonnements websocket et les URL directes de stockage d'objets. La même politique doit survivre à chaque chemin menant à l'objet.

Une petite matrice exécutable révèle davantage qu'une vague instruction de « tester les IDOR ». Le fragment shell suivant suppose un environnement jetable, deux jetons bearer et un document appartenant à l'utilisateur A. Il vérifie le statut ainsi que l'absence du marqueur secret de A dans la réponse de B :

base_url="https://test.example.invalid"
doc_id="d_1042"

curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $TOKEN_B" \
  "$base_url/api/documents/$doc_id" \
  -o /tmp/body.json

status="$(awk 'NR==1 {print $2}' /tmp/headers.txt)"
test "$status" = "403" || test "$status" = "404"
! grep -q "A_ONLY_MARKER" /tmp/body.json

Le résultat attendu est l'absence de sortie et un statut de sortie zéro. Un échec CI doit conserver le statut, le corps expurgé, l'identité agissante, le propriétaire cible, la route et la révision du build. Ne conservez ni identifiants réels ni données de réponse sans rapport.

Faites ensuite varier une dimension à la fois : lecture ou mise à jour, ID direct ou recherche, appartenance active ou révoquée, route normale ou export, jeton utilisateur ou jeton de service. L'agent peut produire et exécuter efficacement ces cas. Une personne doit vérifier que la matrice correspond à la politique et qu'un 404, un 403, un résultat vide ou un objet expurgé est le résultat voulu. Sinon, l'agent peut célébrer un comportement que l'entreprise considère comme une violation.

Les preuves négatives demandent de la prudence. Une mise à jour refusée peut tout de même révéler l'existence d'un objet par le temps de réponse, le texte d'erreur ou un compteur de version. Une lecture refusée peut incrémenter un compteur de vues ou écrire dans un audit des métadonnées secrètes. Décidez quels effets secondaires sont autorisés, puis vérifiez-les. Des tests de sécurité qui n'inspectent que la réponse peuvent manquer un canal d'énumération utile ou une écriture dommageable.

Testez aussi les changements de politique pendant une session. Retirez un utilisateur d'un projet, transférez la propriété, désactivez un compte ou réduisez un rôle de service, puis réutilisez d'anciens jetons et connexions ouvertes. Le délai de révocation attendu doit venir de la politique produit. « À terme » ne se teste pas, et une révocation immédiate peut être inutile, mais l'équipe doit choisir une limite et la vérifier dans les requêtes API, le travail en file, les téléchargements et les abonnements en direct.

L'isolation des tenants échoue hors du chemin de requête évident

L'isolation des tenants exige des tests aux frontières du stockage, du cache, des files, de la recherche, des fichiers, de l'analytique et de l'administration. L'échec courant n'est pas l'absence de tenant_id dans le point de terminaison principal de liste. C'est un chemin secondaire qui copie, indexe, met en cache ou exporte des données sans transmettre le contexte du tenant.

Commencez avec deux tenants contenant des enregistrements volontairement semblables et un marqueur sans équivoque chacun. Utilisez des utilisateurs, sessions et, lorsque l'architecture le permet, identifiants de service séparés. Exercez la création, la lecture, la mise à jour, la suppression, la liste, la recherche, l'export, l'import, l'accès aux pièces jointes, la livraison des notifications et le traitement en arrière-plan. Après chaque action, examinez la réponse visible par l'utilisateur et l'état persistant. Une requête rejetée qui met quand même une tâche inter-tenant en file est un échec.

Les agents aident parce qu'ils peuvent suivre un identifiant à travers les couches et générer des permutations fastidieuses pour les humains. Ils peuvent remarquer que la clé de cache utilise document_id alors que la requête de base de données utilise à la fois tenant_id et document_id. Ils peuvent comparer un worker d'export au gestionnaire interactif et demander pourquoi un seul définit le contexte au niveau des lignes. Ce sont des gestes de revue à forte valeur.

Ils font aussi une hypothèse dangereuse : les noms impliquent des frontières. Une fonction appelée getTenantDocument peut accepter un argument de tenant arbitraire venant de la requête. Une politique de base de données peut exister dans les migrations mais pas sur une nouvelle table. Un filtre de recherche peut être appliqué après le comptage des résultats et révéler l'activité d'un autre tenant. La vérification doit examiner le prédicat appliqué puis tenter une lecture et une écriture inter-tenant.

Ne laissez pas l'agent créer son propre oracle en lisant le même code que celui qu'il teste. Déduisez l'accès attendu d'une table de politique indépendante, maintenue avec les exigences produit. Si l'implémentation et le test comprennent mal la même règle, ils seront parfaitement d'accord tout en exposant des données.

Les chemins asynchrones ont besoin d'assertions différées. Déclenchez un export, une notification, une miniature ou une tâche d'indexation en tant que tenant A, changez la propriété ou l'appartenance avant l'exécution du worker, puis examinez où le résultat arrive. Décidez si le worker doit utiliser l'autorité capturée lors de la requête ou vérifier de nouveau l'autorité actuelle lors de l'exécution. Les deux choix peuvent être justes pour une opération donnée, mais un mélange accidentel crée des fuites et des pistes d'audit défaillantes.

Les outils d'administration méritent des identités distinctes et des assertions de journalisation. L'accès du support traverse souvent les frontières entre tenants par conception, donc une simple règle « un tenant différent doit échouer » est fausse. Vérifiez que l'opérateur a le rôle et le contexte de dossier requis, que la politique visible par le client est respectée, que l'accès expire et que l'événement d'audit identifie l'opérateur au lieu d'usurper le client.

La logique métier exige un scénario d'abus

Les tests de logique métier commencent par un scénario interdit : un utilisateur reçoit une valeur, une autorité ou un état auquel il ne devrait pas avoir droit en réalisant des actions valides dans un ordre ou une combinaison invalide. Les libellés génériques de vulnérabilités sont trop faibles. Le testeur doit savoir comment invitations, approbations, quotas, remboursements, crédits, transferts de propriété et annulations doivent interagir.

Le OWASP Web Security Testing Guide demande aux testeurs d'essayer de sauter des étapes du parcours, de répéter des fonctions, de falsifier des requêtes, de modifier les délais et de détourner des fonctions valides. Son ancienne introduction à la logique métier dit sans détour que l'automatisation par scanner ne peut pas fournir les connaissances ni la créativité propres à l'application. Les agents modernes améliorent l'automatisation, mais ne suppriment pas ce manque de connaissance. Un modèle peut suggérer qu'un coupon est réutilisable ; il ne peut pas savoir si cette réutilisation relève d'une promotion ou d'une fraude tant que quelqu'un n'a pas énoncé la règle.

Donnez à l'agent un modèle d'état avec les transitions autorisées et les invariants. Pour un parcours d'approbation, un invariant peut dire : « Un demandeur ne peut pas approuver son propre paiement, y compris après un transfert de propriété. » Demandez-lui ensuite de générer des séquences avec changements de rôles, requêtes dupliquées, annulation, nouvelle tentative, concurrence et sessions obsolètes. L'agent peut explorer bien plus de séquences qu'une personne n'en exécutera manuellement.

Les cas difficiles concernent les conséquences hors de la réponse HTTP. Deux demandes de rachat simultanées peuvent toutes deux réussir, puis une réconciliation ultérieure peut en retirer une. Une annulation peut arrêter la tâche visible sans révoquer un téléchargement signé. Une invitation acceptée après que l'invitant a perdu l'accès peut créer une appartenance orpheline. Les tests doivent observer les registres, files, autorisations d'objets et états ultérieurs, pas seulement les codes de statut.

Les testeurs humains gardent leur place en remettant en question le modèle énoncé. Ils demandent si le personnel de support peut combiner des fonctions inoffensives, si un opérateur peut influencer sa propre piste d'audit, ou si un objet « expiré » reste utilisable par un autre canal. Un agent travaille dans les objectifs et outils qu'il reçoit. Une personne peut remarquer que les objectifs omettent la partie dangereuse de l'activité.

Le risque lié aux dépendances dépasse une version vulnérable

Les tests de dépendances posent quatre questions distinctes : quels paquets sont présents, si leurs versions connues comportent des vulnérabilités signalées, si le build a obtenu les artefacts prévus et si l'application expose réellement le comportement vulnérable. L'analyse de composition logicielle (SCA) et les contrôles de provenance répondent aux trois premières plus sûrement qu'une revue conversationnelle seule.

Un agent est utile après l'inventaire. Il peut examiner comment une dépendance est appelée, déterminer si la fonction concernée est accessible, trouver un contrôle compensatoire et rédiger un correctif de mise à niveau avec des tests de régression. Il peut aussi signaler des comportements de paquets risqués sans identifiant de vulnérabilité, par exemple un script d'installation qui obtient un accès réseau ou une nouvelle bibliothèque qui reçoit des secrets dans son environnement.

Ne demandez pas au modèle de se souvenir des données de vulnérabilités actuelles. Fournissez-lui une source d'avis horodatée, le fichier de verrouillage résolu et l'inventaire des artefacts construits. La mémoire d'un modèle n'est pas une base de données de vulnérabilités, et un manifeste de paquet ne prouve pas ce qui a été livré. La provenance SLSA fait une distinction proche : elle décrit où, quand et comment un artefact a été produit. Elle ne le déclare pas sûr.

L'accessibilité peut réduire la priorité de triage, mais elle ne doit pas effacer la responsabilité. Les indicateurs de fonctionnalité changent, le code mort revient et des dépendances indirectes sont appelées de façon inattendue. Consignez pourquoi un constat a été différé, quelle version et quel chemin d'appel ont été évalués, et quel événement doit le rouvrir. L'agent peut conserver ce raisonnement, tandis qu'un inventaire déterministe surveille l'événement.

Les noms de paquets créent aussi des pièges d'identité. Une dépendance portant le nom attendu peut venir du mauvais registre, un fichier de verrouillage peut pointer vers un emplacement modifiable, ou une étape de build peut télécharger du code absent du manifeste. Vérifiez les sources résolues, les hachages, les signatures lorsque l'écosystème les prend en charge, ainsi que l'accès réseau pendant le build. Un agent peut expliquer les écarts, mais le système de build doit imposer les sources qu'il accepte.

Les mises à niveau ne sont pas automatiquement des changements sûrs. Une version de sécurité peut modifier l'analyse, les valeurs d'autorisation par défaut ou la sérialisation d'une manière qui casse l'application. Générez une reproduction minimale pour l'avis, appliquez la mise à niveau dans une branche isolée et lancez la preuve de sécurité ainsi que les tests fonctionnels. Les éléments obtenus appuient une décision ; un modèle qui affirme que la nouvelle version « devrait être compatible » ne le fait pas.

Les faux positifs sont un problème de conception des preuves

Un constat mérite le temps des développeurs seulement lorsqu'il comporte une affirmation, des preuves, un impact et un chemin reproductible. Les rapports générés par IA semblent souvent complets tout en omettant l'un de ces éléments. Un texte de remédiation fluide rend les preuves faibles plus difficiles à repérer.

Exigez que chaque constat d'agent identifie la révision et l'environnement analysés, le composant concerné, les préconditions de l'attaquant, la frontière de sécurité franchie, le résultat observé ou déduit, les étapes de reproduction et l'incertitude. Distinguez les constats de code source déduits des exploits exécutés. Si l'agent n'a pas pu exécuter l'application, il doit le dire dans le constat, pas cacher cette limite dans une note générale de scan.

Appliquez ensuite un vocabulaire simple de qualification : confirmé, probable, contexte nécessaire, non reproductible, risque accepté ou corrigé. « Faux positif » doit signifier que l'affirmation de sécurité est erronée, pas que l'équipe n'aime pas la gravité ou a choisi de différer le travail. Mélanger ces décisions détruit le retour d'information. L'agent ne peut pas apprendre quelle règle a échoué si chaque ticket indésirable reçoit le même libellé.

L'IA peut réduire le bruit en regroupant les traces dupliquées, en vérifiant les mécanismes de neutralisation et en retestant après un correctif. Elle peut aussi amplifier le bruit en produisant dix variantes convaincantes d'un même soupçon faible. Dédupliquez par cause racine et frontière, pas par URL. Un contrôle de propriété manquant utilisé par huit points de terminaison est un défaut d'ingénierie avec huit points d'exposition.

Suivez la précision par catégorie et source de test. Si les signalements de cross-site scripting générés par l'agent sont souvent valides mais que ses affirmations sur les conditions de concurrence se reproduisent rarement, traitez-les différemment. Ne réduisez pas les performances à un seul score pour des types de défauts sans rapport. Un contrôle doit échouer sur les preuves et la politique, pas sur l'adjectif de confiance du modèle.

La responsabilité boucle le processus. Chaque constat accepté a besoin d'une personne ou d'une équipe responsable de la remédiation, d'une méthode de retest attendue et d'une preuve conservée qu'un autre testeur peut exécuter. Si le rapport ne vit que dans une conversation avec un agent, il disparaîtra lorsque la conversation, le modèle ou le fournisseur changera. Le travail de sécurité devient durable lorsque les preuves survivent à l'outil qui les a produites.

La confidentialité compte aussi pendant le triage. Le code source, les corps de requêtes, les journaux et les échantillons de base de données peuvent contenir des identifiants ou des données clients. Réduisez au minimum ce que l'agent reçoit, expurgez les transcriptions conservées, séparez les données de test des données de production et appliquez les règles approuvées de l'organisation en matière de traitement des données au fournisseur de modèles et à ses outils. Une meilleure détection ne justifie pas de copier un incident de production entier dans un prompt non contrôlé.

Un test d'intrusion humain teste les hypothèses autour du test

Un testeur d'intrusion compétent change le plan lorsque l'application contredit le brief. C'est la partie que les agents n'ont pas remplacée. Cette personne interroge les responsables, lève les ambiguïtés des règles, remarque les raccourcis opérationnels, demande une autre identité et décide quand un comportement étrange mérite une chaîne d'expériences plus longue.

Les humains sont aussi responsables de leur jugement face à des preuves incomplètes. Ils peuvent distinguer une action techniquement possible d'un chemin d'attaque crédible, expliquer une défaillance composée aux dirigeants et aux ingénieurs, et négocier une preuve sûre lorsque l'exploitation pourrait endommager des données. Un agent autonome doit s'arrêter à la frontière fixée par son opérateur. S'il l'élargit silencieusement, il devient un autre risque de sécurité.

Cela ne signifie pas que chaque version nécessite une mission externe d'une semaine. Utilisez les tests humains là où changement et conséquences se rejoignent : nouveau modèle d'autorisation, architecture multi-tenant, parcours de paiement ou de crédit, plan d'administration, intégration sensible, migration majeure ou lancement public. Planifiez des travaux périodiques plus larges selon le risque, puis retestez les correctifs importants. Les versions de routine ont toujours besoin d'une couverture automatisée.

Donnez au testeur la sortie de l'agent, les traces SAST, la couverture DAST, les notes d'architecture, les comptes de test et les hypothèses non résolues. L'agent peut gérer la reconnaissance et les variations répétitives tandis que le testeur poursuit les comportements surprenants. Le temps humain devient ainsi plus productif sans faire semblant qu'il est superflu.

Méfiez-vous des promesses de « test d'intrusion autonome » mesurées au nombre de constats. Dix constats d'injection familiers ne valent pas un chemin démontré à travers l'attribution de rôles, une autorisation obsolète et un stockage d'export. Jugez le travail selon les frontières testées, la qualité des preuves et les hypothèses importantes remises en question.

Demandez qui est responsable du nettoyage avant le début de la mission. Les comptes de test, fichiers téléversés, messages en file, rôles temporaires et indicateurs de fonctionnalité modifiés peuvent survivre au scan. Un responsable humain doit approuver les preuves destructrices, garder le contact avec les opérations et vérifier la restauration. L'agent peut suivre un script de nettoyage, mais il ne peut pas décider qu'un état de production inexpliqué peut être supprimé sans danger.

Un bon testeur indique aussi ce qui n'a pas pu être testé. Builds mobiles manquants, rôles indisponibles, limites de débit, rappels tiers et environnements instables réduisent le niveau d'assurance. Les agents ont tendance à contourner les obstacles et à présenter les chemins qu'ils ont terminés. Le rapport final doit mettre les exclusions en évidence afin qu'un résultat propre ne soit pas confondu avec une couverture complète.

Construisez un contrôle unique à partir de plusieurs types de preuves

Le bon programme attribue un rôle à chaque méthode et fait converger leurs résultats vers les mêmes exigences de sécurité. Utilisez le SAST pour les motifs de code déterministes et une large couverture des changements. Utilisez la SCA et la provenance pour les faits liés aux dépendances et au build. Utilisez le DAST pour le comportement déployé et les contrôles de base à l'exécution. Utilisez les agents pour relier les preuves, explorer les parcours authentifiés, créer des tests et améliorer le triage. Utilisez les humains pour définir la politique, remettre en cause les hypothèses métier et examiner les changements à fortes conséquences.

Une politique de publication peut alors être précise. Bloquez un build lorsqu'une règle déterministe de haute gravité correspond à un chemin non approuvé, lorsqu'un invariant d'autorisation obligatoire échoue, lorsqu'un marqueur inter-tenant apparaît ou lorsqu'un exploit confirmé reste ouvert. Envoyez les constats incertains d'agents en revue avec une échéance fondée sur l'exposition. Ne laissez pas la confiance déclarée par un modèle décider si la production est livrée.

Gardez les preuves portables. Exportez les constats, les tests générés, les transcriptions de requêtes, les versions d'outils, les révisions, les identités, la couverture et les qualifications dans des formats que l'équipe peut examiner sans l'agent. C'est important pour les audits, les analyses d'incident, les changements de fournisseurs et le jour ordinaire où une mise à jour de modèle change le comportement.

Pour les applications créées par chat, la même séparation s'applique. Koder.ai peut générer des applications web, serveur et mobile et exporter leur code source, mais les logiciels générés ont toujours besoin d'exigences de sécurité explicites et de tests indépendants sur le résultat déployé. La création rapide rend un contrôle clair encore plus utile, car l'architecture et le code peuvent évoluer vite.

Faites fonctionner l'agent en continu, mais transformez ses meilleures découvertes en tests de régression déterministes. Chaque contournement d'autorisation confirmé doit devenir un cas de politique. Chaque fuite entre tenants doit ajouter un invariant à la frontière qui a échoué. Chaque règle bruyante doit recevoir une qualification consignée. Avec le temps, l'agent doit laisser le système de test plus précis qu'il ne l'a trouvé.

Ne demandez pas quel outil unique l'emporte. Demandez si chaque affirmation importante dispose de preuves indépendantes : le chemin de code a été examiné, le comportement déployé a été exercé, la règle métier vient d'un responsable et une personne a remis en question les hypothèses là où un échec ferait mal. Si l'une de ces lignes reste vide, un « tout est bon » généré par IA ne la remplit pas.