Der Bericht liegt vor. Zwei Wochen Testing, ein sauberes Dokument, die Findings sind eingeplant, das Häkchen für den Verwaltungsrat ist gesetzt. Dein Jahres-Pentest hat funktioniert, so wie er seit Jahren funktioniert.

Und jetzt eine unangenehme Frage: Gegen welchen Massstab wurde eigentlich der KI-Teil geprüft?

Nicht ob er geprüft wurde. Gegen was.

Warum der klassische Pentest so gut funktioniert

Der Grund ist nicht, dass Pentester besonders clever sind. Der Grund ist, dass es einen geteilten Massstab gibt, auf den sich Käufer und Anbieter einigen, bevor jemand eine Zeile Code anfasst.

OWASP ASVS, seit Version 5.0 vom Mai 2025 mit rund 350 Anforderungen in siebzehn Kapiteln und drei Verifikationsleveln. Steht Level 2 im Vertrag, wissen beide Seiten, was Bestehen bedeutet, was im Scope ist und was der Bericht am Ende belegen muss. Der Standard macht die Leistung vergleichbar, und Vergleichbarkeit ist der Grund, warum aus dem Pentest eine Commodity werden konnte.

Genau dieser Massstab fehlt beim KI-Teil. Nicht das Testen fehlt. Der Massstab.

Die Lücke ist vermessen, und sie sieht anders aus, als du denkst

Pentera hat im Dezember 2025 dreihundert CISOs und Security-VPs aus Unternehmen ab dreitausend Mitarbeitenden befragt. Die Zahlen widerlegen die bequeme Annahme, KI-Sicherheit sei ein Awareness-Problem.

52 Prozent haben KI-Szenarien bereits im adversarialen Testumfang. Es wird also längst getestet. Nur:

30 Prozent sagen ausdrücklich, die Testmethodik für KI-Sicherheit sei unklar. Elf Prozent haben Werkzeuge, die für KI gebaut wurden. Drei Viertel schützen ihre KI-Systeme mit Endpoint-, Cloud- und API-Tools, die für etwas anderes entworfen wurden.

Und der Wert, der die Lage am ehrlichsten beschreibt: Kein einziger der dreihundert Befragten meldet vollständige Sichtbarkeit über die eigenen KI-Systeme. Null. Zwei Drittel haben begrenzte Sicht, das restliche Drittel hat gute Sicht und rechnet trotzdem mit Schatten-KI im Haus.

Als grösste Hürde nennt die Hälfte der Befragten fehlende interne Expertise. Budget nennen siebzehn Prozent. Das Geld ist da. Der Massstab ist es nicht, und die Leute, die ihn anlegen könnten, auch nicht.

Was sich am 24. Juni geändert hat

An diesem Tag ist OWASP AISVS 1.0 erschienen, der Artificial Intelligence Security Verification Standard. Aufgebaut wie ASVS, mit denselben drei Verifikationsleveln, in zwölf Kapiteln.

Die Kapitelliste allein sagt einem Entscheider mehr als jede Bedrohungsanalyse, weil sie zeigt, welche Angriffsfläche sein Haus in den letzten achtzehn Monaten dazubekommen hat: Trainingsdaten-Integrität, Eingabevalidierung, Modell-Lebenszyklus, Infrastruktur, Zugriffskontrolle und Identität, Lieferkette, Modellverhalten, Memory und Vektordatenbanken, Orchestrierung und agentische Aktionen, MCP-Sicherheit, adversariale Robustheit, Monitoring.

MCP-Sicherheit ist ein eigenes Kapitel in einem Standard. Vor achtzehn Monaten gab es das Protokoll noch nicht in dieser Verbreitung.

Dazu zwei Bedrohungskataloge: die OWASP LLM Top 10 in der Fassung von Anfang August 2026, und die OWASP Top 10 for Agentic Applications vom Dezember 2025. Zwei Listen, weil sie zwei verschiedene Dinge beschreiben. Die eine behandelt das Modell als Komponente, die Eingaben bekommt und Ausgaben produziert. Die andere behandelt es als Akteur mit Zielen, Zugangsdaten, Werkzeugen und Gedächtnis.

Wenn dein Produkt Agenten hat, brauchst du beide. Und dein Pentest-Anbieter hat vermutlich von keiner der beiden gehört, als er dir das Angebot geschrieben hat.

Die eine Bewegung in der Liste, die deine Risikorechnung ändert

Die 2026er Fassung der LLM Top 10 wurde erstmals nicht nur durch Expertenvotum bestimmt, sondern zu einem Viertel durch reale Vorfälle. 7 714 analysierte Incidents. Das verschiebt die Rangfolge, und zwei Verschiebungen erzählen dieselbe Geschichte.

Excessive Agency ist von Platz sechs auf Platz drei gestiegen. Zu viel Handlungsvollmacht für das Modell.

Improper Output Handling ist von Platz fünf auf Platz zehn gefallen. Die unsaubere Weiterverarbeitung der Modellantwort.

Übersetzt für die Vorstandssitzung: Der Schaden entsteht nicht mehr dort, wo das Modell etwas Falsches sagt. Er entsteht dort, wo es etwas Falsches tut. Die relevante Frage lautet nicht mehr, wie gut deine Antworten sind. Sie lautet, was dein System auslösen darf und mit wessen Rechten.

Prompt Injection steht unverändert auf Platz eins, jetzt erweitert um Angriffe, die in Bildern und Audio versteckt sind.

Guardrails sind deine WAF. Was fehlt, ist die Schicht darunter.

Im Web sichern wir Injection auf zwei Ebenen ab, und nur zusammen ergeben sie den Standard, den heute jeder akzeptiert.

