Prüft Ihr Pentest nur die Web-Schicht oder auch, was Ihr KI-Assistent oder Agent mit Werkzeugen und Daten tut?
Ein LLM-Pentest prüft Chatbots, Copilots und KI-Agenten darauf, ob Angreifer sie über manipulierte Eingaben umlenken können. Im Fokus stehen direkte und indirekte Prompt Injection, die Offenlegung des Systemkontexts und der Missbrauch angebundener Werkzeuge. Dazu kommen Berechtigungen in angebundenen Wissensquellen (RAG). Geprüft entlang OWASP Top 10 for LLM Applications, der OWASP API Security Top 10, dem OWASP Web Security Testing Guide (WSTG) 4.2 und dem BSI/ACS-Leitfaden für Penetrationstests von Large-Language-Modellen (LLMs).
Eine Anwendung mit einem Sprachmodell verarbeitet Eingaben, denen Sie nicht vertrauen können, und trifft daraus Entscheidungen oder ruft als KI-Agent selbstständig angebundene Werkzeuge auf. Damit entsteht eine Angriffsfläche, die klassische Web-Prüfungen nicht abdecken: Die Grenze zwischen Anweisung und Daten verschwimmt und ein geschickt formulierter Text kann das Verhalten des Systems verändern.
Die praktisch relevanten Angriffe sind keine Spielerei mehr. Eine indirekte Prompt Injection über ein eingebettetes Dokument, das Abgreifen des Systemkontexts, der Missbrauch angebundener Werkzeuge oder das Überschreiten von Berechtigungen über den Modellzugriff sind reale Wege. Wir prüfen die Anwendung als Ganzes, das Modell, seinen Kontext, die angebundenen Datenquellen und Werkzeuge, entlang etablierter Referenzen für KI-Sicherheit.
Wir prüfen, ob sich das Verhalten über die Eingabe steuern lässt und ob eingebettete Inhalte aus Dokumenten oder Webquellen unerwünschte Anweisungen einschleusen.
Wir testen, ob sich Systemanweisungen, verborgene Regeln oder sensible Kontextdaten aus dem Modell herauslocken lassen.
Wo das Modell Werkzeuge oder Aktionen auslöst, prüfen wir, ob sich diese über manipulierte Eingaben zweckentfremden lassen.
Wir prüfen, ob der Weg über das Modell Berechtigungen umgeht und Zugriff auf Daten öffnet, die den Nutzenden nicht zustehen, etwa in angebundenen Wissensquellen.
Wir bewerten, ob unsichere oder schädliche Ausgaben entstehen und in nachgelagerten Systemen Schaden anrichten können.
Ein LLM-Pentest greift Ihre KI-Anwendung so an, wie es ein Angreifer über Eingaben, Dokumente oder Webinhalte tun würde, von der Nutzereingabe bis zu angebundenen Datenquellen und Werkzeugen. Gedacht ist er für Unternehmen, die Chatbots, Copilots, RAG-Anwendungen oder KI-Agenten einsetzen oder anbieten. Ob sich der Test lohnt, entscheidet vor allem, was das Modell darf. Greift es auf internes Wissen zu, ruft Daten ab, führt Werkzeuge oder Code aus oder stößt Abläufe an, prüfen wir, ob sich das für Datenabfluss, einen Ausbruch aus der Sandbox oder den Missbrauch von Workflows nutzen lässt. Weil die KI-Schicht darauf aufsetzt, ist die Kombination mit Webanwendungen und APIs oder der Cloud oft sinnvoll. Danach eignet sich ein Technischer Workshop, bei regulatorischen Anforderungen verweisen wir auf ProSec Governance.
Wir klären Architektur, angebundene Datenquellen und Werkzeuge, Rollen und die Testparameter, inklusive eines Zustands mit eingefrorenem Stand.
Wir leiten die relevanten Angriffsszenarien aus der konkreten Anwendung ab, statt generisch zu prüfen.
Wir arbeiten die Szenarien systematisch ab und dokumentieren Angriffserfolg und, wo vorhanden, die Erkennung.
Befunde und Bewertung werden vor Übergabe gegengeprüft.
Sie erhalten Befunde mit Angriffsweg, Auswirkung und Empfehlung und gehen sie mit uns durch.
Zuerst die technischen Erkenntnisse für Ihr IT-Team, dann der Plan für die Behebung, dann die Zusammenfassung für Ihre Geschäftsführung und die Prüfbescheinigung für Kunden, Auditoren oder Versicherer. Alles beruht auf denselben Befunden.
Jeder Befund mit Nachweis, Einordnung nach Schweregrad, Auswirkung und Relevanz für Ihre Umgebung, dazu die Liste der betroffenen Systeme und Geräte. Nachvollziehbar und auf Wunsch in einem Retest überprüfbar.
Ein priorisierter Actionplan mit klaren Verantwortlichkeiten, optional geschärft im Technischen Workshop mit Ihrem Team. Er ist die Grundlage für die Behebung und auf Wunsch begleiten wir die Umsetzung bis zum Retest.
Lage, Risiko und Entscheidungsbedarf auf wenigen Seiten, verständlich ohne technisches Vorwissen. Damit nehmen Sie Geschäftsführung, Gremien und Fachbereiche mit, um das Ergebnis zu vermitteln und Handlungsbedarf aufzuzeigen.
Die Bestätigung der durchgeführten Prüfung, ohne technische Details preiszugeben. Für Kunden, Auditoren, Aufsicht und Ihre Cyberversicherung.
Diese Prüfung betrachtet die KI-Schicht mit Modell, Kontext und Anbindung. Darunter liegen Webanwendung, API und Cloud, und bei laufender Weiterentwicklung ändert sich die Angriffsfläche mit jedem Release.
Wenn die KI-Funktion in eine bestehende Webanwendung oder API eingebettet ist, prüft Webanwendungen & APIs Authentifizierung, Sitzungen und Geschäftslogik darunter.
Zur LeistungKombinierbar, sobald Modell, Wissensquellen oder Werkzeuge in der Cloud oder in Microsoft 365 laufen und deren Identitäten und Berechtigungen mitbewertet werden sollen.
Zur LeistungWenn Prompts, Modelle oder Anbindungen regelmäßig wechseln, halten Prüfungen im Release-Takt den Stand aktuell.
Zur LeistungSchildern Sie kurz, worum es geht. Den Zuschnitt erarbeiten wir mit Ihnen im Scoping. Für das Beratungsgespräch müssen
Sie sich nicht vorbereiten, wir führen Sie fachlich Schritt für Schritt. Ausgehend von Ihren Unternehmensabläufen und IT-Systemen ermitteln wir gemeinsam das passende Testkonzept.
Diese Fragen erreichen uns zu dieser Leistung am häufigsten. Was fehlt, klären wir gern persönlich im Beratungsgespräch.
Ein LLM-Pentest kann einen Baustein für die Anforderungen des AI Act liefern, ersetzt aber keine Konformitätsbewertung. Für Hochrisiko-KI-Systeme verlangt der AI Act unter anderem ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit (Art. 15 AI Act). Seit der Änderung durch die Verordnung (EU) 2026/1744 gelten die Pflichten für Hochrisiko-KI-Systeme nach Anhang III ab 2. Dezember 2027 und nach Anhang I ab 2. August 2028. Die regulatorische Begleitung liegt bei ProSec Governance.
Beides, je nach Fragestellung. Die größte Aussagekraft hat die Prüfung der Anwendung als Ganzes: das Modell im Zusammenspiel mit Ihren Datenquellen, Werkzeugen und Berechtigungen. Gezielte Tests nur für das Modell oder nur für Ihre Agenten bieten wir ebenfalls an. Welcher Zuschnitt passt, legen wir im Scoping fest.
Wir arbeiten mit einem definierten, eingefrorenen Stand während des Tests und dokumentieren die Angriffswege so, dass sie nachvollziehbar und wiederholbar bleiben. Bei einer wesentlichen Änderung des Modells oder der Anbindung ist eine erneute Prüfung sinnvoll.
Ein LLM-Penetrationstest, auch KI-Pentest genannt, prüft eine Anwendung mit Sprachmodell auf Angriffe gegen das Zusammenspiel von Eingabe, Modell, Kontext und angebundenen Werkzeugen. Dazu gehören Prompt Injection, die Offenlegung von Systemanweisungen und der Missbrauch von Berechtigungen. Referenzen sind die OWASP Top 10 for LLM Applications, die OWASP API Security Top 10 und der OWASP WSTG 4.2.
Bei der direkten Prompt Injection steht die manipulierende Anweisung in der Eingabe der Nutzenden, bei der indirekten in Inhalten, die das Modell verarbeitet, etwa einem Dokument, einer E-Mail oder einer Webseite. Die indirekte Variante ist oft gefährlicher, weil der Angreifer keinen direkten Zugang zur Anwendung braucht. Wir prüfen beide Wege.
Ein Test mit Einblick in Systemanweisungen, Anbindungen und Berechtigungen kommt in derselben Zeit deutlich tiefer. Ein Test ohne Vorwissen ist ebenfalls möglich und zeigt, was ein externer Angreifer sieht. Welcher Zuschnitt passt, legen wir im Scoping fest.
Ja, im Rahmen dessen, was der Anbieter erlaubt. Geprüft werden dann Ihre Konfiguration und die Anbindung an eigene Daten oder Werkzeuge, nicht das Basismodell des Anbieters. Methodisch liegt das näher an einem Audit, mit Techniken aus dem Pentest. Einen Copilot ohne eigene Integrationen allein zu testen, bringt wenig. Für Microsoft 365 Copilot ist meist die Prüfung unter Cloud & Microsoft 365 der sinnvollere Weg. Die Prüfung geht dort in Richtung Audit, arbeitet aber mit Methoden aus dem Pentest. Einen Copilot ohne Integrationen zu testen bringt wenig; dann ist ein Cloud-Audit der sinnvollere Einstieg. Ist er an Daten, Tools und Workflows angebunden, lohnt die Prüfung sehr.
Der LLM-Pentest prüft Ihre Anwendung gezielt auf Schwachstellen, AI Red Teaming meint oft zusätzlich das Testen auf schädliche oder unerwünschte Modellausgaben. Die Begriffe werden im Markt nicht einheitlich verwendet. Unser Schwerpunkt liegt auf der Sicherheit der Anwendung: Prompt Injection, Datenabfluss, Werkzeugmissbrauch und Berechtigungen. Unsichere Ausgaben bewerten wir mit, soweit sie nachgelagerte Systeme gefährden.
Ja, und dort ist die Prüfung besonders wichtig, weil ein umgelenktes Modell nicht nur antwortet, sondern handelt. Wir prüfen, welche Werkzeuge, Schnittstellen und Rechte ein Agent nutzen kann und ob sich diese über manipulierte Inhalte zweckentfremden lassen. In den OWASP Top 10 for LLM Applications heißt dieses Risiko Excessive Agency. MCP-Server, über die Agenten Werkzeuge ansprechen, prüfen wir mit, bevorzugt mit Einblick in den Quellcode.
Vor allem von der Zahl angebundener Werkzeuge, Datenquellen und Rollen und davon, ob wir Einblick in Systemanweisungen und Architektur erhalten. Ein Chatbot ohne Anbindung ist schneller geprüft als ein Agent, der E-Mails versendet oder Tickets anlegt. Weil Modellantworten variieren, wiederholen wir Angriffe mehrfach, auch das fließt in den Aufwand ein.
Das hängt davon ab, was das LLM darf. Ein einfacher Chatbot auf der Website, der nichts ausführen kann, lohnt kaum. Ist das Modell tiefer in Ihre Webanwendung oder API integriert oder an internes Wissen, Tools und Workflows angebunden, lohnt der Test sehr. Genau dort prüfen wir, ob sich internes Wissen abziehen lässt, ob sich über die angebundenen Werkzeuge Code ausführen lässt, ob ein Ausbruch aus der Sandbox möglich ist und ob sich Workflows für Angriffe missbrauchen lassen.
Ja. MCP-Server verbinden Modelle mit Werkzeugen und Daten und gehören damit zur Angriffsfläche. Wir prüfen sie bevorzugt mit Quellcode, vor allem, wenn sie selbst entwickelt sind: welche Werkzeuge sie bereitstellen, wie sie authentifizieren und was ein manipulierter Aufruf auslösen kann.
