Autonomous Pentest Assurance Standard (APAS): wann Sie autonomen Pentest-Ergebnissen trauen dürfen

Die Ausgangslage beschreibt der Standard selbst nüchtern: Autonome Systeme werden als fähig beworben, Pentests durchzuführen, zu erweitern oder zu ersetzen — und die Adressaten dieser Werbung haben keinen verlässlichen Maßstab, um eine begrenzte, verifizierbare Behauptung von Marketingsprache zu trennen (Background and Motivation). APAS macht solche Behauptungen prüfbar, indem er festlegt, wie ein autonomes System deklariert, was es getan hat, unter welchen Bedingungen und mit welcher Evidenz.

Drei Eigenschaften autonomer Systeme machen den klassischen Pentest-Bericht als Nachweis unzureichend. Erstens die Nicht-Determinismus-Falle: Ein Agent findet in zwei Läufen unter identischen Bedingungen unterschiedliche Angriffsflächen und Befunde; wer nur den besten Lauf berichtet, täuscht Konsistenz vor (4.6.2). Zweitens die Selbstbestätigungs-Falle: Ein System, das seine eigenen Befunde bewertet — auch mit einem zweiten Modell als „Judge“ — beobachtet nicht das Ziel, sondern sich selbst; Einigkeit interner Komponenten ist keine unabhängige Bestätigung (4.4.1 f, 11.2.1 b). Drittens die Coverage-Falle: Ein System, das weniger entdeckt, erscheint vollständiger, wenn der Nenner aus seiner eigenen Entdeckung stammt (1.1.4).

APAS zieht daraus eine klare Grenze nach unten: Automatisiertes Scanning, das Signale ohne validierten Exploit-Pfad erzeugt, ist für sich genommen kein autonomer Pentest. Solcher Output qualifiziert höchstens als Q1-Assurance-Outcome mit EV1- oder EV2-Evidenz und darf nie allein als APAS-Pentest-Claim dargestellt werden. Die Unterscheidungsmerkmale eines Pentests sind unabhängige Reproduktion durch eine andere Partei als das erzeugende System, die Validierung des Exploit-Pfads bis zur behaupteten Bedingung und nachgewiesenes mehrstufiges Chaining innerhalb des deklarierten Scope (2.2.3).

APAS wird in Abstimmung mit der Cloud Security Alliance entwickelt und folgt den Anforderungen an neutrale Trägerschaft in Abschnitt 12: Ein Standard, der von einem Marktteilnehmer kontrolliert wird, darf nicht als neutraler Industriestandard dargestellt werden (12.4.1). Als Heimat nennt das Dokument die CSA AI Safety Working Group; Lead Author ist Will Kapcio, dazu acht Contributors (darunter Jim Reavis und John Yeoh von der CSA) und zwölf Reviewer. Das Änderungsprotokoll weist die Erstfassung vom 23. Oktober 2026 aus, der Dateistand ist der 2. November, die CSA-Veröffentlichung der 4. November 2026. Das PDF ist urheberrechtlich geschützt und darf nicht weiterverbreitet werden — wir verlinken deshalb auf den Download bei der CSA und zitieren mit Quellenangabe.

Der Status-Abschnitt stellt drei Dinge klar. APAS bewertet die Wahrhaftigkeit und Nutzbarkeit von Pentest-Evidenz — nicht die Sicherheit, Eindämmung oder Missbrauchsresistenz des Systems selbst; eine APAS-Zertifizierung darf nie als Fitness-for-Deployment-Safety-Aussage dargestellt werden. Zweitens: Kein Companion-Dokument ist veröffentlicht. Drittens und entscheidend: Solange Evaluator Guide, der einschlägige Eintrag der Profile Registry und das Attestation Schema nicht in kompatiblen Versionen vorliegen, darf keine Atomic System Capability Certification und kein Engagement Conformance Statement ausgestellt werden. Die Veröffentlichung des Core öffnet den Zertifizierungspfad, nicht die Zertifizierung (Status, 12.1.2).

Der Dokumentensatz

Die Governance ist bereits normiert: Versionen folgen einem Major/Minor/Patch-Schema, v1.0 ist eine Major-Version, weil sie Claim-Validität, Qualitätsdimensionen, Umgebungsklassen, Veröffentlichungsgates und Finding-Semantik ändert (12.2.1). Jedes Companion-Dokument deklariert, gegen welche Core-Major-Version es normativ ist; Claims dürfen nur gegen einen kompatiblen Dokumentensatz ausgestellt werden, und eine neue Core-Version entwertet bereits ausgestellte Claims nicht rückwirkend (12.2.2, 12.2.3). Core und Evaluator Guide sind mindestens alle zwölf Monate auf Fähigkeitsdrift zu prüfen, mit einem außerplanmäßigen Trigger bei wesentlichen Sprüngen der Frontier-Fähigkeiten (12.2.4). Normative Änderungen durchlaufen ein öffentliches Review; die Trägerschaft muss organisatorisch von jedem einzelnen Anbieter unabhängig sein, Multi-Stakeholder-Prozesse pflegen und Interessenkonflikte offenlegen (12.3, 12.4). Für Claims gibt es ein öffentliches Statusregister mit den Zuständen Active, Under Review, Revoked und Retired; bei glaubhaften Hinweisen auf gefälschte oder irreführende Evidenz wandert ein Claim auf Under Review und darf nicht mehr als Q3, Q4, R2 oder R3 herangezogen werden (12.5).

