Wenn der Pentest mitdenkt!
KI wird Penetration Testing schneller, breiter und kontinuierlicher machen. Aber sie ersetzt nicht die Person, die entscheidet, was wirklich relevant, erlaubt und belastbar nachweisbar ist.
Pentest trifft KI: Mehr Angriffsfläche, weniger Zeit
Klassisches Penetration Testing findet in der Regel innerhalb eines definierten Zeitrahmens statt: Scope festlegen, testen, Findings validieren, Bericht schreiben, Maßnahmen besprechen. Dieses Modell bleibt relevant. Gerade für Compliance, Freigaben, Audits oder kritische Systeme braucht es klar abgegrenzte Tests mit sauberer Dokumentation.
Aber die Realität in vielen Unternehmen verändert sich. Anwendungen werden schneller gebaut, APIs werden häufiger angepasst, Fachbereiche experimentieren mit KI-Assistenten, Entwickler:innen nutzen Code-Generatoren und interne Workflows werden mit LLMs verbunden. Und irgendwo zwischen Prototyp, Pilot und produktivem System entsteht dann ein Stück Software, das niemand wirklich als „kritisch“ geplant hat, das aber plötzlich Daten liest, Entscheidungen vorbereitet oder interne Tools anstößt.
Genau hier verändert KI das Pentesting. Nicht, weil ein Modell alles allein erledigt, sondern weil wir mehr Angriffsfläche in kürzerer Zeit verstehen müssen.
| Klassischer Pentest | KI-unterstütztes Pentesting | Was gleich bleibt |
|---|---|---|
| Manuelle Exploration, Tooling, Erfahrung, Hypothesenbildung | Schnellere Reconnaissance, Code- und API-Analyse, Payload-Ideen, Mustererkennung, Berichtsvorarbeit | Scope, rechtliche Grenzen, Validierung, Impact, Priorisierung |
| Test innerhalb eines klar definierten Zeitrahmens | Kürzere Feedback-Zyklen, wiederholbare Checks, mehr Abdeckung bei Änderungen | Ein Finding zählt erst, wenn es nachvollziehbar und reproduzierbar ist |
| Fokus auf bekannte Anwendungsklassen | Zusätzlich Tests von LLMs, Agenten, RAG-Systemen und KI-gestützten Workflows | Verantwortung bleibt beim Menschen |
Was KI im Pentest schon heute sinnvoll unterstützt
KI kann im Pentesting viele Tätigkeiten beschleunigen, die früher viel manuelle Vorarbeit gebraucht haben. Besonders stark ist sie dort, wo große Mengen an Text, Code, Konfiguration oder Logik durchsucht, zusammengefasst und in Hypothesen übersetzt werden müssen. Das britische NCSC (National Cyber Security Centre) beschreibt genau diesen Bereich als einen der naheliegenden Verteidigungsnutzen von Frontier AI: schnellere Schwachstellensuche, Exploitability-Checks und das Mapping komplexer Angriffspfade.1
Typische Beispiele:
- API-Dokumentation und Endpunkte schneller erfassen.
- Quellcode nach auffälligen Mustern, fehlenden Checks oder gefährlichen Datenflüssen durchsuchen.
- Payload-Ideen für bestimmte Eingabepunkte vorschlagen.
- Ergebnisse aus Tools zusammenführen und erste Priorisierungen vorbereiten.
- Unterschiede zwischen Responses, Rollen oder Mandanten erkennen.
- Berichte strukturieren und technische Findings verständlicher formulieren.
- Testfälle für wiederkehrende Schwachstellenklassen generieren.
Aber es ist nicht dasselbe, wie ein fertiger Pentest. Ein Modell kann einen Verdacht erzeugen. Ein Pentester muss daraus einen belastbaren Nachweis erstellen.
| Pentest-Phase | Wo KI hilft | Wo der Mensch entscheidet |
|---|---|---|
| Scoping | Systembeschreibungen, Architekturtexte und APIs schneller verstehen. | Was ist kritisch, besonders sensibel, erlaubt oder ausgeschlossen? |
| Reconnaissance | Endpunkte, Parameter, Rollen, Datenflüsse und Technologien schneller kartieren. | Welche Hypothesen sind realistisch und welche sind nur Tool-Rauschen? |
| Exploitation | Payloads, Testvarianten und Angriffspfade schneller vorbereiten. | Wie weit darf ein Test gehen, ohne Betrieb oder Daten zu gefährden? |
| Validierung | Requests, Responses, Logs und Codepfade zusammenfassen. | Ist der Nachweis reproduzierbar, relevant und sauber dokumentiert? |
| Reporting | Findings strukturieren, Management-Summary vorbereiten. | Wie wird technischer Impact in geschäftliches Risiko übersetzt? |
Folglich ist KI ein Beschleuniger für den Arbeitsprozess, aber kein Ersatz für Verantwortung.
KI im Pentesting braucht klare Guardrails und Kontrolle
Wenn man KI im Pentesting einsetzen will, reicht es nicht, ein Modell an ein paar Tools anzuschließen und „mach mal“ zu sagen. Das wäre technisch spannend, organisatorisch aber fahrlässig.
Die folgende Grafik zeigt zunächst fünf konkrete Guardrail-Ebenen, die einen KI-gestützten Pentest kontrollierbar machen. Danach folgt eine Übersicht über die vier übergreifenden Herausforderungen, die dabei besonders wichtig sind.
Diese Guardrail-Ebenen sind ein Teil des Gesamtbildes. Auf einer höheren Ebene lassen sich die wichtigsten Herausforderungen in vier Bereiche gliedern:
| Herausforderung | Warum sie wichtig ist | Was das für Pentesting bedeutet |
|---|---|---|
| Verifizierbarkeit | KI kann plausibel formulieren, auch wenn die Schlussfolgerung falsch ist. | Findings brauchen reproduzierbare Schritte, Rohdaten, Requests, Responses, Screenshots, Logs und klare Impact-Belege. |
| Guardrails | Ein KI-System mit Tools kann Fehler nicht nur beschreiben, sondern auch herbeiführen. | Tool-Nutzung muss eingeschränkt, protokolliert und im Zweifel durch Menschen freigegeben werden. |
| Regulatorik | Testdaten, Kundendaten, Modellzugriffe und automatisierte Aktionen können rechtliche Anforderungen berühren. | Scope, Datenschutz, EU-AI-Act-Kontext, Logging und Auftragsverarbeitung müssen vor dem Test sauber geklärt sein. |
| Kontrollverlust | Autonome Systeme können unerwartete Pfade wählen oder Kontext verlieren. | Pentesting mit KI braucht klare Grenzen, Kill Switches, Rollenmodelle und Review-Schritte. |
Gerade bei LLM-basierten Systemen kommt noch ein spezielles Problem dazu: Das Modell unterscheidet nicht zuverlässig zwischen Daten und Anweisungen. Das NCSC beschreibt Prompt Injection – also das Einschleusen von LLM-Anweisungen via Text – deshalb nicht einfach als neue Variante von SQL Injection, sondern als grundlegend anderes Problem: LLMs haben keine harte Sicherheitsgrenze zwischen „Instruktion“ und „Daten“.2
Für Organisationen heißt das auch: KI-Sicherheit ist nicht nur ein technisches Pentest-Thema. NIST ordnet KI-Risiken ausdrücklich als Managementaufgabe ein, bei der Governance, Messbarkeit und laufende Steuerung zusammengehören.3 In Europa kommt mit dem AI Act zusätzlich ein regulatorischer Rahmen hinzu, der unter anderem Risikoklassen, Transparenzpflichten, Logging, menschliche Aufsicht und Anforderungen an Robustheit, Cybersecurity und Genauigkeit adressiert.4
Wenn ein Modell E-Mails liest, Tickets zusammenfasst, Kundendokumente verarbeitet oder Webseiten crawlt, dann können versteckte LLM-Anweisungen innerhalb nicht vertrauenswürdiger Inhalte potenziell Einfluss auf LLM-Aktionen nehmen. Und wenn das Modell zusätzlich Tools oder APIs verwenden darf, wird aus einem Textproblem ein Berechtigungsproblem.
Warum der Pentester „in der Loop“ bleiben muss
Es gibt einen Satz, den man in dieser Diskussion oft hört: „Aber wenn die KI alles schneller kann, brauchen wir dann überhaupt noch Pentester?“
Die Frage greift zu kurz. Ein Pentester ist nicht nur eine Person, die Payloads ausprobiert. Ein guter Pentester versteht, warum eine Schwachstelle im konkreten Unternehmen gefährlich ist. Er oder sie erkennt, ob eine technische Beobachtung nur interessant ist oder tatsächlich ein Geschäftsrisiko erzeugt. Und genau diese Übersetzungsleistung ist schwer zu automatisieren.
Ein Beispiel: Eine KI findet einen möglichen IDOR (Insecure Direct Object Reference) in einer API. Schön, aber was bedeutet das?
Kann man damit nur eine harmlose Einstellung lesen oder auch Kundendaten? Betrifft es einen Mandantenwechsel? Gibt es Logging? Gibt es eine nachgelagerte Freigabe? Kann man die Schwachstelle mit einer weiteren Fehlkonfiguration kombinieren? Ist der Angriff aus dem Internet möglich oder nur mit einem internen Testkonto? Welche Maßnahme ist realistisch?
Diese Fragen entscheiden darüber, ob aus einem Tool-Ergebnis ein relevantes Finding wird. "Deshalb gehört KI in den Pentest-Prozess, aber nicht auf den Fahrersitz ohne Aufsicht."
Der Pentester-in-the-Loop ist aus fünf Gründen notwendig:
- Scope und Legalität: Nicht alles, was technisch möglich ist, ist im Test erlaubt.
- Validierung: Ein Finding muss reproduzierbar sein, nicht nur plausibel klingen.
- Impact: Risiko entsteht aus Kontext, Daten, Berechtigungen und Geschäftsprozessen.
- Priorisierung: Unternehmen brauchen Reihenfolge, nicht nur eine lange Liste.
- Kommunikation: Ein gutes Finding erklärt, was zu tun ist und warum es wichtig ist.
Penetration Testing für KI-Workflows und LLM-Anwendungen
Darüber hinaus wir nicht mehr nur klassische Anwendungen mit etwas KI-Unterstützung getestet, sondern auch Anwendungen, die selbst KI verwenden.
Ein LLM in einem Unternehmensworkflow ist nicht einfach ein weiteres UI-Element. Es ist oft ein Vermittler zwischen Menschen, Datenquellen und Tools. Es liest Inhalte, bewertet sie, erzeugt Ausgaben und kann in Agentic-AI-Szenarien auch Aktionen anstoßen.
Damit entstehen neue Fragen:
- Kann ein Nutzer das Modell über Prompt Injection beeinflussen?
- Können externe Dokumente oder Webseiten den internen Workflow manipulieren?
- Werden sensible Daten in Prompts, Kontextfenstern, Logs oder Trainingsprozessen offengelegt?
- Hat der Agent zu viele Berechtigungen?
- Werden Modell-Ausgaben ungeprüft an APIs, Ticketsysteme, E-Mail oder Datenbanken übergeben?
- Ist nachvollziehbar, warum das System eine bestimmte Aktion vorgeschlagen oder ausgeführt hat?
- Gibt es menschliche Freigaben für riskante Aktionen?
OWASP listet in den Top 10 für LLM- und generative KI-Anwendungen genau solche Risikoklassen auf: Prompt Injection, Sensitive Information Disclosure, Data and Model Poisoning, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses und weitere.5
Für Unternehmen bedeutet das: Wenn LLMs in produktive Workflows eingebaut werden, braucht es nicht nur klassische AppSec. Es braucht Tests entlang der gesamten Kette:
| Ebene | Typische Frage | Risiko |
|---|---|---|
| Prompt und Kontext | Können nicht vertrauenswürdige Inhalte die Systemlogik beeinflussen? | Prompt Injection, Context Poisoning |
| Datenquellen und RAG | Sind Quellen vertrauenswürdig, aktuell und berechtigt? | Datenabfluss, falsche Entscheidungen, Mandantentrennung |
| Tool-Nutzung | Welche APIs darf das Modell verwenden? | Excessive Agency, ungewollte Aktionen |
| Output Handling | Wird Modelloutput validiert, bevor er weiterverarbeitet wird? | Injection, Fehlbuchungen, falsche Tickets, Datenmanipulation |
| Monitoring | Kann man Entscheidungen und Tool-Aufrufe nachvollziehen? | Keine Forensik, keine Verantwortlichkeit |
Vibe Coding: Die neue Angriffsfläche für Unternehmen
Ein Thema, das wir in der Praxis zunehmend sehen werden, ist Vibe Coding. Also Software, die sehr schnell mit Hilfe von KI gebaut wird: ein Prototyp, ein internes Tool, ein kleines Dashboard, ein Automatisierungsskript, ein „nur kurz für uns“-Portal.
Ein Thema, das wir in der Praxis zunehmend sehen werden, ist Vibe Coding. Also Software, die sehr schnell mit Hilfe von KI gebaut wird: ein Prototyp, ein internes Tool, ein kleines Dashboard, ein Automatisierungsskript, ein „nur kurz für uns“-Portal.
Das ist nicht automatisch schlecht. Im Gegenteil: Für Innovation ist das großartig. Fachbereiche können Dinge ausprobieren, Entwickler:innen werden schneller, Ideen landen früher in testbarer Form.
Das Problem entsteht, wenn aus dem Prototyp still und leise Produktion wird. Dann steht da plötzlich eine Anwendung, die:
- Secrets in Konfigurationsdateien oder Repositories enthält,
- Authentifizierung und Autorisierung nur oberflächlich umsetzt,
- personenbezogene Daten verarbeitet,
- externe APIs nutzt,
- generierte Dependencies ungeprüft übernimmt,
- keine saubere Fehlerbehandlung hat,
- intern erreichbar ist, aber praktisch produktiv genutzt wird.
Aus Security-Sicht ist das kein Randthema. Das ist wahrscheinlich eine der spannendsten neuen Angriffsflächen der nächsten Jahre.
Und genau hier kann CANCOM Unternehmen helfen: Nicht, indem Innovation gebremst wird, sondern indem schnell gebaute Software ernst genommen werden. Auch „vibe-coded“-Tools brauchen Threat Modeling, Code Review, Secret Scanning, Authentication- und Authorization-Tests, Dependency-Prüfung und einen Blick auf Datenflüsse. "Oder etwas direkter gesagt: Wenn ein Tool einen Geschäftsprozess unterstützt, dann ist es kein Spielzeug mehr."
Wie Unternehmen von CANCOM profitieren können
Für Unternehmen wird die zentrale Frage nicht lauten: „Setzen wir KI ein?“. Die realistischere Frage lautet: „Wo setzen wir KI bereits ein, ohne es vollständig zu überblicken?“. Genau dort wird Security-Arbeit wertvoll.
Neben klassischen Penetration Tests und Red Teamings können wir Unternehmen dabei unterstützen, KI-bezogene Risiken greifbar zu machen, ohne gleich jedes Experiment abzuwürgen. Es geht nicht darum, Fachbereiche zu verlangsamen. Es geht darum, früh genug zu erkennen, wo aus Experimenten echte Angriffsflächen werden.
Praktisch heißt das:
- Wir testen weiterhin klassische Anwendungen, APIs, Infrastruktur und Angriffsketten.
- Wir betrachten zusätzlich KI-gestützte Entwicklungs- und Betriebsprozesse.
- Wir prüfen „vibe-coded“ Tools und Prototypen, bevor sie unkontrolliert produktiv werden.
- Wir testen LLMs, RAG-Systeme und Agenten, die in Workflows oder Infrastruktur eingebunden sind.
- Wir bewerten Guardrails, Berechtigungen, Logging, Human Approval und Datenflüsse.
- Wir helfen dabei, Findings so zu formulieren, dass technische Teams und Management damit arbeiten können.
Pentesting wird stärker KI-unterstützt. KI-Anwendungen selbst werden intensiver getestet werden müssen. Und Unternehmen werden Partner brauchen, die beides verstehen: klassische Offensive Security und die neuen Risiken rund um LLMs, Agenten und Automatisierung.
Fazit: KI wird Pentesting verändern. Nicht irgendwann, sondern jetzt.
KI wird uns helfen, mehr Code, mehr Konfigurationen, mehr APIs und mehr Angriffspfade schneller zu prüfen. Sie wird repetitive Arbeit reduzieren und Hypothesen schneller erzeugen. Sie wird auch Unternehmen helfen, Security früher in Entwicklungsprozesse zu integrieren.
Aber sie nimmt uns nicht die wichtigste Arbeit ab: sauber zu beweisen, was wirklich ausnutzbar ist, was das im konkreten Unternehmenskontext bedeutet und welche Maßnahmen den größten Sicherheitsgewinn bringen.
Die Zukunft des Pentestings ist daher nicht „Mensch oder KI“. Sie ist „Mensch mit KI“, aber mit klaren Grenzen, sauberer Dokumentation und belastbarer Validierung.
Quellen:
1. Why cyber defenders need to be ready for frontier AI
2. Prompt injection is not SQL injection (it may be worse)
3. AI Risk Management Framework
4. AI Act
5. 2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps
