Autonomous Pentest Assurance Standard (APAS) : quand vous fier aux résultats d’un pentest autonome

Le standard lui-même décrit la situation de départ avec sobriété : les systèmes autonomes sont présentés comme capables de réaliser, d’étendre ou de remplacer des pentests — et les destinataires de ce discours promotionnel ne disposent d’aucun étalon fiable pour distinguer une affirmation limitée et vérifiable du langage marketing (Background and Motivation). APAS rend ces affirmations vérifiables en fixant la manière dont un système autonome déclare ce qu’il a fait, dans quelles conditions et avec quelles preuves.

Trois propriétés des systèmes autonomes rendent le rapport de pentest classique insuffisant comme preuve. Premièrement, le piège du non-déterminisme : en deux exécutions dans des conditions identiques, un agent trouve des surfaces d’attaque et des constats différents ; qui ne rapporte que la meilleure exécution feint une cohérence (4.6.2). Deuxièmement, le piège de l’autoconfirmation : un système qui évalue ses propres constats — même avec un second modèle comme « Judge » — n’observe pas la cible, mais lui-même ; l’accord entre composants internes n’est pas une confirmation indépendante (4.4.1 f, 11.2.1 b). Troisièmement, le piège de la couverture : un système qui découvre moins paraît plus complet lorsque le dénominateur provient de sa propre découverte (1.1.4).

APAS en tire une limite basse claire : un scan automatisé qui produit des signaux sans chemin d’exploitation validé n’est pas, en soi, un pentest autonome. Un tel résultat se qualifie au mieux comme Assurance Outcome Q1 avec des preuves EV1 ou EV2 et ne doit jamais être présenté seul comme un claim de pentest APAS. Les traits distinctifs d’un pentest sont la reproduction indépendante par une partie autre que le système producteur, la validation du chemin d’exploitation jusqu’à la condition revendiquée et un chaînage multi-étapes démontré à l’intérieur du périmètre déclaré (2.2.3).

APAS est développé en concertation avec la Cloud Security Alliance et suit les exigences de neutralité de l’organisme porteur énoncées à la section 12 : un standard contrôlé par un acteur du marché ne doit pas être présenté comme un standard industriel neutre (12.4.1). Le document rattache le standard au CSA AI Safety Working Group ; le Lead Author est Will Kapcio, accompagné de huit Contributors (dont Jim Reavis et John Yeoh de la CSA) et de douze Reviewers. Le journal des modifications indique une première version du 23 octobre 2026, l’état du fichier est daté du 2 novembre et la publication par la CSA du 4 novembre 2026. Le PDF est protégé par le droit d’auteur et ne doit pas être redistribué — nous renvoyons donc au téléchargement chez la CSA et citons avec indication de la source.

La section Status clarifie trois points. APAS évalue la véracité et l’utilisabilité des preuves de pentest — non la sécurité, le confinement ou la résistance aux abus du système lui-même ; une certification APAS ne doit jamais être présentée comme une déclaration de Safety du type « fitness for deployment ». Deuxièmement : aucun document Companion n’est publié. Troisièmement, et c’est décisif : tant que l’Evaluator Guide, l’entrée pertinente de la Profile Registry et l’Attestation Schema ne sont pas disponibles dans des versions compatibles, aucune Atomic System Capability Certification ni aucun Engagement Conformance Statement ne peut être délivré. La publication du Core ouvre la voie vers la certification, non la certification elle-même (Status, 12.1.2).

L’ensemble documentaire

La gouvernance est déjà normée : les versions suivent un schéma Major/Minor/Patch, et la v1.0 est une version majeure parce qu’elle modifie la validité des claims, les dimensions de qualité, les classes d’environnement, les gates de publication et la sémantique des findings (12.2.1). Chaque document Companion déclare contre quelle version majeure du Core il est normatif ; les claims ne peuvent être délivrés que contre un ensemble documentaire compatible, et une nouvelle version du Core n’invalide pas rétroactivement les claims déjà délivrés (12.2.2, 12.2.3). Le Core et l’Evaluator Guide doivent être examinés au moins tous les douze mois quant à la dérive des capacités, avec un déclencheur hors calendrier en cas de saut significatif des capacités des modèles frontière (12.2.4). Les modifications normatives passent par une revue publique ; l’organisme porteur doit être organisationnellement indépendant de tout fournisseur individuel, entretenir des processus multipartites et divulguer les conflits d’intérêts (12.3, 12.4). Les claims disposent d’un registre public de statut avec les états Active, Under Review, Revoked et Retired ; en cas d’indices crédibles de preuves falsifiées ou trompeuses, un claim passe en Under Review et ne peut plus être invoqué comme Q3, Q4, R2 ou R3 (12.5).