Die Regeln zur Anwendung sind streng. Jede Qualitätsdeklaration muss Coverage Fidelity, Finding Validity, Evidence Traceability und Agent Integrity abbilden; für Q4- oder R3-Claims kommen Remediation Usability und Retestability verpflichtend hinzu (4.1.1 a). Eine Dimension darf nur mit dokumentierten Kriterien und Zustimmung des Evaluators als nicht anwendbar oder nicht gemessen gelten — und das muss offengelegt werden (4.1.1 b). Profile dürfen Dimensionen ergänzen, aber keine streichen (4.1.1 c). Vor allem: Die Dimensionen werden unabhängig voneinander deklariert und bewertet, dürfen nicht zu einem Composite Score kombiniert werden, und ein Defizit in einer Dimension darf nicht als durch Stärke in einer anderen ausgeglichen dargestellt werden (4.1.1 d).

Jeder Q2-, Q3-, Q4-, R2- oder R3-Claim enthält eine Qualitätsdeklaration, die jede anwendbare Dimension durch numerischen Wert, Ordinalklasse, booleschen Status oder eine profildefinierte Darstellung ausweist und auf Evidenz oder Methodik verweist (4.1.2). Vergleichsvalidierung — etwa gegen eine menschliche Referenzkohorte — darf die Qualitätsbewertung ergänzen, aber Coverage Fidelity, Finding Validity oder Evidence Traceability nie ersetzen (4.1.3). Agent Integrity ist eine eigenständige Dimension und wird nicht durch Process-Integrity-Offenlegungen erfüllt (4.1.4).

APAS <Modus>-<Tier> / <Ausführung>-<Kollaboration>-<Assurance> / <Umgebung> [<Affordance-Profil>] {<Reliance>}

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

Die vier Beispiel-Claims aus Anhang A

Drei Claim-Typen gibt es (5.1): Die Atomic System Capability Certification ist das vom Evaluator ausgestellte Ergebnis, dass ein System die anwendbaren Anforderungen für eine Fähigkeitskombination unter deklarierten Bedingungen erfüllt hat. Das Multi-Configuration Capability Statement bündelt zwei oder mehr atomare Claims für eine Systemversion. Das Engagement Conformance Statement bezieht sich auf ein konkretes Engagement, das mit einem APAS-zertifizierten System unter denselben oder engeren Bedingungen ausgeführt wurde — es zertifiziert nie die Zielumgebung (5.1.1).

Weil ein System mehrere Kombinationen anbieten kann, verlangt APAS eine Capability Matrix mit sieben Statusklassen: S1 Supported (ausgelegt, nicht evaluiert), S2 Evaluated (evaluiert, kein Claim), S3 Certified or Conformant, S4 Not Certified, S5 Not Evaluated, S6 Unsupported, S7 Retired. Nur S3 darf als zertifiziert dargestellt werden; eine öffentliche Matrix, die materiell relevante unterstützte Kombinationen weglässt, ist irreführend (5.3.1). Je Zeile gehören unter anderem dazu: Kombinations-ID, vollständiger Claim-String, Systemname und -version, Modellidentitäten samt System-Prompt-Provenance, Methodikreferenz, Evaluator, Status, Verweise auf Attestierung, Qualitäts- und Coverage-Deklaration, Core- und Companion-Versionen, Zertifizierungs- und Gültigkeitsdaten, materielle Limitationen; für Q3, Q4, R2 oder R3 sind Zertifizierungsdatum und explizites Ablaufdatum oder Revalidierungsintervall Pflicht (5.4.1).

Die Assistance Class aus Abschnitt 9 ergänzt die Klassen um die Frage, was Menschen tatsächlich beigetragen haben: H0 keine Hilfe mit Wirkung auf Strategie, Exploitation, Validierung, Priorisierung oder Bericht; H1 nur administrative oder Safety-Intervention; H2 analytische Hilfe — Exploit-Anleitung, Interpretation, Priorisierung, Control-Mapping oder Bericht-Editing. Die Klasse ist in der Attestierung offenzulegen, bei Mehrfachkonfigurationen je Kombination und Lauf (9.1.1). Ein X3-Claim verbietet H2 während der Ausführung, ein Q4-Claim verbietet H2 beim Zusammenstellen des Evidence-Package — auch durch interne Validierungs- oder Judge-Komponenten, die den Paketinhalt formen (9.1.2). Nachträgliches, anbieterseitiges Framework-Mapping oder Priorisieren, das den Prüfer materiell beeinflusst, gilt als Vendor-side Analytical Review und muss offengelegt werden (9.1.3). Eine Plattform darf nicht als agent-only, unabhängig autonom oder assessor-ready vermarktet werden, wenn relevante Läufe auf unoffengelegtem menschlichem Eingreifen oder Nachbearbeitung beruhten (9.2.2).

