Die Angriffsfläche hat sich verschoben
Solange KI nur Texte vorschlägt, ist ein Fehler ärgerlich. Sobald sie Werkzeuge bedient, Mails verschickt, Datensätze ändert oder Zahlungen auslöst, wird aus einem Fehler eine Handlung. Und Handlungen lassen sich auslösen, ohne dass jemand einbricht: Es reicht, dem Modell eine Anweisung unterzuschieben, an einer Stelle, an der es Text liest.
Dieser Weg heißt Prompt-Injection, und er ist deshalb so unangenehm, weil er wie normale Nutzung aussieht. Ein Bewerbungs-PDF, eine Support-Mail, eine indexierte Webseite. Alles legitim, alles erwartet, und mittendrin ein Satz, der an das Modell gerichtet ist.
Was wir prüfen
Wir sehen uns die Kette an, nicht nur ihr Ende. Wo kommen Inhalte her, werden sie vor dem Modell geprüft, was darf das Modell danach tun, und was wird davon protokolliert. Vier Befundklassen tauchen dabei immer wieder auf.
Erstens Injection über Inhalte. Zweitens Datenabfluss, also Systemprompt, Fremddaten oder interne Hinweise, die im Output landen. Drittens Werkzeugrechte, die weiter sind als der eigentliche Zweck. Und viertens die Lieferkette: Modelle, Plugins und Erweiterungen, deren Herkunft niemand geprüft hat.
Dazu kommt das übliche Handwerk. Netz, Dienste, Authentifizierung, Rechte, Konfiguration. KI- Werkzeuge nutzen wir dabei dort, wo sie Zeit sparen, etwa beim Sichten großer Ausgaben. Die Bewertung macht ein Mensch.
Die Grenze, die wir nicht verschieben
Wir testen ausschließlich Systeme, für die uns eine schriftliche Beauftragung samt Scope vorliegt. Das ist keine Formalie, sondern die Linie zwischen Sicherheitsarbeit und Straftat. Fertige Angriffsketten geben wir nicht heraus und veröffentlichen sie auch nicht, weder im Bericht noch sonst wo. Was ihr bekommt, ist der Weg zur Reproduktion in eurer Umgebung und die Gegenmaßnahme.
Was danach passiert
Ein Bericht, den niemand abarbeitet, hat den Aufwand nicht wert gewesen. Deshalb gehört bei uns der Nachtest dazu: Nach dem Fix prüfen wir dieselben Punkte erneut und schreiben auf, was jetzt hält. Wenn ein Befund aus Gründen offen bleibt, notieren wir das mit Begründung, statt ihn stillschweigend verschwinden zu lassen.
Häufigster Befund bei handelnden Agenten ist übrigens kein Angriff, sondern eine Lücke: Es gibt kein belastbares Protokoll darüber, was der Agent entschieden hat. Für die Sicherheit ist das schlecht, für die Nachweispflichten des EU AI Act ebenfalls. Beides lässt sich mit derselben Maßnahme schließen, und genau dafür haben wir AgentGuard gebaut.
Wann ihr uns dafür nicht braucht
Ein Termin, der beiden Seiten nichts bringt, ist teurer als eine ehrliche Zeile hier.
- —Systeme ohne schriftliche Beauftragung und ohne abgestimmten Scope. Ohne Auftrag kein Test, ausnahmslos.
- —Fremde Systeme, über die ihr nicht verfügen dürft. Auch nicht auf Zuruf und auch nicht kurz.
- —Angriffswerkzeuge oder fertige Exploit-Ketten zum Mitnehmen. Wir liefern Befunde und Gegenmaßnahmen, keine Waffen.
- —Ein Zertifikat als Ziel. Wir liefern eine Prüfung, kein Siegel.
Häufige Fragen
Was unterscheidet ein KI-Pipeline-Audit von einem normalen Pentest?
Ein klassischer Pentest fragt, ob jemand ins System kommt. Ein KI-Audit fragt, ob jemand das System dazu bringt, etwas zu tun, das es nicht soll — ohne einzubrechen. Der häufigste Weg dorthin ist Text: eine Anweisung, die in einem Dokument, einer E-Mail oder einer Webseite steht und vom Modell als Befehl gelesen wird. Eine Anwendung kann netzseitig völlig sauber sein und trotzdem über ein hochgeladenes PDF steuerbar.
Braucht ihr Zugriff auf unsere Produktivsysteme?
Bevorzugt nicht. Wir arbeiten am liebsten gegen eine Staging-Umgebung mit realistischen Daten und schriftlich abgestimmtem Scope. Wo nur Produktion existiert, legen wir vorher Zeitfenster, Testkonten, Abbruchkriterien und Ansprechpartner fest. Nichts davon passiert auf Zuruf, und alles steht im Auftrag.
Was steht am Ende im Bericht?
Je Befund der Weg zur Reproduktion, eine Einschätzung der Tragweite in eurem Kontext und ein Vorschlag zur Behebung, der zu eurem Stack passt. Dazu eine Einordnung, was davon wirklich dringend ist. Nach dem Fix testen wir dieselben Punkte erneut, sonst bleibt der Bericht ein Papier. Funktionierende Angriffsketten veröffentlichen wir nicht, auch nicht im Bericht.
Wie oft sollte man das machen?
Bei KI-Anwendungen häufiger als bei klassischer Software, weil sich die Angriffsfläche mit jedem neuen Werkzeug, jeder neuen Datenquelle und jedem Modellwechsel ändert. Ein sinnvoller Rhythmus ist eine Prüfung vor dem Produktivgang, danach bei wesentlichen Änderungen, mindestens aber jährlich.
Hilft eine Prüfung bei EU-AI-Act-Pflichten?
Sie ersetzt keine Konformitätsbewertung, liefert aber Belege für das, was der AI Act an Risikomanagement und Robustheit erwartet, und sie deckt Nachweislücken auf. Wenn Agenten folgenreiche Aktionen ausführen, fällt fast immer auf, dass Entscheidungen nicht protokolliert werden. Das ist weniger ein Sicherheits- als ein Nachweisproblem, gehört aber in denselben Bericht.
Passt dazu
Konkreter Fall statt Katalog
Erzählt uns in 30 Minuten, was bei euch anfällt. Wir sagen danach klar, ob sich das in diesem Feld lösen lässt und was es ungefähr kostet. Wenn es nicht passt, sagen wir auch das.
Erstgespräch buchen