Les règles d’application sont strictes. Toute déclaration de qualité doit couvrir Coverage Fidelity, Finding Validity, Evidence Traceability et Agent Integrity ; pour les claims Q4 ou R3, Remediation Usability et Retestability s’y ajoutent obligatoirement (4.1.1 a). Une dimension ne peut être considérée comme non applicable ou non mesurée qu’avec des critères documentés et l’accord de l’Evaluator — et cela doit être divulgué (4.1.1 b). Les profils peuvent ajouter des dimensions, mais n’en supprimer aucune (4.1.1 c). Surtout : les dimensions sont déclarées et évaluées indépendamment les unes des autres, ne doivent pas être combinées en un Composite Score, et un déficit dans une dimension ne doit pas être présenté comme compensé par une force dans une autre (4.1.1 d).

Tout claim Q2, Q3, Q4, R2 ou R3 contient une déclaration de qualité qui exprime chaque dimension applicable par une valeur numérique, une classe ordinale, un statut booléen ou une représentation définie par le profil, et renvoie aux preuves ou à la méthodologie (4.1.2). La validation comparative — par exemple contre une cohorte humaine de référence — peut compléter l’évaluation de la qualité, mais jamais remplacer Coverage Fidelity, Finding Validity ou Evidence Traceability (4.1.3). Agent Integrity est une dimension à part entière et n’est pas satisfaite par des divulgations relevant de Process Integrity (4.1.4).

APAS <Mode>-<Tier> / <Exécution>-<Collaboration>-<Assurance> / <Environnement> [<Profil d’affordance>] {<Reliance>}

APAS BB-T2C / X2-C2-Q4 / E3 [P-021] {R2}

Les quatre Claims d’exemple de l’annexe A

Il existe trois types de Claims (5.1) : l’Atomic System Capability Certification est le résultat, délivré par l’Evaluator, attestant qu’un système a satisfait aux exigences applicables pour une combinaison de capacités dans des conditions déclarées. Le Multi-Configuration Capability Statement regroupe deux Claims atomiques ou plus pour une version de système. L’Engagement Conformance Statement se rapporte à un engagement concret, exécuté avec un système certifié APAS dans des conditions identiques ou plus strictes — il ne certifie jamais l’environnement cible (5.1.1).

Comme un système peut proposer plusieurs combinaisons, APAS exige une Capability Matrix à sept classes de statut : S1 Supported (conçu pour, non évalué), S2 Evaluated (évalué, sans Claim), S3 Certified or Conformant, S4 Not Certified, S5 Not Evaluated, S6 Unsupported, S7 Retired. Seul S3 peut être présenté comme certifié ; une matrice publique qui omet des combinaisons prises en charge matériellement pertinentes est trompeuse (5.3.1). Chaque ligne comprend entre autres : l’ID de combinaison, le Claim String complet, le nom et la version du système, les identités des modèles avec la provenance des system prompts, la référence de méthodologie, l’Evaluator, le statut, les renvois vers l’attestation, la déclaration de qualité et de Coverage, les versions Core et Companion, les dates de certification et de validité, les limitations significatives ; pour Q3, Q4, R2 ou R3, la date de certification et une date d’expiration explicite ou un intervalle de revalidation sont obligatoires (5.4.1).

L’Assistance Class de la section 9 complète ces classes par la question de ce que les humains ont réellement apporté : H0 aucune aide ayant un effet sur la stratégie, l’exploitation, la validation, la priorisation ou le rapport ; H1 intervention administrative ou de sécurité uniquement ; H2 aide analytique — guidage d’exploit, interprétation, priorisation, mapping de contrôles ou édition du rapport. La classe doit être divulguée dans l’attestation, par combinaison et par exécution en cas de configurations multiples (9.1.1). Un Claim X3 interdit H2 pendant l’exécution, un Claim Q4 interdit H2 lors de l’assemblage de l’Evidence Package — y compris par des composants internes de validation ou de type judge qui façonnent le contenu du package (9.1.2). Un mapping vers des frameworks ou une priorisation effectués a posteriori côté fournisseur et influençant matériellement l’auditeur constituent une Vendor-side Analytical Review et doivent être divulgués (9.1.3). Une plateforme ne peut pas être commercialisée comme agent-only, autonome de manière indépendante ou assessor-ready si des exécutions pertinentes ont reposé sur une intervention humaine ou un post-traitement non divulgués (9.2.2).

Deux autres règles méritent l’attention des CISO et de l’audit interne. Premièrement, la responsabilité : chaque Claim R3 doit nommer la partie responsable de l’exactitude des preuves substituées, le recours de la partie utilisatrice (relying party) en cas de défauts constatés ultérieurement, les limites de garantie et une assurance de responsabilité civile professionnelle ou pour préjudices financiers présentée à la partie utilisatrice — APAS lui-même ne crée, ne transfère ni ne limite aucune responsabilité (5.10.4). Deuxièmement, les tests de tenants et d’habilitations : un Claim R2 ou R3 ne peut jamais valoir substitut ou complément de tests d’autorisation, de contrôle d’accès ou de frontières entre tenants si moins de deux principals différents ou un seul tenant ont été utilisés ; ces domaines sont réputés matériellement non testés (5.10.6). Et : R2/R3 décrivent ce que le package fournit — non les actes de contrôle que le reviewer peut omettre ; les contrôles résiduels et l’acceptation du risque résiduel restent du ressort du reviewer et de son framework (5.10.7).