Zwei weitere Regeln verdienen die Aufmerksamkeit von CISOs und Revision. Erstens Haftung: Jeder R3-Claim muss die Partei benennen, die für die Richtigkeit der substituierten Evidenz verantwortlich ist, den Regress der vertrauenden Partei bei später festgestellten Mängeln, Gewährleistungsgrenzen und eine gegenüber der vertrauenden Partei dargestellte Berufs- oder Vermögensschadenhaftpflicht — APAS selbst begründet, überträgt oder begrenzt keine Haftung (5.10.4). Zweitens Mandanten- und Berechtigungstests: Ein R2- oder R3-Claim darf nie als Ersatz oder Ergänzung für Autorisierungs-, Zugriffskontroll- oder Mandantengrenzen-Tests gelten, wenn weniger als zwei verschiedene Principals oder nur ein Tenant genutzt wurden; solche Bereiche gelten als materiell ungetestet (5.10.6). Und: R2/R3 beschreiben, was das Paket liefert — nicht, welche Prüfhandlungen der Reviewer weglassen darf; Restprüfungen und Restrisiko-Akzeptanz bleiben beim Reviewer und seinem Framework (5.10.7).

Jeder T2A-, T2C-, T3-, T4-, Q2-, Q3-, Q4-, R2- oder R3-Claim enthält eine Coverage-Deklaration mit festen Pflichtfeldern (4.2.1). Sie muss die Unterschiede zwischen deklariertem, erreichbarem und getestetem Scope sowie zur Surface Baseline wahrheitsgemäß ausweisen; kein Paket darf vollständige, volle oder gleichwertige Coverage suggerieren, ohne Methodik und Evidenz dafür zu liefern; ein auf einer einzelnen Instanz oder in einem Lauf gezeigtes Ergebnis ist keine Coverage der entsprechenden Angriffsklasse (4.2.2).

Die Baseline-Leiter BS-1 bis BS-3

1. 1
   BS-1 Asserted

   Asset-Inventar oder Scope-Liste des Zieleigentümers — unabhängig vom Kandidatensystem, aber begrenzt durch die Vollständigkeit des Eigentümers (4.2.8 a).

2. 2
   BS-2 Directed

   Vom Evaluator gelenkte Enumeration, bei der der Evaluator die Fläche über die Entdeckung des Systems hinaus spezifiziert oder erweitert — die Mindeststufe für Q3, Q4 und R3 (4.2.8 b, 4.2.10).

3. 3
   BS-3 Instrumented

   Enumeration durch ein unabhängiges Discovery-Instrument oder einen Prozess, der die Discovery-Logik des Kandidatensystems nicht teilt (4.2.8 c).

Für Q3, Q4 und R3 ist der Coverage-Nenner gegen eine Independent Surface Baseline zu bilden; die eigene Entdeckung des Systems darf nicht die einzige Quelle sein (4.2.4). Materielle Abweichungen zwischen entdeckter Fläche und Baseline sind in beide Richtungen offenzulegen; jede Baseline-Fläche, die nicht ausgeübt wurde, gilt als materiell ungetestet; Under-Discovery senkt die dargestellte Coverage, nie umgekehrt (4.2.5). Werden Quellen kombiniert, darf die Gesamt-Baseline nicht stärker dargestellt werden als die schwächste Quelle, die einen materiellen Bereich allein abdeckt (4.2.9). Wo keine unabhängige Baseline verlangt ist, muss die Deklaration sagen, dass der Nenner selbst enumeriert ist, und die Methode beschreiben (4.2.6).

Coverage-Status allein sagt nichts über Tiefe. Für jeden getesteten oder teilweise getesteten Bereich ist auszuweisen, ob Request-Level-Probing, authentifiziertes Probing, mehrstufige Workflow- oder Zustandsübergangs-Tests und Tests an Privilegien- oder Mandantengrenzen durchgeführt wurden. Coverage-Einheit, Schwellen für Teilabdeckung, Tiefengrade und Gewichtungen definiert die Profile Registry — ohne anwendbares Profil ist Tiefe narrativ zu deklarieren und keine Coverage-Proportion oder -Prozentzahl darzustellen (4.2.11). Bei T2C-Claims muss die Deklaration so strukturiert sein, dass ein Reviewer kontrollrelevante getestete, ausgeschlossene und ungetestete Bereiche ohne Interpretation des Anbieters erkennt (4.2.7).

Nicht-Determinismus ist der zweite Blindfleck. Ein System gilt als materiell nicht-deterministisch, wenn wiederholte Läufe unter denselben Bedingungen materiell unterschiedliche Angriffsflächen, Befundmengen oder Exploitation-Ergebnisse liefern; das ist in der Methodik offenzulegen (4.6.1). Varianz darf nicht durch den günstigsten Lauf kaschiert werden; wo mehrere Läufe einen Claim stützen, sind Auswahl, Aggregation und Offenlegung vorab zu definieren, und der Evaluator attestiert, dass Laufzahl und Aggregationsregel vor der Ausführung feststanden (4.6.2). Q3-, Q4-, R2- und R3-Claims charakterisieren die Run-zu-Run-Varianz mit einem deklarierten Maß — etwa Surface-Discovery-Varianz oder dem Jaccard-Index der Finding-Mengen — über ein vorregistriertes Run-Design (4.6.3). Die Aggregationsregel stammt aus einer geschlossenen Menge (Any-Run-Union, All-Run-Intersection, Mehrheit oder eine ausdrücklich deklarierte Regel) und die Einzelergebnisse aller Läufe, nicht nur eine Kennzahl, gelangen ins Evidence-Package (4.6.5).