Unten liegt die deterministische Ebene: parametrisierte Abfragen. Damit ist SQL Injection nicht zu neunundneunzig Prozent verhindert, sondern strukturell unmöglich, weil Anweisung und Daten getrennte Kanäle haben. Darüber liegt die probabilistische Ebene: die Web Application Firewall, seit März 2025 in PCI DSS für öffentlich erreichbare Anwendungen sogar verpflichtend. Sie rät, sie hat Falsch-Negative, und das ist völlig in Ordnung. Sie darf raten, weil unter ihr etwas liegt, das nicht raten muss.

Bei KI hast du heute nur die obere Ebene. Guardrails sind deine WAF, und sie sind erstaunlich gut geworden: Für ein gehärtetes Modell nennt Anthropic rund ein Prozent Erfolgsquote bei Injection-Versuchen. Als WAF-Kennzahl wäre das ein Spitzenwert.

Die parametrisierte Abfrage fehlt trotzdem. Ein Sprachmodell verarbeitet Systemanweisung, Nutzereingabe und den Text aus der eingehenden Mail in einer einzigen Tokenfolge. Es gibt keine Privilegiengrenze zwischen Anweisung und Daten, deshalb zeigt Forschung gegen sechs verbreitete Schutzsysteme, darunter Azure Prompt Shield und Meta Prompt Guard, Umgehungsraten von bis zu hundert Prozent, sobald ein Angreifer seine Eingaben gezielt anpasst.

Der Unterschied liegt also nicht in der Erkennungsrate. Er liegt darin, was hinter der Lücke wartet. Kommt eine Payload an der WAF vorbei, trifft sie auf Code, der sie nicht ausführt. Kommt eine Injection am Guardrail vorbei, trifft sie auf einen Agenten mit deinen Werkzeugen und deinen Rechten.

Und damit ist das Problem lösbar, nur eben nicht dort, wo die meisten es suchen. Die fehlende Ebene baust du nicht aus besserer Erkennung, sondern aus Berechtigungen. Was ein Agent nicht darf, kann keine Injection auslösen. Das ist deterministisch, genau wie die parametrisierte Abfrage, und es ist die einzige Kontrolle in der ganzen Kette, die nicht raten muss.

Das ist auch der Grund, warum die Guardrails in Azure AI Foundry an vier Interventionspunkten greifen: bei der Nutzereingabe, vor dem Werkzeugaufruf, an der Werkzeugantwort und an der finalen Ausgabe. Die drei Punkte nach der Eingabe sind nicht Redundanz, sie sind der Ersatz für die Ebene, die es im Modell nicht gibt. Wer nur am Eingang filtert, hat eine WAF gekauft und die parametrisierten Abfragen weggelassen.

Der Termin, der wirklich zählt, ist nicht der Regulator

Viele Programme warten auf den AI Act. Dieser Druck ist gerade weggefallen. Mit dem Digital Omnibus, im Rat final bestätigt Ende Juni 2026, sind die Hochrisiko-Pflichten verschoben: eigenständige Systeme nach Anhang III auf den 2. Dezember 2027, KI in regulierten Produkten nach Anhang I auf den 2. August 2028. Seit dem 2. August 2026 gilt die Transparenzpflicht nach Artikel 50, mehr nicht.

Wer sein KI-Sicherheitsprogramm am AI Act aufgehängt hat, hat gerade sechzehn Monate geschenkt bekommen. Die Angreifer nicht.

Der Termin, der zählt, steht in einem anderen Dokument. 44 Prozent der befragten Sicherheitsverantwortlichen geben an, ihr Cyberversicherer verlange bereits heute einen Nachweis über Pentests des KI-Ökosystems. Nicht 2027. Beim nächsten Renewal.

Und bis vor sieben Wochen gab es für diesen Nachweis keinen anerkannten Massstab. Jetzt gibt es einen.

Was du in den nächsten neunzig Tagen tun kannst

Inventar vor Test. Kein Assessment ist etwas wert, solange niemand sagen kann, welche KI-Systeme, Agenten und Anbindungen produktiv laufen. Null von dreihundert Befragten haben hier volle Sicht. Das ist der erste Arbeitsschritt, nicht der letzte.

Massstab in den Vertrag. AISVS-Level festlegen, so wie du es bei ASVS längst tust. Die beiden Top-10-Listen als Bedrohungskatalog danebenlegen. Ein Angebot, das keinen Standard nennt, ist ein Angebot über unbestimmte Leistung.

Berechtigungen sind deine parametrisierte Abfrage. Der Sprung von Excessive Agency auf Platz drei ist keine Modellfrage, sondern eine Rechtefrage. Kurzlebige Anmeldeinformationen statt Dauer-Token, Rechte pro Aufgabe statt pro Agent, und für jede Werkzeuganbindung die Frage, was ein Angreifer damit anstellen könnte, der die Eingabe kontrolliert. Das ist die einzige Massnahme auf dieser Liste, die auch dann wirkt, wenn alles andere versagt.

Bestehende Guardrails auf Vollständigkeit prüfen. Die meisten Implementierungen sichern die Eingabe und lassen die Werkzeugkette offen. Lass dir zeigen, welche Kontrolle an welchem Punkt greift, und welche davon beim Anbieter noch als Vorschau ohne Service Level läuft.

Frequenz. Bei quartalsweiser Prüfung berichten 80 Prozent der Befragten Zuversicht in ihre KI-Sicherheit, bei jährlicher 71. Der eigentliche Grund liegt aber nicht in der Statistik: Modell, Systemprompt, Werkzeuge und Datenanbindungen ändern sich bei KI-Systemen monatlich. Ein Jahresbericht beschreibt ein System, das es so nicht mehr gibt.

Vor sieben Wochen war "es gibt dafür keinen Standard" noch eine Erklärung. Jetzt ist es eine Entschuldigung.