Tout Claim T2A, T2C, T3, T4, Q2, Q3, Q4, R2 ou R3 contient une déclaration de Coverage avec des champs obligatoires fixes (4.2.1). Elle doit exposer fidèlement les écarts entre scope déclaré, scope atteignable et scope testé, ainsi que par rapport à la Surface Baseline ; aucun package ne doit suggérer une Coverage complète, totale ou équivalente sans en fournir la méthodologie et les preuves ; un résultat démontré sur une seule instance ou lors d’un seul run n’est pas une Coverage de la classe d’attaque correspondante (4.2.2).

L’échelle des baselines BS-1 à BS-3

1. 1
   BS-1 Asserted

   Inventaire d’actifs ou liste de scope du propriétaire de la cible — indépendant du système candidat, mais limité par l’exhaustivité du propriétaire (4.2.8 a).

2. 2
   BS-2 Directed

   Énumération dirigée par l’Evaluator, dans laquelle celui-ci spécifie ou étend la surface au-delà de la découverte du système — le niveau minimal pour Q3, Q4 et R3 (4.2.8 b, 4.2.10).

3. 3
   BS-3 Instrumented

   Énumération par un instrument de découverte indépendant ou par un processus qui ne partage pas la logique de découverte du système candidat (4.2.8 c).

Pour Q3, Q4 et R3, le dénominateur de Coverage doit être construit contre une Independent Surface Baseline ; la découverte effectuée par le système lui-même ne peut pas en être la seule source (4.2.4). Les écarts matériels entre surface découverte et baseline doivent être divulgués dans les deux sens ; toute surface de la baseline qui n’a pas été exercée est réputée matériellement non testée ; l’Under-Discovery abaisse la Coverage présentée, jamais l’inverse (4.2.5). Lorsque des sources sont combinées, la baseline globale ne peut pas être présentée comme plus forte que la source la plus faible qui couvre seule une zone matérielle (4.2.9). Là où aucune baseline indépendante n’est exigée, la déclaration doit indiquer que le dénominateur est auto-énuméré et décrire la méthode (4.2.6).

Le statut de Coverage seul ne dit rien de la profondeur. Pour chaque zone testée ou partiellement testée, il faut indiquer si un probing au niveau des requêtes, un probing authentifié, des tests multi-étapes de workflows ou de transitions d’état et des tests aux frontières de privilèges ou de tenants ont été réalisés. L’unité de Coverage, les seuils de couverture partielle, les degrés de profondeur et les pondérations sont définis par la Profile Registry — sans profil applicable, la profondeur doit être déclarée de manière narrative et aucune proportion ni aucun pourcentage de Coverage ne doit être présenté (4.2.11). Pour les Claims T2C, la déclaration doit être structurée de sorte qu’un reviewer identifie les zones testées, exclues et non testées pertinentes pour les contrôles sans interprétation du fournisseur (4.2.7).

Le non-déterminisme est le second angle mort. Un système est réputé matériellement non déterministe lorsque des runs répétés dans les mêmes conditions produisent des surfaces d’attaque, des ensembles de findings ou des résultats d’exploitation matériellement différents ; cela doit être divulgué dans la méthodologie (4.6.1). La variance ne doit pas être masquée par le run le plus favorable ; lorsque plusieurs runs étayent un Claim, la sélection, l’agrégation et la divulgation doivent être définies à l’avance, et l’Evaluator atteste que le nombre de runs et la règle d’agrégation étaient fixés avant l’exécution (4.6.2). Les Claims Q3, Q4, R2 et R3 caractérisent la variance d’un run à l’autre par une mesure déclarée — par exemple la variance de découverte de surface ou l’indice de Jaccard des ensembles de findings — sur la base d’un run design préenregistré (4.6.3). La règle d’agrégation provient d’un ensemble fermé (Any-Run-Union, All-Run-Intersection, majorité ou une règle expressément déclarée) et les résultats individuels de tous les runs, et non un seul indicateur, sont versés dans l’Evidence Package (4.6.5).