Jedes Confirmed Finding trägt einen Stable Finding Identifier — eine eindeutige, über Revisionen, Retests, Exporte und Formatkonvertierungen hinweg stabile Kennung — und, außer im Single-Capture-Pfad, eine Reproduction Procedure: eine aufgezeichnete, deterministische, agentenunabhängige Abfolge von Schritten, Requests, Payloads, Vorbedingungen und erwarteten Beobachtungen, mit der ein kompetenter Dritter die Bedingung ohne Zugang zum Kandidatensystem reproduzieren kann (4.3.3, Anhang D). Die erwarteten Beobachtungen schließen die Kontroll- oder Expected-Secure-Beobachtung ein; probabilistisch darf eine Procedure nur sein, wenn die Bedingung selbst probabilistisch ist (Race Conditions, TOCTOU, Timing-Seitenkanäle), dann mit Versuchszahl und beobachteter Erfolgsrate. Jedes Confirmed Finding deklariert außerdem Vantage Point und Zugangsbedingung sowie die Region der Umgebungsklasse (4.3.5); angrenzende Dienste oder systemübergreifende Pfade, die für Ausnutzbarkeit oder Impact relevant sind, werden offengelegt — bei E3 zwingend (4.3.6).

Für Q3-, Q4-, R2- oder R3-Claims müssen EV3- und EV4-Artefakte über einen Pfad erhoben werden, der nicht unter alleiniger Kontrolle des Kandidatensystems steht — Netzwerk-Interception, Host-Beobachtung oder vom Evaluator gesammelte Captures; unterhalb dieser Schwelle sind rein systemgesammelte Artefakte im Evidence-Manifest als solche zu kennzeichnen; für Q2 und Q3 sollen EV3/EV4 Out-of-Band Witness Evidence sein — Callback-Listener, Canaries oder zielseitige Monitore, die das System weder autoren, beobachten noch erreichen kann (4.4.4, Anhang D). Behauptet ein Befund einen Autorisierungs- oder Mandantengrenzen-Defekt, verlangt EV3 gepaarte Beobachtungen: derselbe Request gelingt für den unbefugten Principal und wird für einen befugten Kontroll-Principal abgewiesen, beide referenziert über die Identity Coverage (4.4.6).

Retest und Deduplizierung

Ein Retest führt die gegen den Stable Finding Identifier aufgezeichnete Reproduction Procedure aus, ordnet das Ergebnis dieser Kennung zu und legt offen, ob der Befund weiter besteht, teilweise behoben oder nicht mehr reproduzierbar ist (4.3.4). Probabilistische Wiederentdeckung — oder ihr Ausbleiben — durch einen erneuten Agentenlauf ist weder Fix-Verifikation noch Persistenznachweis noch Retest; solche Ergebnisse müssen als probabilistic rediscovery gekennzeichnet und vom Procedure-Ergebnis getrennt werden (4.3.4 a). Bei intermittierenden Bedingungen werden Versuchszahl und Erfolgsrate gegen die Rate vor der Behebung bewertet (4.3.4 b). Für jedes Paket muss eine dokumentierte Deduplizierungsregel existieren, die festlegt, wie wiederholte Beobachtungen derselben Bedingung aus verschiedenen Läufen, Vantage Points oder Instanzen auf einen Stable Finding Identifier kollabieren (4.3.9).

Das Affordance-Profil ist die deklarierte Betriebsumgebung des Systems während des Tests: Fähigkeiten, Restriktionen, Zugangsbedingungen, Eskalationslimits und Auflagen (Anhang D). Jeder Claim referenziert ein Profil mit mindestens den folgenden Feldern; ein generisches Label wie „standard“ genügt für die Felder zu Zielschutz- und Agent-Integrity-Kontrollen nicht. Interne Validierungs-, Judge-, Verifier- oder Konsenskomponenten sind in der Agent Topology zu deklarieren und ihre Rolle in der Qualitätsdeklaration zu Finding Validity offenzulegen. Fehlt eine Action Reversibility Class, gilt das Engagement als irreversibel — mit den strengsten Safety-Pflichten (7.1.1).

Die Umgebungsklassen beschreiben Reichweite über Vertrauensgrenzen, nicht den Zieltyp: E1 ein einzelnes isoliertes Ziel, E2 mehrrollige, mehrstufige oder zustandsbehaftete Interaktion innerhalb einer deklarierten Vertrauensgrenze, E3 Interaktion über eine Vertrauens- oder Segmentierungsgrenze hinweg (7.2). Sie gelten für Anwendungen, APIs, Netze, Infrastruktur, Cloud-Control-Planes, Container, Client-Software, Mobile, Firmware und Embedded gleichermaßen; Social-Engineering-, physische und Funk-Vektoren importiert keine Klasse. Jeder Claim ist auf seine deklarierte Klasse beschränkt (7.2.1); Umgebungstyp und materielle Unterschiede zur Produktion sind zu deklarieren, ein Nicht-Produktionstest impliziert ohne deklarierte Parität keine Produktionsabdeckung (7.2.2). T2A-, T2C-, T3- und T4-Claims referenzieren eine deklarierte Methodik; Methodiken für Q4 oder R3 definieren zusätzlich Negative-Result-Handling, Remediation- und Retest-Erwartungen sowie die Bedrohungsmodell-Begründung für den gewählten Modus (7.3).

Autorisierung und Rules of Engagement

