KI-Sicherheit — Absicherung von LLM-Systemen
LLM-Anwendungen bringen Angriffsflächen mit, die klassische Sicherheitstests nicht abdecken. Wir prüfen Ihre KI-Anwendung aus der Angreiferperspektive, weisen konkrete Schwachstellen nach und setzen die Schutzschicht davor — bis hin zum gehärteten Betrieb der Modelle.
Angriffsflächen, die klassische Tests nicht abdecken
Ein Penetrationstest gegen die Webanwendung sagt nichts darüber aus, ob das Sprachmodell dahinter Anweisungen aus einem hochgeladenen Dokument befolgt. LLM-Systeme führen Sprache aus — und Sprache kommt aus Quellen, denen niemand Rechte zugewiesen hat.
Prompt Injection über Eingaben
Anweisungen im Benutzertext überschreiben die Vorgaben der Anwendung. Das Modell unterscheidet nicht von sich aus zwischen Ihrer Systemanweisung und dem, was ein Nutzer hineinschreibt — die Trennung muss die Anwendung herstellen.
Indirekte Injection über verarbeitete Inhalte
Der gefährlichere Fall: Die Anweisung steht nicht in der Eingabe, sondern in einem Dokument, einer E-Mail oder einer Webseite, die das System verarbeitet. Wer Fremdmaterial durch ein LLM schickt, führt fremde Anweisungen aus.
Jailbreaks und Regelumgehung
Rollenspiele, Kodierungen, Sprachwechsel und schrittweise Umformulierung hebeln Vorgaben aus, die im Systemprompt sauber formuliert sind. Ein Prompt allein ist keine Sicherheitsgrenze.
Datenabfluss über Modellantworten
Systemanweisungen, Inhalte aus dem Wissensspeicher oder Daten anderer Nutzer landen in einer Antwort, die sie nie hätte enthalten dürfen. Bei angebundenen Dokumentenbeständen ist das die häufigste stille Schwachstelle.
Unsichere Werkzeug- und Funktionsaufrufe
Sobald ein Modell Funktionen aufruft, wird aus einem Textproblem ein Systemproblem: unvalidierte Parameter, zu weit gefasste Aufrufe und Aktionen, die niemand zwischenzeitlich freigibt.
Überzogene Berechtigungen von Agenten
Agenten bekommen im Aufbau oft mehr Rechte, als der Anwendungsfall braucht — vollen Datenbankzugriff statt einer Abfrage, Schreibrechte statt Lesen. Was der Agent darf, darf im Ernstfall auch der Angreifer.
Orientierung an der OWASP-Top-10 für LLM-Anwendungen
Für die Risiken von LLM-Anwendungen hat sich die OWASP-Top-10 für LLM-Anwendungen als anerkannter Bezugsrahmen etabliert. Wir nutzen sie als Struktur für die Analyse, damit nichts Wesentliches durchrutscht — nicht als Zertifizierung: Ein Siegel gibt es dort nicht, und wir behaupten keines. Was zählt, ist der Nachweis am konkreten System.
- Angriffsflächen strukturiert entlang eines anerkannten Rahmens erfasst
- Geprüft wird die ganze Kette: Eingabe, Modell, Wissensspeicher, Werkzeuge, Ausgabe
- Nachweis konkreter Schwachstellen statt Abhaken einer Liste
- Priorisierte Maßnahmen mit realistischer Aufwandseinschätzung
Nachweis statt Siegel
Sie erhalten belegte Befunde an Ihrem eigenen System — kein Zertifikat und keine bestandene Checkliste.
Lieferkette im Blick
Modelle, Gewichte, Bibliotheken und Erweiterungen bringen Risiken aus fremder Hand mit. Herkunft und Abhängigkeiten gehören in die Prüfung.
Eingabe bis Ausgabe
Geprüft wird die vollständige Kette: Eingabe, Wissensspeicher, Modell, Werkzeugaufrufe und ausgelieferte Antwort.
Wiederholbar prüfbar
Die Testfälle bleiben erhalten. Nach Änderungen an Prompt, Modell oder Werkzeugen lässt sich derselbe Stand erneut prüfen.
Von der Prüfung bis zum gehärteten Betrieb
Die Leistungen lassen sich einzeln beauftragen oder aufeinander aufbauen — von der einmaligen Sicherheitsprüfung bis zur laufend betreuten Schutzschicht vor Ihren KI-Anwendungen.
Sicherheitsprüfung bestehender KI-Anwendungen
Strukturierte Analyse der Angriffsflächen Ihrer bestehenden Anwendung — mit dem Nachweis konkreter Schwachstellen an Ihrem System, nicht mit einer allgemeinen Risikoliste. Ergebnis ist ein Bericht, mit dem Ihre Entwicklung arbeiten kann.
Schutzschicht vor dem Modell
Eine vorgelagerte Schicht prüft Eingaben, filtert Ausgaben, erkennt Injection-Versuche in verarbeiteten Dokumenten und schiebt kritische Werkzeugaufrufe in einen Freigabe-Workflow. Kontrolle liegt damit außerhalb des Modells.
Absicherung der Agenten-Ebene
Agenten erhalten die minimal nötigen Rechte, jede Aktion wird protokolliert, und jeder Schritt bleibt im Nachhinein nachvollziehbar. Damit ist im Zweifelsfall belegbar, was das System getan hat — und was nicht.
Datenschutz-Schutzschicht
Personenbezogene Daten werden vor der Verarbeitung erkannt und maskiert. So gelangen Namen, Anschriften, Vertrags- und Gesundheitsdaten gar nicht erst in Verarbeitungswege, in denen sie nichts zu suchen haben.
Betrieb und Härtung der Infrastruktur
Netzwerktrennung, Zugriffskontrolle und eine Betriebsumgebung ohne ausgehende Verbindungen: Die Modell-Infrastruktur wird so aufgesetzt, dass ein Datenabfluss technisch nicht vorgesehen ist.
Schulung und Übergabe
Ihr Team lernt, wie die Angriffe funktionieren, worauf bei eigenen Erweiterungen zu achten ist und wie die Schutzschicht gepflegt wird. Ziel ist ein System, das Sie ohne uns weiterbetreiben können.
Kontrolle gehört vor das Modell, nicht hinein
Regeln im Systemprompt lassen sich mit Sprache umgehen. Wirksam wird eine Grenze erst, wenn sie außerhalb des Modells liegt — in einer Schicht, die Eingaben, Werkzeugaufrufe und Ausgaben unabhängig prüft.
Eingangsprüfung
Eingaben werden vor dem Modell auf bekannte Muster, Kodierungstricks und untypische Anweisungsformen untersucht — und je nach Bewertung blockiert, entschärft oder markiert.
Injection-Erkennung in Inhalten
Dokumente, Mails und Webinhalte werden vor der Verarbeitung auf eingebettete Anweisungen geprüft. Fremdmaterial wird als Daten behandelt, nicht als Befehl.
Ausgabefilterung
Antworten werden vor der Auslieferung auf Systemanweisungen, personenbezogene Daten und Inhalte geprüft, die der anfragende Nutzer nicht sehen darf.
Freigabe für kritische Aktionen
Aufrufe mit Wirkung — Schreiben, Löschen, Versenden, Bezahlen — laufen über eine definierte Freigabe. Der Mensch bleibt an der Stelle im Ablauf, an der es darauf ankommt.
Rechte- und Rollenmodell
Jedes Werkzeug bekommt eigene, eng gefasste Rechte statt eines gemeinsamen Vollzugriffs. Die Wirkung einer erfolgreichen Injection bleibt damit begrenzt.
Protokollierung & Nachvollziehbarkeit
Eingaben, Werkzeugaufrufe, Freigaben und Ausgaben werden protokolliert. Auffälligkeiten sind auswertbar, und Vorfälle lassen sich rekonstruieren statt vermuten.
Offensive Sicherheitsarbeit trifft eigenen Modellbetrieb
KI-Sicherheit sitzt zwischen zwei Disziplinen. Wer nur angreift, kennt den Betrieb nicht; wer nur betreibt, kennt die Angriffe nicht. Wir arbeiten auf beiden Seiten — und prüfen Systeme, die wir in gleicher Form selbst bauen.
Praxis aus offensiver Sicherheitsarbeit
Wir prüfen Systeme aus der Angreiferperspektive. Diese Arbeitsweise bringen wir in die Bewertung von KI-Anwendungen ein — es geht um belegte Angriffswege, nicht um theoretische Risikokategorien.
Veröffentlichte Schwachstellen
Aus unserer Sicherheitsarbeit sind gemeldete und veröffentlichte Schwachstellen hervorgegangen, die als CVE geführt werden. Die Prüfmethodik dahinter ist dieselbe, mit der wir KI-Anwendungen untersuchen.
Eigener Betrieb von Sprachmodellen
Wir betreiben Sprachmodelle selbst — Auswahl, Anpassung, Bereitstellung und Anbindung an Fachsysteme. Wir bewerten also keine Technik, die wir nur aus Dokumentationen kennen.
Wir kennen beide Seiten
Angriffswissen ohne Betriebswissen führt zu Berichten, die niemand umsetzen kann. Betriebswissen ohne Angriffswissen führt zu Systemen, die erst im Ernstfall auffallen. Wir bringen beides zusammen.
Nachweis statt Vermutung
Eine Schwachstelle gilt bei uns erst als Befund, wenn sie an Ihrem System reproduzierbar gezeigt werden kann. Das erspart Ihrer Entwicklung Diskussionen über hypothetische Risiken.
Umsetzung statt reiner Beratung
Wir liefern nicht nur den Bericht. Die Schutzschicht, die Rechtetrennung und die Protokollierung bauen wir auf Wunsch mit — und prüfen anschließend erneut.
Vom Erstgespräch zur belegten Nachprüfung
Umfang und Tiefe legen wir gemeinsam mit Ihrer IT-Sicherheit fest. Jeder Schritt endet mit einem Ergebnis, mit dem Sie weiterarbeiten können — auch wenn Sie die Umsetzung intern übernehmen.
Erstgespräch
Wir klären, welche KI-Anwendungen im Einsatz oder im Aufbau sind, welche Daten sie berühren und welche Vorgaben aus IT-Sicherheit und Datenschutz gelten.
Bestandsaufnahme
Architektur, Datenflüsse, Modelle, Wissensspeicher, Werkzeuge und Berechtigungen werden aufgenommen. Daraus entsteht das Bild der tatsächlichen Angriffsfläche.
Prüfung
Die Anwendung wird gezielt angegriffen: direkte und indirekte Injection, Jailbreaks, Abfluss über Antworten, Missbrauch von Werkzeugaufrufen und Agentenrechten.
Bericht mit Priorisierung
Sie erhalten die Befunde mit Nachweis, Einordnung der Schwere und priorisierten Maßnahmen — technisch konkret genug, dass Ihre Entwicklung direkt damit arbeiten kann.
Umsetzung der Schutzschicht
Auf Wunsch setzen wir die Maßnahmen um: Eingangs- und Ausgabeprüfung, Injection-Erkennung, Freigabe-Workflows, Rechtetrennung und Protokollierung.
Nachprüfung
Nach der Umsetzung wird mit denselben Testfällen erneut geprüft. So ist belegt, dass die Befunde geschlossen sind — und nicht nur als erledigt vermerkt wurden.
Leistungsumfang
Prüfung, Schutzschicht und Betrieb — einzeln oder als aufeinander aufbauendes Vorgehen.
- Strukturierte Analyse der Angriffsflächen Ihrer KI-Anwendung
- Nachweis konkreter Schwachstellen an Ihrem eigenen System
- Bericht mit priorisierten Maßnahmen für Ihre Entwicklung
- Schutzschicht mit Eingangsprüfung und Ausgabefilterung
- Erkennung von Injection-Versuchen in verarbeiteten Dokumenten
- Freigabe-Workflows für kritische Werkzeugaufrufe
- Rechtetrennung und Protokollierung auf Agenten-Ebene
- Erkennung und Maskierung personenbezogener Daten
- Härtung der Modell-Infrastruktur und Netzwerktrennung
- Schulung, Übergabe und Nachprüfung
Lassen Sie Ihre KI-Anwendung prüfen
Wir sehen uns an, welche KI-Systeme bei Ihnen im Einsatz oder im Aufbau sind, wo die Angriffsfläche tatsächlich liegt und welche Schutzschicht dafür angemessen ist.