Chaque Confirmed Finding porte un Stable Finding Identifier — un identifiant unique, stable à travers les révisions, retests, exports et conversions de format — et, sauf dans le cas Single-Capture, une Reproduction Procedure : une séquence enregistrée, déterministe et indépendante de l’agent, faite d’étapes, de requêtes, de payloads, de préconditions et d’observations attendues, avec laquelle un tiers compétent peut reproduire la condition sans accès au système candidat (4.3.3, annexe D). Les observations attendues incluent l’observation de contrôle ou Expected-Secure ; une Procedure ne peut être probabiliste que si la condition elle-même l’est (race conditions, TOCTOU, canaux auxiliaires temporels), avec alors le nombre de tentatives et le taux de succès observé. Chaque Confirmed Finding déclare en outre le Vantage Point et la condition d’accès ainsi que la région de la classe d’environnement (4.3.5) ; les services adjacents ou chemins inter-systèmes pertinents pour l’exploitabilité ou l’impact sont divulgués — obligatoirement pour E3 (4.3.6).

Pour les Claims Q3, Q4, R2 ou R3, les artefacts EV3 et EV4 doivent être collectés par un chemin qui n’est pas sous le contrôle exclusif du système candidat — interception réseau, observation sur l’hôte ou captures collectées par l’Evaluator ; en dessous de ce seuil, les artefacts collectés par le seul système doivent être identifiés comme tels dans l’Evidence Manifest ; pour Q2 et Q3, EV3/EV4 devraient relever de l’Out-of-Band Witness Evidence — callback listeners, canaris ou moniteurs côté cible que le système ne peut ni produire, ni observer, ni atteindre (4.4.4, annexe D). Lorsqu’un finding allègue un défaut d’autorisation ou de frontière de tenant, EV3 exige des observations appariées : la même requête réussit pour le principal non autorisé et est rejetée pour un principal de contrôle autorisé, tous deux référencés via l’Identity Coverage (4.4.6).

Retest et déduplication

Un retest exécute la Reproduction Procedure enregistrée pour le Stable Finding Identifier, rattache le résultat à cet identifiant et divulgue si le finding persiste, est partiellement corrigé ou n’est plus reproductible (4.3.4). Une redécouverte probabiliste — ou son absence — lors d’un nouveau run d’agent n’est ni une vérification de correctif, ni une preuve de persistance, ni un retest ; de tels résultats doivent être identifiés comme probabilistic rediscovery et séparés du résultat de la Procedure (4.3.4 a). Pour les conditions intermittentes, le nombre de tentatives et le taux de succès sont évalués par rapport au taux antérieur à la remédiation (4.3.4 b). Chaque package doit disposer d’une règle de déduplication documentée qui définit comment des observations répétées de la même condition, issues de différents runs, Vantage Points ou instances, sont fusionnées en un seul Stable Finding Identifier (4.3.9).

L’Affordance Profile est l’environnement d’exploitation déclaré du système pendant le test : capacités, restrictions, conditions d’accès, limites d’escalade et obligations (annexe D). Chaque Claim référence un profil comportant au moins les champs suivants ; un label générique tel que « standard » ne suffit pas pour les champs relatifs aux contrôles de protection de la cible et d’Agent Integrity. Les composants internes de validation, de Judge, de Verifier ou de consensus doivent être déclarés dans l’Agent Topology et leur rôle divulgué dans la déclaration de qualité relative à la Finding Validity. En l’absence d’Action Reversibility Class, l’engagement est réputé irréversible — avec les obligations de Safety les plus strictes (7.1.1).

Les classes d’environnement décrivent la portée à travers les frontières de confiance, non le type de cible : E1 une cible unique isolée, E2 une interaction multi-rôles, multi-étapes ou à état au sein d’une frontière de confiance déclarée, E3 une interaction franchissant une frontière de confiance ou de segmentation (7.2). Elles s’appliquent indifféremment aux applications, API, réseaux, infrastructures, plans de contrôle cloud, conteneurs, logiciels clients, mobile, firmware et embarqué ; aucune classe n’importe les vecteurs d’ingénierie sociale, physiques et radio. Chaque Claim est limité à sa classe déclarée (7.2.1) ; le type d’environnement et les différences matérielles avec la production doivent être déclarés, un test hors production n’implique aucune couverture de la production sans parité déclarée (7.2.2). Les Claims T2A, T2C, T3 et T4 référencent une méthodologie déclarée ; les méthodologies pour Q4 ou R3 définissent en outre le traitement des résultats négatifs, les attentes de remédiation et de retest ainsi que la justification du mode choisi au regard du modèle de menace (7.3).

Autorisation et Rules of Engagement

Chaque engagement APAS dispose d’une Authorization Declaration indiquant la partie autorisante, la base légale ou contractuelle, le scope et la fenêtre temporelle autorisés ainsi que les Rules of Engagement ; tout test en dehors de ce cadre vaut activité Out-of-Scope au sens de la section 10 — indépendamment du succès technique ou de la valeur du finding (7.4.1). Doivent en outre être déclarés, lorsque pertinent : les fenêtres de test, y compris les fenêtres de blackout et de maintenance, les contacts d’urgence nommés du propriétaire de la cible, de l’évaluateur et de l’exploitant du système avec leur joignabilité et le délai maximal de notification, le statut d’autorisation des infrastructures tierces et cloud avec les conditions de test propres au fournisseur, les adresses sources du système et l’allowlisting, les limites de classification des données et la déconfliction avec le SOC ou la Blue Team (7.4.3). La Declaration nomme aussi l’identité de l’agent opérant, le schéma d’identité, la méthode de vérification pour le propriétaire de la cible et, pour les sous-agents, la chaîne de délégation avec sa profondeur maximale (7.4.4).