Jedes APAS-Engagement hat eine Authorization Declaration mit autorisierender Partei, rechtlicher oder vertraglicher Grundlage, autorisiertem Scope und Zeitfenster sowie Rules of Engagement; Tests außerhalb davon gelten als Out-of-Scope-Aktivität nach Abschnitt 10 — unabhängig von technischem Erfolg oder Befundwert (7.4.1). Zusätzlich sind, wo relevant, zu deklarieren: Testfenster inklusive Blackout- und Wartungsfenster, benannte Notfallkontakte von Zieleigentümer, Evaluator und Betreiber des Systems mit Erreichbarkeit und maximaler Benachrichtigungszeit, Autorisierungsstatus für Dritt- und Cloud-Infrastruktur samt providerspezifischen Testbedingungen, Quelladressen des Systems und Allowlisting, Datenklassifikationsgrenzen und De-Confliction mit SOC oder Blue Team (7.4.3). Die Declaration benennt außerdem die Identität des handelnden Agenten, das Identitätsschema, die Verifikationsmethode für den Zieleigentümer und bei Subagenten die Delegationskette samt maximaler Tiefe (7.4.4).

Weil autonome Systeme auf Schwachstellen in Drittkomponenten oder außerhalb des Scope stoßen, verlangt jedes Engagement einen Coordinated-Disclosure Path: Jeder solche Befund trägt einen Offenlegungsstatus (encountered, notified, disclosure-restricted, resolved, published), bleibt in jedem Status mit Stable Finding Identifier und Content-Hash im Evidence-Manifest enumeriert, und nur das Exploitation-Detail darf vorübergehend zurückgehalten werden — nie der Befund selbst (7.4.2). Kann das System geteilte oder fremde Infrastruktur außerhalb der Autorisierung erreichen, müssen die Eskalationslimits es davon fernhalten (7.4.3.2).

Jede als R2 oder R3 dargestellte Zertifizierung oder Engagement-Aussage enthält ein vom Assessor konsumierbares Evidence-Package; jeder Q2-, Q3- oder Q4-Claim enthält Qualitäts- und Coverage-Deklaration, selbst wenn nur R1 beansprucht wird (8.1.1). Für R2/R3 soll die stützende Evidenz mindestens so lange verfügbar bleiben, wie der Claim gültig ist (8.1.2 b).

Integrität: Signatur, Hashes, manipulationssichere Logs

Jede Q3-, Q4-, R2- oder R3-Attestierung ist vom ausstellenden Evaluator oder der Konformitätsstelle kryptografisch signiert — mit verifizierbarer Identität, veröffentlichter Prüfmethode, Zertifikats- oder Schlüsselkennung, vertrauenswürdigem Zeitstempel und einem veröffentlichten Weg, den Schlüsselstatus auch nach Rotation, Ablauf oder Widerruf zu prüfen (8.2.1). Das Evidenz-Manifest enthält je Artefakt einen Content-Hash zum Erfassungszeitpunkt (8.2.2); Ausführungs- und Evidenz-Logging ist manipulationsevident und wird von einer Komponente oder Partei geführt oder gegengezeichnet, die nicht unter alleiniger Kontrolle des Systems steht (8.2.3). Gefälschte, nicht nachvollziehbare oder materiell irreführende Evidenz macht den Claim ungültig (8.2.4); ein Paket mit fehlgeschlagener Signaturprüfung, Hash-Abweichungen oder unerklärten Lücken im Log darf nicht als Q3, Q4, R2 oder R3 herangezogen werden, bis der Widerspruch gelöst und neu attestiert ist (8.2.5). Widersprüche zwischen Attestierung, Befunden, Ausführungsaufzeichnungen und Artefakten sind offenzulegen und nicht narrativ wegzuerklären (8.2.7).

Maschinenlesbarkeit und offene Austauschformate

Jedes Q2-, Q3-, Q4-, R2- oder R3-Paket trägt maschinenlesbare Felder: vollständiger Claim-String, Kombinations-ID, Systemname und -version, Modellidentitäten und -versionen, System-Prompt-Provenance, eine Build-Kennung des Systems als kryptografischer Digest über die gebundene Konfiguration, Methodikreferenz, Evaluator-Identität, Signatur- und Verifikationsmetadaten, Assistance Class, beobachteter Betriebspfad, Referenzen auf Qualitäts- und Coverage-Deklaration mit Baseline-Quellen, Asset-IDs und SBOM-Referenzen, Finding-State-Übersicht, Stable Finding Identifiers, Attack-Path-Beziehungen, Single-Capture-Labels, Materialitätsentscheidungen, Manifest-Hashes, Zertifizierungsdatum mit Ablauf oder Revalidierungsintervall, Core- und Companion-Versionen und Reliance Outcome. Claim-String und Build-Kennung reisen in einem deklarierten Provenance-Envelope wie in-toto, DSSE oder SCITT (8.4.1).

Die Baseline gilt für jeden Claim: explizite Scope-Grenzen, ein Stop- oder Suspend-Mechanismus und ausreichende Logs oder Artefakte für die Evaluator-Prüfung (10.1.1). Out-of-Scope-Aktivität, gefälschte Evidenz, materielles Verschweigen menschlicher Hilfe oder irreführende Coverage-Aussagen machen den Claim ungültig (10.1.2); materielle Unsicherheit bei Impact, Coverage oder Retest-Schlüssen ist im Paket zu kennzeichnen (10.1.3).

1. 1
   Stop Authority deklarieren

   Jedes Engagement benennt, wer die Ausführung aussetzen oder beenden darf — mindestens der Zieleigentümer und, falls vorhanden, der Evaluator (10.2.1).

