Large Language Models stecken heute in Chatbots, Copiloten, Wissensdatenbanken (RAG), Automatisierungen und teilautonomen Agenten. Sie sind produktiv im Einsatz und verarbeiten dabei sensible Daten, treffen Vorentscheidungen und lösen Aktionen in angebundenen Systemen aus. Damit werden sie selbst zur Angriffsfläche, und zwar auf eine Art, die klassische Penetrationstests und automatisierte Scanner nicht abdecken.
Wir prüfen Ihre KI-Systeme entlang der etablierten Standards und sichern sie anschließend gemeinsam mit Ihnen ab: Prüfung und Härtung aus einer Hand, von denselben Leuten.
zentrust partners ist vom BSI als IT-Sicherheitsdienstleister im Geltungsbereich IS-Penetrationstests anerkannt (Stellen-ID BSI-APS-9080). Für die Prüfung von KI-Systemen orientieren wir uns am Leitfaden für Penetrationstests von Large-Language-Modellen des Expertenkreises KI-Sicherheit der Allianz für Cyber-Sicherheit sowie an der OWASP Top 10 für LLM-Anwendungen 2025. So bleibt die Prüfung nachvollziehbar, vergleichbar und anschlussfähig an Audits.
Kostenfreies Erstgespräch vereinbaren
Warum KI-Systeme eine eigene Prüfung brauchen
Ein Penetrationstest eines KI-Systems ist kein gewöhnlicher Anwendungstest mit ein paar Zusatzfragen. Drei Eigenschaften machen den Unterschied:
- Nicht-deterministisches Verhalten. Dieselbe Eingabe kann unterschiedliche Antworten erzeugen. Ob eine Schwachstelle existiert, lässt sich oft erst durch mehrfach wiederholte und variierte Prüfungen belastbar beurteilen. Es bleibt eine Restunsicherheit, die dokumentiert und über Metriken wie die Attack Success Rate greifbar gemacht werden muss.
- Angriffe, die nicht im Quellcode stehen. Prompt Injection kommt häufig indirekt über die Inhalte, die das Modell verarbeitet: hochgeladene Dokumente, abgerufene Webseiten, E-Mails oder Einträge in einer Wissensdatenbank. Eine reine Codeanalyse findet solche Angriffspfade nicht.
- Grenzen automatisierter Scanner. Öffentlich verfügbare LLM-Scanner decken einzelne Angriffsklassen ab, vernachlässigen aber kombinierte und komplexe Szenarien. Sie ersetzen keine manuelle, kreative Prüfung durch erfahrene Tester. Genau deshalb kombinieren wir mehrere Werkzeuge mit gezielter Handarbeit.
| Aspekt | Klassischer Pentest | KI-Pentest |
|---|---|---|
| Verhalten des Prüfobjekts | deterministisch, reproduzierbar | probabilistisch, mit Restunsicherheit |
| Zentrale Angriffsvektoren | Injection, Zugriffskontrolle, Fehlkonfiguration | Prompt Injection, Datenabfluss, überzogene Handlungsvollmacht (Excessive Agency) |
| Eingabequellen | definierte Schnittstellen | auch externe Inhalte: Dokumente, Webseiten, RAG-Kontext |
| Aussagekraft | einmalige Prüfung genügt oft | Wiederholungen und Variationen nötig, Bewertung über Metriken |
Was wir prüfen
Wir prüfen entlang der OWASP Top 10 für LLM-Anwendungen 2025, dem international anerkannten Katalog der wichtigsten Risiken, und ergänzen ihn um die Risikoszenarien und Prüfschwerpunkte des BSI-Leitfadens. So verbinden wir internationale Wiedererkennbarkeit mit der Prüftiefe der deutschen Fachpublikation.
Typische Systeme, die wir prüfen: Kundenchatbots und Support-Assistenten, Wissensdatenbanken mit RAG, Dokumenten- und Analyse-Assistenten, Code-Assistenten sowie teilautonome Agenten mit Werkzeug- und Systemzugriff.
LLM01 Prompt Injection
Manipulierte Eingaben verändern das Modellverhalten, umgehen Schutzregeln oder verleiten das Modell zu unerwünschten Aktionen. Wir prüfen sowohl direkte Prompt Injection als auch indirekte Angriffe über Dokumente, Webseiten und RAG-Inhalte, die das Modell verarbeitet.
Beispiel: In ein hochgeladenes PDF eingebetteter, für den Nutzer unsichtbarer Text weist das Modell an, interne Regeln zu ignorieren.
LLM02 Sensitive Information Disclosure
Das Modell gibt sensible Informationen preis: personenbezogene Daten, Geschäftsgeheimnisse, Zugangsdaten oder Rückschlüsse auf Trainingsdaten (Modell-Inversion, Membership Inference). Wir prüfen, ob Filter, Kontexttrennung und Berechtigungen greifen.
Beispiel: Ein Support-Assistent gibt auf geschickte Nachfrage Daten anderer Kunden oder hinterlegte Zugangsdaten preis.
LLM03 Supply Chain
Schwachstellen in zugekauften Modellen, Adaptern, Bibliotheken und Trainingsdaten. Wir bewerten die Herkunft und Integrität der eingesetzten Komponenten und Abhängigkeiten.
Beispiel: Ein aus einer öffentlichen Quelle bezogenes Modell oder ein Adapter enthält eine manipulierte Komponente.
LLM04 Data and Model Poisoning
Manipulierte Trainings-, Fine-Tuning- oder Einbettungsdaten schleusen Hintertüren, Bias oder Fehlverhalten ein. Wir prüfen die Datenpfade, aus denen Ihr System lernt und Kontext bezieht.
Beispiel: Ein vergifteter Eintrag in der Wissensdatenbank bringt das Modell bei bestimmten Stichworten gezielt zu falschen Ausgaben.
LLM05 Improper Output Handling
Modellausgaben werden ungeprüft an nachgelagerte Systeme weitergereicht und ermöglichen so Cross-Site-Scripting, SSRF, SQL-Injection oder Codeausführung. Wir prüfen die Verarbeitung der Ausgaben in Ihrer Anwendung.
Beispiel: Eine ungeprüft übernommene Modellausgabe enthält Skriptcode, der im Browser des Nutzers ausgeführt wird.
LLM06 Excessive Agency
Agenten mit zu weitreichenden Berechtigungen, Werkzeugen oder Autonomie lösen schädliche Aktionen aus. Wir prüfen Rechtevergabe, Werkzeugzugriff und menschliche Freigaben. Ein Test gilt hier erst als bestanden, wenn das Werkzeug selbst die Ausführung verweigert, weil die Berechtigung an der Identität des aufrufenden Nutzers hängt, nicht an der Modellausgabe. Auch MCP Tool Poisoning, bei dem schon die Beschreibung eines angebundenen Werkzeugs das Modell manipuliert, prüfen wir.
Beispiel: Ein Agent mit Schreibrechten verschickt oder löscht Daten, weil eine manipulierte Eingabe ihn dazu verleitet.
LLM07 System Prompt Leakage
System-Prompts enthalten oft Regeln, Logik oder Geheimnisse, die nicht offengelegt werden dürfen. Wir prüfen, ob sich diese extrahieren lassen und ob sicherheitsrelevante Entscheidungen fälschlich im Prompt liegen.
Beispiel: Ein Nutzer bringt das Modell dazu, seinen System-Prompt samt hinterlegter Regeln oder Schlüssel auszugeben.
LLM08 Vector and Embedding Weaknesses
Schwächen in RAG-Systemen und Vektordatenbanken: Datenlecks über Einbettungen, Vergiftung des Retrieval-Kontexts und fehlende Mandantentrennung. Wir prüfen die gesamte RAG-Pipeline.
Beispiel: Über gezielte Anfragen gelangen Inhalte eines anderen Mandanten aus der Vektordatenbank in die Antwort.
LLM09 Misinformation
Halluzinationen und plausibel wirkende, aber falsche Ausgaben, auf die Nutzer oder angebundene Systeme vertrauen. Wir prüfen Absicherungen wie Quellenbindung, Validierung und Ausgabeprüfung.
Beispiel: Ein Assistent erfindet ein nicht existierendes Gerichtsurteil, auf das sich ein Sachbearbeiter verlässt.
LLM10 Unbounded Consumption
Unbegrenzter Ressourcenverbrauch führt zu Denial of Service, überraschenden Kosten (Denial of Wallet) oder Modell-Extraktion durch Massenabfragen. Wir prüfen Ratenlimits, Kontingente und Missbrauchserkennung.
Beispiel: Massenhafte, aufwendige Anfragen treiben die Kosten in die Höhe oder legen den Dienst lahm.
Prüfobjekt: Modell, Schnittstelle und Eingabe
Der BSI-Leitfaden unterscheidet drei Ebenen des Prüfobjekts, die wir gezielt betrachten. Für zugekaufte Modelle liegt der Schwerpunkt auf der Einbindung in Ihre Anwendung, nicht auf dem fremden Foundation-Modell selbst.
- Das Modell und seine Einbindung: eingesetztes Modell, Konfiguration, System-Prompt sowie Fine-Tuning und Guardrails, soweit vorhanden.
- API-Schnittstellen: Authentifizierung, Autorisierung, Rate Limiting und Absicherung der Zugänge zum Modell.
- Eingabemechanismen: alle Punkte, an denen Daten in das Modell gelangen, ausdrücklich auch externe Quellen wie Webseiten, Dokumente und E-Mails.
Integrationsformen als Prüfschwerpunkt
Moderne KI-Anwendungen sind mehr als ein Modell hinter einer Chatoberfläche. Wir prüfen die sicherheitskritischen Integrationsformen aus dem BSI-Leitfaden:
- Retrieval Augmented Generation (RAG) und Vektordatenbanken
- Agentensysteme sowie Werkzeug- und Funktionsaufrufe (Tool- und Function-Calling)
- Model Context Protocol (MCP) und angebundene Dienste
- Codegenerierung und Codeausführung
- Web- und Dokumentenkontext sowie Websuche
- Cyberphysische Agentensysteme, bei denen KI auf Hardware und Aktorik wirkt
Hardware ist für uns kein reines Software-Thema. Cyberphysische Agentensysteme verbinden KI mit realer Aktorik. Unser Mitgründer Sven Faßbender ist gelernter Elektroniker für Betriebstechnik und staatlich geprüfter Techniker der Fachrichtung Elektrotechnik. Diese Kombination aus KI-, Software- und Hardware-Kompetenz finden Sie selten bei einem Anbieter.
Prüftiefe
Die Prüftiefe stimmen wir vorab mit Ihnen ab. Möglich sind Blackbox-Tests (Verhalten ohne Kenntnis der internen Struktur), Whitebox-Tests (mit Zugang zu Architektur, Konfiguration und Prompts) und Graybox-Tests als Kombination. Für ein belastbares Ergebnis empfehlen wir in der Regel einen Whitebox- oder Graybox-Ansatz.
Wie wir prüfen
Wir folgen dem vierphasigen Ablauf des BSI-Leitfadens. Er versteht Pentesting als iterativen Prozess, der bei wesentlichen Änderungen und in regelmäßigen Abständen wiederholt wird.
Phase 1: Business Understanding und Ist-Analyse
Wir entwickeln ein tiefes Verständnis für Zielsetzung, Zielgruppe und Ist-Zustand Ihrer Anwendung: gewählte Bereitstellung, Integrationen in Ihre Geschäftsprozesse, relevante Geschäftsrisiken und Compliance-Anforderungen. Auf dieser Basis analysieren wir die Architektur auf Infrastruktur-, API- und Applikationsebene, definieren den Scope und legen Prioritäten fest.
Im vorbereitenden Gespräch klären wir Zeitraum, Budget und Umfang, die benötigte Unterstützung, die Testumgebung (üblicherweise Staging oder Development statt Produktion, mit ausdrücklicher schriftlicher Freigabe) und gehen einen strukturierten Fragebogen gemeinsam Punkt für Punkt durch.
Phase 2: Threat Modeling, Priorisierung und Testplanung
Wir erstellen ein Bedrohungsmodell mit etablierten Methoden wie STRIDE oder PASTA und orientieren uns an MITRE ATLAS, der KI-spezifischen Wissensbasis für Angreifertechniken. Daraus leiten wir eine gezielte Teststrategie mit definierten Szenarien ab. Aus den Risikoszenarien und dem Fragebogen priorisieren wir die Tests gemeinsam mit Ihnen und im Rahmen des Budgets, für eine bestmögliche Abdeckung der relevanten Risiken. Was nicht getestet wird, halten wir transparent fest.
Phase 3: Test und Dokumentation
Unsere Prüfer führen die geplanten Angriffe durch und kombinieren dabei mehrere Werkzeuge mit manueller, kreativer Analyse. Wegen des nicht-deterministischen Verhaltens führen wir aussagekritische Prompts mehrfach und in Variationen aus und bewerten die Ergebnisse über Metriken wie Attack Success Rate, Detection Rate und Jailbreak Success Rate. Wir prüfen dabei nicht nur einzelne Eingaben, sondern auch mehrstufige Angriffe über viele Gesprächsrunden: Schutzregeln, die eine einzelne Anfrage abwehren, geben oft nach, wenn ein Angreifer über mehrere Schritte Vertrauen aufbaut oder die Anfrage aufteilt. Jeder Schritt wird nachvollziehbar dokumentiert.
Phase 4: Evaluation, Risikobewertung und Reporting
Wir bewerten die Funde nach Schweregrad und Auswirkung, gleichen kritische Befunde mit Ihren Geschäftsrisiken ab und leiten konkrete Härtungsempfehlungen ab. In einer Abschlusspräsentation besprechen wir die Ergebnisse, bevor der finale Bericht entsteht. Zusätzlich schlagen wir einen Zeitraum für die nächste Prüfung vor, um die kontinuierliche Überwachung zu unterstützen.
Der Prüfbericht gliedert sich in eine Management-Zusammenfassung für Entscheidungstragende (durchgeführte Tests, wichtigste Schwachstellen nach Kritikalität, Handlungsempfehlungen und mögliche Auswirkungen) und einen technischen Bericht für Ihre Teams (Testzeitraum, Zielsysteme, Einschränkungen, Methodik und Werkzeuge sowie je Befund die Beschreibung, betroffene Komponente, Reproduktionsschritte und eine Bewertung nach CVSS, bei Bedarf in Anlehnung an den BSI-Standard 200-3). Belege wie Screenshots und Logs liefern wir im Anhang.
Rechtlicher Rahmen. Der rechtliche Rahmen für Penetrationstests ist bislang nicht abschließend gesetzlich geregelt. Ohne eindeutige Einwilligung besteht ein Strafbarkeitsrisiko nach den §§ 202a bis c und 303a bis b StGB. Vor Beginn vereinbaren wir daher eine schriftliche Freigabeerklärung (Rules of Engagement) mit Scope, Testzeitraum, zulässigen Methoden, Haftungsfragen und Kommunikationswegen sowie ein NDA und, wo personenbezogene Daten betroffen sind, die nötigen datenschutzrechtlichen Vereinbarungen. Datenschutz hat bei uns jederzeit höchste Priorität.
Wie Sie sich schützen können
Eine Prüfung zeigt, wo es klemmt. Damit die Lücken auch geschlossen werden, braucht es konkrete Schutzmaßnahmen im Betrieb Ihrer KI-Systeme:
Prüfung und Bereinigung von Eingaben und Ausgaben, Erkennung von Prompt Injection und sichere Weiterverarbeitung der Modellantworten.
Härtung des System-Prompts, Trennung von Geheimnissen und Logik, damit sicherheitsrelevante Entscheidungen nicht im Prompt liegen.
Minimale Rechte und Werkzeugzugriffe, menschliche Freigaben bei kritischen Aktionen, um überzogene Handlungsvollmacht zu begrenzen.
Ratenlimits, Kontingente und Missbrauchserkennung gegen unbegrenzten Verbrauch, dazu eine belastbare Protokollierung für die Nachvollziehbarkeit.
Wie wir Sie dabei unterstützen
Wir begleiten Sie bei der Härtung und beim sicheren Betrieb, auf Wunsch direkt im Anschluss an den Test. Über die technische Härtung hinaus verankern wir KI-Sicherheit in Ihrer Organisation:
- KI-Governance und sicherer Betrieb: Richtlinien, Datenklassifizierung, Freigabeprozesse und menschliche Kontrolle. Eingebettet in Ihr Informationssicherheits-Management.
- Sichere Entwicklung: Wir verankern sichere Entwicklungspraktiken für KI-Anwendungen in Ihren Teams, von Richtlinien bis zu Secure-Coding-Schulungen.
- Architektur-Review und Threat Modeling: Bedrohungsmodellierung und Architektur-Reviews schon im Entwurf, bevor Schwachstellen in den Betrieb gelangen.
- Schulungen: passende Schulungen für Entwickler und Führungskräfte zur sicheren Nutzung und Integration von KI.
- Nachtest der Wirksamkeit: Nach der Behebung prüfen wir auf Wunsch gezielt nach. Wir testen die zuvor gefundenen Schwachstellen erneut, wiederholt und in Variationen, und weisen über dieselben Metriken nach, ob die Härtung tatsächlich greift.
- Nachweise für KI-Managementsysteme: Auf Wunsch bereiten wir die Prüfergebnisse als messbare Nachweise für ein KI-Managementsystem nach ISO/IEC 42001 auf und ordnen sie in den NIST AI RMF ein. Zertifiziert wird dabei die Organisation, nicht der einzelne Test. Wir liefern die Evidenz.
Regulatorischer Rahmen
KI-Pentests sind nicht als solche gesetzlich vorgeschrieben. Sie sind aber ein anerkanntes Mittel, um die Wirksamkeit Ihrer Sicherheitsmaßnahmen nachzuweisen, und zahlen auf mehrere regulatorische Anforderungen ein:
- AI Act: Für Hochrisiko-KI verlangt die Verordnung Robustheit, Genauigkeit und Cybersicherheit über den Lebenszyklus. Artikel 15 nennt ausdrücklich Datenvergiftung, Modellvergiftung und adversariale Beispiele als abzuwehrende Angriffe, ohne einen Penetrationstest vorzuschreiben. Sicherheitsprüfungen belegen diese Eigenschaften.
- NIS-2: Konzepte und Verfahren zur Bewertung der Wirksamkeit der Risikomanagementmaßnahmen (Artikel 21), wofür sich Penetrationstests etabliert haben.
- BSI C5: Kriterienkatalog für Cloud-Dienste. Die Attestierung setzt regelmäßige Schwachstellen- und Penetrationstests beim Anbieter voraus.
- DORA: Für von den Aufsichtsbehörden benannte Finanzunternehmen sind mindestens alle drei Jahre bedrohungsgeleitete Penetrationstests (TLPT) auf produktiven Systemen kritischer oder wichtiger Funktionen vorgesehen. Sind KI-gestützte Systeme Teil dieser Funktionen, fallen sie in den Scope.
- Cyber Resilience Act: Sicherheitsnachweise für Produkte mit digitalen Elementen, zunehmend auch mit KI-Anteil.
- DSGVO: Schutz personenbezogener Daten, die von KI-Systemen verarbeitet werden.
Welche Anforderungen für Sie konkret gelten, ordnen wir im Erstgespräch ein.
Warum zentrust partners
- Vom BSI zertifizierter IS-Penetrationstest-Dienstleister (Stellen-ID BSI-APS-9080), überprüfbar im offiziellen BSI-Verzeichnis.
- Prüfung und Absicherung aus einer Hand: Wer die Lücken findet, spricht auch die Empfehlungen aus und begleitet die Behebung.
- Kombination aus automatisierten Verfahren und manueller, kreativer Analyse, statt Verlass auf einen einzelnen Scanner.
- KI-, Software- und Hardware-Kompetenz unter einem Dach, bis hin zu cyberphysischen Agentensystemen.
- Eigene Sicherheitsforschung: Unsere Prüfer veröffentlichen CVEs und Coordinated Disclosures und wurden als Sachverständige in Ausschüssen des Deutschen Bundestages angehört. Mehr über uns und im Blog.
- Management-taugliche Berichte mit klarer Risikobewertung nach CVSS und priorisierten Maßnahmen.
Häufige Fragen
Testet ihr gegen unser Produktivsystem?
Üblicherweise nicht. Wir testen bevorzugt in einer Staging- oder Testumgebung, die der Produktion entspricht. So vermeiden wir Betriebsrisiken und unnötige Kosten, insbesondere bei kostenpflichtigen Modell-APIs. Ausnahmen stimmen wir vorab schriftlich ab.
Wir nutzen ein zugekauftes Modell. Was lässt sich da prüfen?
Sehr viel. Die meisten Risiken entstehen nicht im Foundation-Modell, sondern in seiner Einbindung: System-Prompt, RAG-Kontext, Werkzeuge und Agenten, API-Absicherung und die Verarbeitung der Ausgaben. Genau diese Anwendungsebene prüfen wir.
Reichen nicht Guardrails und ein Filter?
Sie helfen, genügen aber nicht. Filter und Guardrails lassen sich umgehen, besonders über indirekte Prompt Injection. Belastbar wird die Aussage erst durch eine Prüfung, die mehrere Werkzeuge mit manueller Analyse kombiniert und Prompts wiederholt und variiert.
Wie oft sollten wir prüfen?
KI-Systeme und ihre Bedrohungen entwickeln sich schnell. Sinnvoll ist eine Prüfung bei wesentlichen Änderungen an Modell, Prompt oder Integration sowie in regelmäßigen Abständen. Einen konkreten Vorschlag für den nächsten Prüfzeitpunkt legen wir in den Bericht.
Noch keine eigene Informationssicherheits-Organisation? Wenn Sie KI einsetzen, aber noch keinen Informationssicherheitsbeauftragten und kein gelebtes ISMS haben, ist der kostenfreie CyberRisikoCheck nach DIN SPEC 27076 oft der bessere erste Schritt. Einen Überblick über die veränderte Bedrohungslage durch KI gibt unsere Seite Künstliche Intelligenz, was jetzt?