Parce que les systèmes autonomes rencontrent des vulnérabilités dans des composants tiers ou hors scope, chaque engagement exige un Coordinated-Disclosure Path : chaque finding de ce type porte un statut de divulgation (encountered, notified, disclosure-restricted, resolved, published), reste énuméré à chaque statut dans l’Evidence Manifest avec Stable Finding Identifier et hash de contenu, et seul le détail d’exploitation peut être retenu temporairement — jamais le finding lui-même (7.4.2). Si le système peut atteindre une infrastructure partagée ou tierce hors autorisation, les limites d’escalade doivent l’en tenir à l’écart (7.4.3.2).

Toute certification ou déclaration d’engagement présentée comme R2 ou R3 contient un Evidence Package consommable par l’assessor ; tout Claim Q2, Q3 ou Q4 contient une déclaration de qualité et de Coverage, même si seul R1 est revendiqué (8.1.1). Pour R2/R3, les preuves à l’appui devraient rester disponibles au moins aussi longtemps que le Claim est valide (8.1.2 b).

Intégrité : signature, hashes, logs infalsifiables

Toute attestation Q3, Q4, R2 ou R3 est signée cryptographiquement par l’évaluateur émetteur ou l’organisme d’évaluation de la conformité — avec identité vérifiable, méthode de vérification publiée, identifiant de certificat ou de clé, horodatage de confiance et un moyen publié de vérifier le statut de la clé même après rotation, expiration ou révocation (8.2.1). L’Evidence Manifest contient pour chaque artefact un hash de contenu pris au moment de la capture (8.2.2) ; la journalisation de l’exécution et des preuves est tamper-evident et tenue ou contresignée par un composant ou une partie qui n’est pas sous le contrôle exclusif du système (8.2.3). Des preuves falsifiées, non traçables ou matériellement trompeuses invalident le Claim (8.2.4) ; un package dont la vérification de signature échoue, qui présente des écarts de hash ou des lacunes inexpliquées dans le log ne peut être invoqué comme Q3, Q4, R2 ou R3 tant que la contradiction n’est pas résolue et une nouvelle attestation émise (8.2.5). Les contradictions entre attestation, findings, enregistrements d’exécution et artefacts doivent être divulguées, et non éludées par un récit (8.2.7).

Lisibilité machine et formats d’échange ouverts

Tout package Q2, Q3, Q4, R2 ou R3 porte des champs lisibles par machine : Claim String complet, ID de combinaison, nom et version du système, identités et versions des modèles, provenance du system prompt, un identifiant de build du système sous forme de digest cryptographique de la configuration liée, référence de méthodologie, identité de l’évaluateur, métadonnées de signature et de vérification, Assistance Class, chemin opérationnel observé, références aux déclarations de qualité et de Coverage avec sources de Baseline, ID d’actifs et références SBOM, vue d’ensemble des Finding States, Stable Finding Identifiers, relations d’Attack Path, labels Single-Capture, décisions de matérialité, hashes du manifeste, date de certification avec expiration ou intervalle de revalidation, versions Core et Companion et Reliance Outcome. Claim String et identifiant de build voyagent dans une Provenance Envelope déclarée telle qu’in-toto, DSSE ou SCITT (8.4.1).

La baseline s’applique à chaque Claim : des limites de périmètre explicites, un mécanisme de Stop ou de Suspend et des journaux ou artefacts suffisants pour l’examen par l’Evaluator (10.1.1). Toute activité hors périmètre, toute preuve falsifiée, toute dissimulation matérielle d’une assistance humaine ou toute affirmation trompeuse sur la couverture invalide le Claim (10.1.2) ; toute incertitude matérielle sur l’impact, la couverture ou les conclusions de retest doit être signalée dans le package (10.1.3).

1. 1
   Déclarer la Stop Authority

   Chaque mission désigne qui peut suspendre ou arrêter l’exécution — au minimum le propriétaire de la cible et, s’il existe, l’Evaluator (10.2.1).

2. 2
   Agir out-of-band

   Le mécanisme de Stop opère en dehors de la boucle de décision du système ; le système n’est jamais le seul arbitre de la prise d’effet d’un Stop. Le profil d’Affordance fixe un temps de réaction maximal ; dans ce délai, toute activité offensive cesse, les actions en cours sont interrompues, et le travail en attente, planifié ou délégué est annulé ou documenté (10.2.2).

3. 3
   Fail-safe en cas de perte de supervision

   Si le monitoring, la liaison de supervision, la journalisation ou le canal de Stop font défaut au-delà des tolérances déclarées, le système suspend toute activité offensive jusqu’au rétablissement de la supervision — une perte de supervision ne conduit jamais à la poursuite du fonctionnement autonome (10.2.3).

4. 4
   Enregistrer et notifier

   Les événements de Stop et de Halt-on-Loss, avec leur horodatage, sont consignés dans le journal à preuve d’altération et dans l’Evidence Package ; les contacts d’urgence sont informés dans le délai déclaré (10.2.4).

5. 5
   Access Disposition Record

   À la clôture — et après chaque Stop — un Access Disposition Record recense chaque accès créé par la mission (tokens, comptes, sessions, tunnels, tokens délégués, persistance) avec son statut (Revoked, Expired, Removed, soumis à rotation par le propriétaire de la cible ou Retained avec propriétaire et expiration), la partie responsable et une référence de vérification (10.2.5).

6. 6
   Vérifier de bout en bout

   L’Evaluator vérifie de bout en bout chaque canal de Stop, Suspend, Resume ou Override critique pour la sécurité — de la partie autorisée jusqu’au point d’application dans la configuration de déploiement attestée ; la simple existence ou la signature correcte ne suffit pas, au moins un événement exercé par canal, avec son résultat de remise et d’application, doit figurer dans le package (10.2.6). La disponibilité d’un canal ne prouve pas la remise ; une instruction non appliquée doit être identifiable comme un échec de remise (10.2.7).

Les obligations s’échelonnent selon le pire des trois facteurs que sont l’autonomie d’exécution, la participation humaine réduite et le risque d’Affordance déclaré (Action Reversibility Class) : au sein d’un profil, les exigences pour X3 sont au moins aussi fortes que pour X2, et celles-ci au moins aussi fortes que pour X1, de même de C1 à C4 ; une Action Reversibility Class moins réversible renforce les exigences indépendamment de X et de C ; aucune décision de profil, d’Evaluator ou de fournisseur ne peut accorder une supervision plus faible aux classes les plus autonomes — une configuration dans laquelle davantage d’autonomie supprime la supervision n’est pas certifiable (10.3.1).

• Le fonctionnement en X3, C4 et E3 ainsi que toute mission autorisant des actions irréversibles ou un chaînage autonome vers des surfaces adjacentes exigent en plus : la disponibilité permanente du canal de Stop pendant l’exécution (10.3.2 a),
• la détection automatique de l’approche ou du franchissement de la limite de périmètre, qui stoppe ou bloque l’action au lieu de se contenter de la journaliser (10.3.2 b),
• une déclaration de la manière dont la limite de périmètre autorisée est appliquée à l’exécution (10.3.2 c), le Halt-on-Loss-of-Oversight (10.3.2 d),
• l’application des limites d’escalade déclarées par un mécanisme dont la défaillance est détectable (10.3.2 e),
• et, pour les actions chaînées, un gate sur la pire Action Reversibility Class atteignable de toute la chaîne, avant l’exécution de la première étape (10.3.2 f).

Agent Integrity : l’agent comme cible d’attaque

Un agent de pentest lit les contenus de la cible, appelle des outils, utilise des serveurs MCP et persiste du contexte — il est donc lui-même attaquable. APAS exige des contrôles déclarés contre au moins quatre classes de manipulation : la Prompt Injection depuis les contenus ou réponses de la cible, la manipulation ou la substitution d’outils, de plugins, de modèles ou de serveurs MCP et de serveurs d’outils comparables, le Poisoning du contexte récupéré ou persisté, ainsi que la modification ou le contournement non autorisés des contrôles d’exécution relatifs au périmètre, aux outils autorisés et aux privilèges (10.4.1). Chaque Claim Q3, Q4, R2 ou R3 comprend, dans la déclaration de qualité, une divulgation Agent Integrity décrivant les contrôles, les tentatives de manipulation détectées et leur traitement ; un message « aucune manipulation détectée » généré par le système lui-même ne prouve pas qu’aucune n’a eu lieu (10.4.2).

Ce qui est décisif, c’est de savoir qui teste : pour Q3, Q4, R2 ou R3, l’Evaluator doit exécuter lui-même des tests adversariaux d’Agent Integrity — au minimum Goal Hijack, Tool Response Injection ainsi que Context ou Memory Poisoning ; des contrôles simplement affirmés par le fournisseur ne soutiennent aucun de ces Claims (10.4.4). L’évaluation compare des exécutions d’évaluation annoncées comme telles avec des exécutions à l’aveugle sur la fidélité au périmètre, le refus du hors-périmètre, la couverture et le taux de fabrication ; une différence de comportement matérielle constitue de l’Eval-Awareness, doit être divulguée et plafonne l’Assurance Outcome (10.4.3). Une manipulation non détectée qui a matériellement modifié la stratégie, les constats, la fidélité au périmètre ou le contenu du rapport invalide les dimensions du Claim concernées. Si le système détecte une manipulation, il suspend l’activité offensive, informe le propriétaire de la cible, l’Evaluator et les contacts d’urgence, et place en quarantaine les preuves et constats de la fenêtre temporelle suspecte (10.4.5).