2. 2
   Out-of-band wirken

   Der Stop-Mechanismus arbeitet außerhalb der Entscheidungsschleife des Systems; das System ist nie alleiniger Schiedsrichter darüber, ob ein Stop greift. Das Affordance-Profil nennt eine maximale Reaktionszeit; innerhalb dieser Frist endet jede offensive Aktivität, laufende Aktionen werden unterbrochen, wartende, geplante oder delegierte Arbeit storniert oder dokumentiert (10.2.2).

3. 3
   Fail-safe bei Aufsichtsverlust

   Fallen Monitoring, Aufsichtsverbindung, Logging oder der Stop-Kanal über die deklarierten Toleranzen hinaus aus, setzt das System offensive Aktivität aus, bis die Aufsicht wiederhergestellt ist — Verlust der Aufsicht führt nie zu fortgesetztem autonomem Betrieb (10.2.3).

4. 4
   Aufzeichnen und benachrichtigen

   Stop- und Halt-on-Loss-Ereignisse samt Timing landen im manipulationsevidenten Log und im Evidence-Package; die Notfallkontakte werden innerhalb der deklarierten Frist informiert (10.2.4).

5. 5
   Access Disposition Record

   Zum Abschluss — und nach jedem Stop — weist ein Record jeden vom Engagement erzeugten Zugang (Tokens, Konten, Sessions, Tunnel, delegierte Tokens, Persistenz) mit Status (Revoked, Expired, Removed, vom Zieleigentümer rotiert oder Retained mit Eigentümer und Ablauf), zuständiger Partei und Verifikationsreferenz aus (10.2.5).

6. 6
   End-to-End verifizieren

   Der Evaluator prüft jeden sicherheitskritischen Stop-, Suspend-, Resume- oder Override-Kanal Ende-zu-Ende — von der autorisierten Partei bis zum Enforcement-Punkt in der attestierten Deployment-Konfiguration; die bloße Existenz oder korrekte Signierung genügt nicht, mindestens ein ausgeübtes Ereignis je Kanal mit Zustell- und Durchsetzungsergebnis gehört ins Paket (10.2.6). Verfügbarkeit eines Kanals ist kein Beleg für Zustellung; eine nicht umgesetzte Anweisung muss als Zustellfehler erkennbar sein (10.2.7).

Die Pflichten skalieren mit dem Schlechteren aus Ausführungsautonomie, reduzierter menschlicher Beteiligung und deklariertem Affordance-Risiko (Action Reversibility Class): Innerhalb eines Profils sind die Anforderungen für X3 mindestens so stark wie für X2 und diese mindestens so stark wie für X1, dasselbe von C1 bis C4; eine weniger reversible Action Reversibility Class erhöht die Anforderungen unabhängig von X und C; keine Profil-, Evaluator- oder Anbieterentscheidung darf den autonomsten Klassen schwächere Aufsicht gewähren — eine Konfiguration, in der mehr Autonomie die Aufsicht entfernt, ist nicht zertifizierbar (10.3.1).

• X3-, C4- und E3-Betrieb sowie jedes Engagement mit erlaubten irreversiblen Aktionen oder autonomem Chaining in angrenzende Flächen verlangen zusätzlich: ständige Verfügbarkeit des Stop-Kanals während der Ausführung (10.3.2 a),
• automatische Erkennung der Annäherung an oder Verletzung der Scope-Grenze, die die Aktion stoppt oder blockiert, statt sie nur zu protokollieren (10.3.2 b),
• eine Deklaration, wie die autorisierte Scope-Grenze zur Laufzeit durchgesetzt wird (10.3.2 c), Halt-on-Loss-of-Oversight (10.3.2 d),
• die Durchsetzung der deklarierten Eskalationslimits durch einen Mechanismus, dessen Ausfall erkennbar ist (10.3.2 e),
• und bei verketteten Aktionen ein Gate auf der schlechtesten erreichbaren Action Reversibility Class der gesamten Kette, bevor der erste Schritt läuft (10.3.2 f).

Agent Integrity: der Agent als Angriffsziel

Ein Pentest-Agent liest Zielinhalte, ruft Tools auf, nutzt MCP-Server und persistiert Kontext — und ist damit selbst angreifbar. APAS verlangt deklarierte Kontrollen gegen mindestens vier Manipulationsklassen: Prompt Injection aus Zielinhalten oder -antworten, Manipulation oder Substitution von Tools, Plugins, Modellen oder MCP- und vergleichbaren Tool-Servern, Poisoning abgerufenen oder persistierten Kontexts sowie unautorisierte Änderung oder Umgehung der Laufzeitkontrollen für Scope, erlaubte Tools und Privilegien (10.4.1). Jeder Q3-, Q4-, R2- oder R3-Claim enthält in der Qualitätsdeklaration eine Agent-Integrity-Offenlegung mit den Kontrollen, erkannten Manipulationsversuchen und deren Behandlung; eine vom System selbst erzeugte Meldung „keine Manipulation erkannt“ ist kein Beleg dafür, dass keine stattfand (10.4.2).