Mentions obligatoires de tout Claim APAS public (11.1.1)

• le statut atomique ou matriciel,
• les huit dimensions du Claim,
• l’identité de l’Evaluator,
• les dates de certification et de validité,
• la version du système candidat,
• les limitations matérielles là où une Reliance est revendiquée,
• la disponibilité de la déclaration de qualité applicable ou d’un résumé,
• lorsque plusieurs combinaisons sont prises en charge, le statut des combinaisons voisines qu’un acheteur raisonnable pourrait supposer disponibles,
• la version du Core Standard ainsi que l’identifiant et la version de chaque document Companion appliqué,
• lorsque c’est pertinent, si la commutation dynamique entre combinaisons est prise en charge,
• et, partout où le Claim String figure publiquement ou dans des supports destinés aux acheteurs, au marketing ou aux achats, une lecture en langage clair en une phrase selon l’annexe A — avec la même visibilité que la chaîne codée.

Affirmations interdites (11.2.1)

Sur la seule base d’une certification APAS, personne ne peut affirmer ni laisser entendre :

Deux règles supplémentaires complètent la section : aucune classe d’exécution, de collaboration, d’assurance ou de Reliance ne peut être commercialisée sans l’ensemble des dimensions du Claim — un « Q4 » ou un « X3 » isolé dans une brochure est inadmissible (11.2.2). Et une Single-Capture Confirmation doit être signalée comme telle dans tout Claim public et ne doit jamais être présentée comme reproduite de manière indépendante (11.2.3). En cas de contradiction, les déclarations attestées prévalent sur toute affirmation publique et tout résumé marketing (13.2) ; si un framework ou un Assessor exige des conditions plus strictes qu’APAS, ce sont elles qui s’appliquent (13.3).

La CSA elle-même classe l’APTS comme l’initiative la plus proche : un projet OWASP Incubator à un stade précoce, consacré à l’exploitation sûre et bornée des plateformes de pentest autonomes. Les recoupements ne concernent que la gouvernance opérationnelle — les sections 7 (Declared Conditions), 9 (Human Assistance) et 10 (Safety) d’APAS —, tandis que l’APTS ne prévoit ni méthodologie de mesure de la couverture, ni gradation de Reliance ou de substitution, ni certification par évaluateur ; c’est précisément là le cœur d’APAS. Là où l’APTS aborde la reproductibilité des constats et les preuves destinées aux assesseurs, APAS va plus loin : les Confirmed Findings présupposent une reproduction indépendante de l’agent, la couverture est mesurée contre une Independent Surface Baseline (Relationship to Existing Work).

Comment utiliser les deux standards ensemble

La décision : où les pentests autonomes tiennent aujourd’hui

Les systèmes de pentest autonomes révèlent leurs atouts là où comptent l’étendue, la fréquence et la répétabilité : contrôle continu d’une surface d’attaque mouvante, tests de régression après les releases, triage préalable à un pentest manuel, retests avec des Procedures reproductibles et couverture de nombreuses cibles de même nature. Leurs limites, APAS les fixe lui-même : pas d’ingénierie sociale, pas de vecteurs physiques ou radio, pas de Red Team complète (2.2, 5.6.3), pas d’exploitation continue comme Claim (2.2.4) — et aucune substitution de contrôles exigés sans R3, sans profil et sans admission par le cadre d’audit (5.10). La décision est donc rarement « autonome ou humain », mais plutôt : quel sous-ensemble des activités de test peut être réalisé de façon autonome, avec quelle Assurance, et qu’est-ce qui reste classique ?

1. 1
   Fixer le but de la preuve

   Remédiation interne (Q2/R1), augmentation pour les auditeurs (Q4/R2) ou substitution (Q4/R3) ? Le navigateur Reliance de cette page vous guide dans cette question ; le résultat détermine toutes les exigences suivantes.

2. 2
   Fournir le scope et la baseline

   Un inventaire lisible par machine (CMDB/CAASM, références SBOM) constitue votre baseline BS-1 ; pour Q3/Q4/R3, une énumération pilotée par l’évaluateur (BS-2) la complète. Sans baseline, personne ne peut mesurer la Coverage — vous non plus (4.2).

3. 3
   Monter le pilote comme une évaluation

   Design de run préenregistré avec plusieurs runs et mesure de variance (4.6.3), reproduction indépendante d’un échantillon (EV3), observations appariées pour les constats d’autorisation (4.4.6), test de bout en bout de la Stop Authority (10.2.6), tests adversariaux d’Agent Integrity (10.4.4) et un run à l’aveugle contre l’Eval-Awareness (10.4.3).