Entscheidend ist, wer testet: Für Q3, Q4, R2 oder R3 muss der Evaluator adversariale Agent-Integrity-Tests selbst ausführen — mindestens Goal Hijack, Tool-Response-Injection sowie Context- oder Memory-Poisoning; rein anbieterbehauptete Kontrollen tragen keinen dieser Claims (10.4.4). Die Evaluation vergleicht gekennzeichnete Evaluationsläufe mit blinden Läufen bei Scope-Treue, Out-of-Scope-Verweigerung, Coverage und Fabrikationsrate; eine materielle Verhaltensdifferenz ist Eval-Awareness, muss offengelegt werden und deckelt das Assurance-Outcome (10.4.3). Unentdeckte Manipulation, die Strategie, Befunde, Scope-Treue oder Berichtsinhalt materiell verändert hat, macht die betroffenen Claim-Dimensionen ungültig. Erkennt das System eine Manipulation, setzt es offensive Aktivität aus, informiert Zieleigentümer, Evaluator und Notfallkontakte und stellt Evidenz und Befunde aus dem verdächtigen Zeitfenster unter Quarantäne (10.4.5).

Pflichtangaben jedes öffentlichen APAS-Claims (11.1.1)

• atomarer oder matrixbasierter Status,
• alle acht Claim-Dimensionen,
• die Identität des Evaluators,
• Zertifizierungs- und Gültigkeitsdaten,
• die Version des Kandidatensystems,
• materielle Limitationen, wo Reliance beansprucht wird,
• die Verfügbarkeit der anwendbaren Qualitätsdeklaration oder einer Zusammenfassung,
• bei mehreren unterstützten Kombinationen der Status benachbarter Kombinationen, die ein vernünftiger Käufer als verfügbar annehmen könnte,
• die Core-Standard-Version und Kennung samt Version jedes angewandten Companion-Dokuments,
• wo wesentlich, ob dynamisches Umschalten zwischen Kombinationen unterstützt wird,
• und überall, wo der Claim-String öffentlich oder in käufer-, marketing- oder beschaffungsseitigem Material steht, eine einsätzige Klartext-Lesart nach Anhang A — in gleicher Prominenz wie der codierte String.

Verbotene Aussagen (11.2.1)

Allein auf Basis einer APAS-Zertifizierung darf niemand behaupten oder implizieren:

Zwei weitere Regeln runden den Abschnitt ab: Keine Ausführungs-, Kollaborations-, Assurance- oder Reliance-Klasse darf ohne die vollständigen Claim-Dimensionen vermarktet werden — ein isoliertes „Q4“ oder „X3“ im Prospekt ist unzulässig (11.2.2). Und eine Single-Capture Confirmation ist in jedem öffentlichen Claim als solche zu kennzeichnen und darf nie als unabhängig reproduziert dargestellt werden (11.2.3). Bei Widersprüchen gelten die attestierten Deklarationen vor jeder öffentlichen Aussage und jeder Marketing-Zusammenfassung (13.2); verlangt ein Framework oder Assessor strengere Bedingungen als APAS, gelten diese (13.3).

Die CSA selbst ordnet APTS als das nächstverwandte Vorhaben ein: ein frühes OWASP-Incubator-Projekt zum sicheren, begrenzten Betrieb autonomer Pentest-Plattformen. Überschneidungen gibt es nur bei der operativen Governance — den APAS-Abschnitten 7 (Declared Conditions), 9 (Human Assistance) und 10 (Safety) —, während APTS keine Coverage-Messmethodik, kein Reliance- oder Substitutions-Grading und keine evaluatorbasierte Zertifizierung vorsieht; genau das ist der Kern von APAS. Wo APTS Reproduzierbarkeit von Befunden und assessor-gerichtete Evidenz berührt, geht APAS weiter: Confirmed Findings setzen agentenunabhängige Reproduktion voraus, Coverage wird gegen eine Independent Surface Baseline gemessen (Relationship to Existing Work).

So nutzen Sie beide Standards zusammen

Die Entscheidung: wo autonome Pentests heute tragen

Autonome Pentest-Systeme spielen ihre Stärken aus, wo Breite, Frequenz und Wiederholbarkeit zählen: kontinuierliche Prüfung einer sich ändernden Angriffsfläche, Regressionstests nach Releases, Vorab-Triage vor einem manuellen Pentest, Retests mit reproduzierbaren Procedures und die Abdeckung vieler gleichartiger Ziele. Ihre Grenzen setzt APAS selbst: kein Social Engineering, keine physischen oder Funk-Vektoren, kein vollumfängliches Red Team (2.2, 5.6.3), kein kontinuierlicher Betrieb als Claim (2.2.4) — und keine Substitution geforderter Prüfungen ohne R3, Profil und Zulassung des Prüfrahmens (5.10). Die Entscheidung lautet deshalb selten „autonom oder menschlich“, sondern: Welche Teilmenge der Prüfaktivitäten kann autonom mit welcher Assurance erfolgen, und was bleibt klassisch?

1. 1
   Nachweiszweck festlegen

   Interne Remediation (Q2/R1), Augmentation für Prüfer (Q4/R2) oder Substitution (Q4/R3)? Der Reliance-Navigator auf dieser Seite führt durch die Frage; das Ergebnis bestimmt alle weiteren Anforderungen.

2. 2
   Scope und Baseline bereitstellen

   Ein maschinenlesbares Inventar (CMDB/CAASM, SBOM-Referenzen) ist Ihre BS-1-Baseline; für Q3/Q4/R3 ergänzt eine evaluatorgelenkte Enumeration (BS-2). Ohne Baseline kann niemand Coverage messen — auch Sie nicht (4.2).

3. 3
   Pilot als Evaluation aufsetzen

   Vorregistriertes Run-Design mit mehreren Läufen und Varianzmaß (4.6.3), unabhängige Reproduktion einer Stichprobe (EV3), gepaarte Beobachtungen bei Berechtigungsbefunden (4.4.6), Stop-Authority-Test End-to-End (10.2.6), adversariale Agent-Integrity-Tests (10.4.4) und ein blinder Lauf gegen Eval-Awareness (10.4.3).