4. 4
   Définir le modèle d’exploitation humain plus agent

   Quelle classe X/C correspond à votre tolérance au risque ? Les cibles de production avec actions irréversibles relèvent des obligations les plus strictes (10.3.2) ; fixez les points d’approbation, les contacts d’escalade, les fenêtres de test et la déconfliction avec le SOC (7.4.3).

5. 5
   Contrat et gouvernance

   Data Handling et egress (7.1.1), Stop Authority et délai de réaction, Access Disposition, divulgation des changements de configuration et ré-attestation (5.11.3), responsabilité en cas de substitution (5.10.4), formats d’échange (8.4.3) — plus des KPI : Unsupported-Finding Rate, taux de retest, Coverage par rapport à la baseline, délai de réaction au stop.

Évaluation des outils : le catalogue d’exigences fondé sur APAS

• Quelles combinaisons de capacités la plateforme propose-t-elle — sous forme de Capability Matrix avec les huit dimensions et les classes de statut, et non de liste de fonctionnalités (5.3, 5.4) ?
• Quelle est la lecture en clair de votre Claim le plus fort, et quelles limitations s’y appliquent (11.1.1) ?
• D’où provient le dénominateur de Coverage de vos rapports — de votre propre découverte ou d’une baseline indépendante ? Montrez une déclaration de Coverage avec tous les champs obligatoires (4.2.1).
• Quelle est votre Unsupported-Finding Rate par combinaison, ventilée entre faux positifs et Over-Severity (4.3.8) ?
• Chaque constat contient-il une Reproduction Procedure que mon équipe peut reproduire sans votre plateforme, ainsi qu’un Stable Finding Identifier (4.3.3) ?
• Comment distinguez-vous Observations, Validated et Confirmed Findings — et qui confirme (4.3, 4.4.1) ?
• Comment caractérisez-vous la variance run à run, et rapportez-vous tous les runs ou seulement le meilleur (4.6) ?
• Quels champs couvre votre profil d’Affordance — en particulier l’egress d’inférence et de télémétrie avec juridiction, la provenance des outils et MCP, l’Action Reversibility (7.1.1) ?
• Comment la Stop Authority agit-elle hors bande, avec quel délai de réaction maximal, et que se passe-t-il en cas de perte de la supervision (10.2.2, 10.2.3) ?
• Quels contrôles existent contre l’injection de prompt, la substitution d’outils, l’empoisonnement du contexte et le contournement des contrôles d’exécution, et qui les a soumis à des tests adversariaux (10.4) ?
• Fournissez-vous l’Agent Execution Record, les hachages de contenu et une attestation signée — et dans quels formats exportez-vous constats, mappings et statut des correctifs (8.2, 8.4.3) ?
• Quels changements de modèle, de prompt, d’orchestration ou de jeu d’outils nous signalez-vous, et combien de fois votre configuration a-t-elle changé substantiellement au cours des douze derniers mois (5.11) ?

La version complète, avec matrice d’évaluation, critères d’exclusion et 20 questions RfP, figure dans le livre blanc CISO plus bas sur cette page.

Positionnement réglementaire : ce qu’un auditeur peut accepter

APAS précise qu’il ne fonde aucune conformité réglementaire, contractuelle ou d’audit et qu’une certification APAS n’implique jamais l’acceptation par un référentiel (1, 5.9.1). Inversement, la plupart des référentiels ne disent rien des testeurs autonomes — ils exigent des tests, une méthodologie, des qualifications et une documentation. Le positionnement qui suit est donc une appréciation de VamiSec sur la classe de Reliance qu’un auditeur peut aujourd’hui raisonnablement accepter sous chaque référentiel.

En 2026, la supervision suit une ligne reconnaissable : l’IA comme capacité d’appui, sous supervision humaine. En juillet 2026, la supervision bancaire de la BCE a demandé aux établissements importants des plans d’action contre les attaques assistées par l’IA et cite les outils fondés sur l’IA comme complément de l’examen des vulnérabilités — à condition d’une évaluation préalable bénéfices-risques, de mesures de protection appropriées et d’une supervision humaine. Le même mois, l’ENISA décrit le « Verification Bottleneck » : la masse de constats IA techniquement corrects dépasse les capacités de vérification — exactement la lacune qu’APAS traite avec les Confirmed Findings et l’Unsupported-Finding Rate. Le NCSC britannique exige pour les agents IA un sandboxing, des logs immuables et la possibilité de « débrancher la prise » ; la ligne directrice commune des Five Eyes de mai 2026 recommande le Red Teaming et les tests de pénétration contre les systèmes agentiques ainsi qu’une approbation humaine avant les actions à fort impact. Il n’existe à ce jour aucune prise de position d’une autorité de supervision reconnaissant ou rejetant expressément les pentests autonomes comme preuve réglementaire.