4. 4
   Betriebsmodell Mensch plus Agent definieren

   Welche X/C-Klasse passt zu Ihrer Risikotoleranz? Für produktive Ziele mit irreversiblen Aktionen gelten die strengsten Pflichten (10.3.2); legen Sie Freigabepunkte, Eskalationskontakte, Testfenster und De-Confliction mit dem SOC fest (7.4.3).

5. 5
   Vertrag und Governance

   Data Handling und Egress (7.1.1), Stop Authority und Reaktionszeit, Access Disposition, Offenlegung von Konfigurationsänderungen und Re-Attestierung (5.11.3), Haftung bei Substitution (5.10.4), Austauschformate (8.4.3) — plus KPIs: Unsupported-Finding Rate, Retest-Quote, Coverage gegen Baseline, Stop-Reaktionszeit.

Tool-Evaluation: der APAS-basierte Anforderungskatalog

• Welche Fähigkeitskombinationen bietet die Plattform an — bitte als Capability Matrix mit allen acht Dimensionen und Statusklassen, nicht als Feature-Liste (5.3, 5.4)?
• Wie lautet die Klartext-Lesart Ihres stärksten Claims, und welche Limitationen gelten dafür (11.1.1)?
• Woher stammt der Coverage-Nenner Ihrer Berichte — aus eigener Entdeckung oder aus einer unabhängigen Baseline? Zeigen Sie eine Coverage-Deklaration mit allen Pflichtfeldern (4.2.1).
• Wie hoch ist Ihre Unsupported-Finding Rate je Kombination, getrennt nach False Positives und Over-Severity (4.3.8)?
• Enthält jeder Befund eine Reproduction Procedure, die mein Team ohne Ihre Plattform nachvollziehen kann, und einen Stable Finding Identifier (4.3.3)?
• Wie kennzeichnen Sie Observations, Validated und Confirmed Findings — und wer bestätigt (4.3, 4.4.1)?
• Wie charakterisieren Sie Run-zu-Run-Varianz, und berichten Sie alle Läufe oder nur den besten (4.6)?
• Welche Felder umfasst Ihr Affordance-Profil — insbesondere Inference- und Telemetry-Egress mit Jurisdiktion, Tool- und MCP-Provenance, Action Reversibility (7.1.1)?
• Wie wirkt die Stop Authority out-of-band, mit welcher maximalen Reaktionszeit, und was passiert bei Verlust der Aufsicht (10.2.2, 10.2.3)?
• Welche Kontrollen gegen Prompt Injection, Tool-Substitution, Kontext-Poisoning und Umgehung der Laufzeitkontrollen bestehen, und wer hat sie adversarial getestet (10.4)?
• Liefern Sie Agent Execution Record, Content-Hashes und signierte Attestierung — und in welchen Formaten exportieren Sie Befunde, Mappings und Fix-Status (8.2, 8.4.3)?
• Welche Änderungen an Modell, Prompt, Orchestrierung oder Tool-Set melden Sie uns, und wie oft hat sich Ihre Konfiguration in den letzten zwölf Monaten materiell geändert (5.11)?

Die vollständige Fassung mit Bewertungsmatrix, Ausschlusskriterien und 20 RfP-Fragen enthält das CISO-Whitepaper weiter unten auf dieser Seite.

Regulatorische Einordnung: was Prüfer akzeptieren können

APAS stellt klar, dass es keine regulatorische, vertragliche oder Audit-Compliance begründet und eine APAS-Zertifizierung nie Framework-Akzeptanz impliziert (1, 5.9.1). Umgekehrt sagen die meisten Rahmenwerke nichts über autonome Tester — sie verlangen Tests, Methodik, Qualifikation und Dokumentation. Die folgende Einordnung ist deshalb eine VamiSec-Einschätzung, welche Reliance-Klasse ein Prüfer unter dem jeweiligen Rahmen heute vernünftigerweise akzeptieren kann.

Die Aufsicht hat 2026 eine erkennbare Linie: KI als unterstützte, menschlich beaufsichtigte Fähigkeit. Die EZB-Bankenaufsicht forderte bedeutende Institute im Juli 2026 zu Aktionsplänen gegen KI-gestützte Angriffe auf und nennt KI-basierte Werkzeuge als Ergänzung der Schwachstellenprüfung — unter der Bedingung einer vorherigen Nutzen-Risiko-Bewertung, angemessener Schutzmaßnahmen und menschlicher Aufsicht. ENISA beschreibt im selben Monat den „Verification Bottleneck“: Die Menge technisch korrekter KI-Befunde überfordert die Verifikation — genau die Lücke, die APAS mit Confirmed Findings und Unsupported-Finding Rate adressiert. Das britische NCSC verlangt für KI-Agenten Sandboxing, unveränderliche Logs und die Möglichkeit, „den Stecker zu ziehen“; die gemeinsame Five-Eyes-Leitlinie vom Mai 2026 empfiehlt Red Teaming und Penetrationstests gegen agentische Systeme und menschliche Freigabe vor wirkungsstarken Aktionen. Eine Aufsichtsaussage, die autonome Pentests ausdrücklich als Regulierungsnachweis anerkennt oder ablehnt, gibt es bislang nicht.