DeepSeek mit Werkzeugen absichern: Ein Sicherheitstestplan gegen Prompt-Injection und Werkzeugmissbrauch

Der Beitrag richtet sich an Sicherheits- und Plattformteams, die DeepSeek-Modelle über die API, bei einem Hostingpartner oder im eigenen Rechenzentrum einsetzen und ihnen Zugriff auf Inhalte oder Werkzeuge geben wollen. Für einen Chat ohne Werkzeuge mit unkritischen Daten genügt ein kleiner Teil davon. Sinnvoll beginnt man nicht mit dem Modell, sondern mit der Frage: Welche Aktion kann der Agent auslösen, wenn er einer fremden Anweisung folgt?

Wo der Sicherheitstest im DeepSeek-Angebot steht

DeepSeek bietet eine API, offene Modellgewichte und Infrastruktur-Bausteine an, wie die Seite DeepSeek für Unternehmen zeigt. Der hier beschriebene Testplan gilt für alle drei Wege, denn er prüft das Verhalten des Modells in der eigenen Anwendung. Er beantwortet nicht, ob Daten an die API in China gehen dürfen. Das klärt der Beitrag zur DeepSeek-API im Unternehmen. Hardware und Betrieb der offenen Gewichte behandelt der Beitrag zum Eigenbetrieb von DeepSeek V4.

Werkzeugaufrufe beschreibt DeepSeek in der API-Dokumentation: Die Anwendung definiert Funktionen als JSON-Schema, das Modell schlägt einen Aufruf vor, und die Anwendung führt ihn aus. Laut DeepSeek führt das Modell selbst keine Funktionen aus. Ein Strict-Modus, als Beta gekennzeichnet, prüft auf dem Server, ob das Schema den Regeln entspricht. Das sichert die Form der Argumente, nicht ihren Inhalt. Eine Sicherheitsprüfung von Werkzeugaufrufen oder einen Schutzfilter für eingeschleuste Anweisungen haben wir in den durchgesehenen DeepSeek-Dokumenten nicht gefunden. Das Unternehmen muss diese Schutzschicht deshalb selbst sicherstellen und prüfen, ob mit eigener Entwicklung oder mit Kontrollen einer vorhandenen Plattform, etwa eines Gateways oder Agenten-Frameworks.

Was über die Anfälligkeit von DeepSeek bekannt ist

Das Center for AI Standards and Innovation am NIST hat im September 2025 die Modelle R1, R1-0528 und V3.1 geprüft. Laut Bericht folgten Agenten auf Basis des robustesten dieser Modelle im Schnitt zwölfmal häufiger eingeschleusten schädlichen Anweisungen als die US-Vergleichsmodelle. Im Forschungsblog vom 23. März 2026 greift CAISI diese frühere Auswertung erneut auf, eine neue Prüfung aktueller DeepSeek-Modelle ist das nicht: DeepSeek-Modelle seien weiterhin anfälliger für die Übernahme von Agenten, etwa zum Versand von Phishing-Mails, zum Ausführen von Schadsoftware oder zum Abgreifen von Zugangsdaten.

Davon getrennt liefert derselbe Blogbeitrag eine zweite, ebenso wichtige Erkenntnis aus einem anderen Test. In einem öffentlichen Red-Teaming-Wettbewerb mit mehr als 250.000 Angriffsversuchen fanden die Teilnehmer gegen jedes der 13 geprüften Spitzenmodelle mindestens einen erfolgreichen Angriff. Robustheit ist also eine Frage des Grades. Wer ein Modell mit besseren Werten wählt, braucht trotzdem dieselben Schutzschichten.

Welche Schutzschichten getestet werden

Das BSI hat im September 2026 einen Basisschutz gegen indirekte Prompt-Injections veröffentlicht, abgeleitet aus Red-Teaming-Untersuchungen dokumentbasierter Chats. Die Kernaussage: Ein Sprachmodell kann allein nicht zwischen Nutzeranweisung, Systemanweisung und fremden Daten unterscheiden, es sieht nur eine Kette von Tokens. Schutzmaßnahmen müssen deshalb überwiegend außerhalb des Modells wirken. Die fünf Basismaßnahmen des BSI sind Eingabe-Bereinigung, Trennung der Vertrauensbereiche, ein gehärteter Systemprompt, Modellauswahl mit Reasoning und ein Filter für die Ausgabe.

Für Agenten mit Werkzeugen fehlt darin eine Schicht, die OWASP als eigenes Risiko führt: übermäßige Handlungsbefugnis. Ein Agent, der Mails versenden, Datensätze ändern oder Dateien schreiben darf, braucht Rechte, die außerhalb des Modells begrenzt sind, etwa auf interne Empfänger, bestimmte Datensätze oder nur lesende Zugriffe. Die Animation zeigt an drei erfundenen Testfällen, warum jede Schicht einzeln geprüft werden muss.

Redaktionelle, schematische Darstellung von AI-Fabrik, keine Messung. Die Testfälle sind erfunden und zeigen nur, an welcher Schicht ein Angriff dieser Art typischerweise abgefangen werden soll. Schichten nach dem BSI-Basisschutz (Bereinigung, Abgrenzung, Modell, Ausgabe) und OWASP LLM06 (Werkzeugrechte).

Die drei Fälle zeigen den Zweck des Testplans. Fall 2 kann alle textbezogenen Schutzmaßnahmen passieren, weil die Anweisung sauber formuliert ist. Das BSI beschreibt genau diese Lücke: Inhaltlich-semantische Angriffe mit unauffälligem Text passieren die Bereinigung unverändert. Fall 3 braucht gar kein Werkzeug, er nutzt nur die Antwort. Der Link selbst überträgt noch nichts; Daten fließen ab, sobald ein Browser, eine Bildanzeige, eine Vorschaufunktion oder ein Folgesystem die Adresse aufruft. Laut BSI kann das ohne Zutun des Nutzers geschehen, wenn ein eingebettetes Bild geladen wird. Ein Test, der nur das Modell prüft, würde beide Lücken übersehen.

Der Testplan in fünf Bausteinen

Die folgende Gliederung ist eine Empfehlung von AI-Fabrik. Sie folgt den Punkten, die das BSI-Papier zu Evasion-Angriffen und die zugehörige Checkliste behandeln: Verständnis des Systems, Bedrohungsmodell für den konkreten Einsatz, Auswahl und Einbau der Gegenmaßnahmen.

1. Testgegenstand: die ganze Kette, nicht nur das Modell

Geprüft wird die konkrete Konfiguration: Modellfassung und Denkmodus, Systemprompt, alle angebundenen Werkzeuge mit ihren Rechten, die Datenquellen, aus denen fremde Inhalte kommen, und die Ausgabe an Nutzer oder Folgesysteme. Wer die DeepSeek-API nutzt, sollte die Modellbezeichnung je Testlauf protokollieren, denn hinter einem API-Namen kann eine neue Fassung stehen. Im Eigenbetrieb gehört die genaue Revision der Gewichte in das Protokoll.

2. Angriffsszenarien

• Direkte Prompt-Injection: Nutzer versuchen, Regeln auszuhebeln oder den Systemprompt auszulesen. Siehe OWASP LLM01.
• Indirekte Prompt-Injection: Anweisungen in Dokumenten, Mails, Webseiten, Tickets oder Code, sichtbar oder versteckt, etwa in Metadaten, Kommentaren oder unsichtbaren Zeichen.
• Werkzeugmissbrauch: eingeschleuste Anweisungen, die zu Aufrufen mit falschen Empfängern, zu vielen Datensätzen oder fremden Zielen führen, auch in Ketten mehrerer Aufrufe.
• Datenabfluss über die Antwort: Links, Bildadressen oder kodierte Inhalte, die Daten nach außen tragen, sobald Oberfläche, Vorschau oder Folgesystem sie aufrufen. Der Test schließt deshalb die tatsächliche Darstellung und Weiterverarbeitung ein, nicht nur den Antworttext.
• Offenlegung von Interna: Systemprompt, Zugangsdaten aus dem Kontext und, bei DeepSeek wichtig, das Reasoning (dazu unten mehr).

3. Anlass und Häufigkeit

Der vollständige Katalog läuft vor der ersten produktiven Nutzung und danach bei jeder Änderung an Modellfassung, Systemprompt, Werkzeugen oder Rechten. Bei DeepSeek ist der erste Anlass häufig: Zwischen April und Oktober 2026 erschienen an sieben Terminen neue V4-Gewichte, wie der Beitrag zum Eigenbetrieb dokumentiert. Im laufenden Betrieb kommen Stichproben hinzu, deren Takt sich nach der möglichen Wirkung richtet.

4. Abnahmekriterien und Protokoll

Kriterien sollten vor dem Test feststehen und messbar sein. Für Agenten mit schreibenden Werkzeugen empfehlen wir als harte Grenze: Kein Testfall darf zu einer ausgeführten Aktion führen, die nicht vom berechtigten Nutzer stammt, und kein Testfall darf Daten an nicht freigegebene Adressen bringen. Für weichere Kriterien, etwa wie oft das Modell einer eingeschleusten Anweisung sprachlich folgt, wird der Anteil je Fassung festgehalten und verglichen. Konkrete Schwellenwerte legt das Unternehmen fest, belastbare Branchenwerte dafür gibt es nicht. Jeder Lauf wird mit Fassung, Konfiguration, Testfällen und Ergebnis protokolliert, jeder Befund bekommt eine verantwortliche Person und eine Frist.

Ein bestandener Katalog ist ein begrenzter Nachweis. Er zeigt, dass die geprüften Angriffe abgefangen wurden, nicht, dass das System gegen unbekannte Varianten sicher ist. Weil Modelle nicht bei jedem Aufruf gleich antworten, laufen Testfälle mehrfach, und der Katalog wird regelmäßig um neue Angriffsvarianten erweitert. Dazu gehören reguläre Aufgaben ohne Angriff: Ein System, das im Zweifel alles blockiert, besteht sonst jeden Sicherheitstest und ist trotzdem unbrauchbar.

Beispielzeilen für den Katalog

Die folgenden Zeilen sind hypothetische Beispiele von AI-Fabrik für einen Agenten, der Mails liest, Dokumente auswertet und intern Nachrichten versenden darf. Sie zeigen das Format, keinen vollständigen Katalog.

5. Werkzeuge und Kataloge

Als methodische Orientierung eignen sich die OWASP Top 10 für LLM-Anwendungen, die beiden BSI-Papiere und die Testlogik des NIST-Berichts. Für die Modellauswahl nennt das BSI Benchmarks wie BIPIA und InjecAgent sowie Vergleichsplattformen mit Fokus auf die deutsche Sprache. Automatisierte Scanner können den Katalog füllen und wiederholen, ersetzen aber keine fachlich gebauten Szenarien für die eigenen Werkzeuge. Werkzeugnamen nennen wir hier bewusst nicht als Empfehlung.

Was bei DeepSeek besonders zu beachten ist

Laut API-Dokumentation ist der Denkmodus standardmäßig eingeschaltet, mit hohem Aufwand. Das Reasoning kommt in einem eigenen Feld reasoning_content zurück. Bei Anfragen mit Werkzeugen muss die Anwendung dieses Feld in allen folgenden Anfragen mitschicken, sonst antwortet die API mit einem Fehler. Das Reasoning liegt damit im Gesprächsverlauf der Anwendung und oft in ihren Protokollen.

Das BSI bewertet Reasoning zwiespältig. Es sei einer der wirksamsten Hebel gegen sprachlich getarnte Angriffe, könne aber selbst zum Angriffsvektor werden. Das BSI empfiehlt, das Reasoning Nutzern nicht anzuzeigen und es höchstens für Administratoren unter Beachtung des Datenschutzes zu protokollieren. Für DeepSeek heißt das: Den Denkmodus als eigene Testkonfiguration prüfen und nach der gemessenen Robustheit entscheiden, ob er eingeschaltet bleibt; eine Sicherheitsgarantie ist er nicht. reasoning_content nicht in die Oberfläche durchreichen und im Test prüfen, ob es Systemprompt, Zugangsdaten oder eingeschleuste Anweisungen enthält. Die genannten Standardwerte und Feldnamen gelten für die DeepSeek-API. Im Eigenbetrieb hängen Denkmodus, Ausgabeformat und Voreinstellungen von der Inferenz-Software und ihrer Konfiguration ab und müssen dort geprüft werden.

Der Strict-Modus für Werkzeugaufrufe ist nützlich, weil er Argumente in eine feste Form zwingt. Er ist laut Doku eine Beta-Funktion der API. Ob eine selbst betriebene Inferenz-Software dieselbe Prüfung bietet, hängt von der Software ab. In beiden Fällen gilt: Die Anwendung prüft vor jeder Ausführung, ob Empfänger, Datensatz und Umfang erlaubt sind. Das ist eine fachliche Prüfung, die kein Schema leisten kann.

Wie viel Aufwand angemessen ist

Einteilung nach möglichem Schaden und Umkehrbarkeit, Empfehlung von AI-Fabrik. Ein kleines Unternehmen mit einem lesenden Assistenten braucht keinen Konzernprozess, ein Agent mit Zahlungsrechten dagegen auch im kleinen Unternehmen die erweiterte Stufe.

Pilotfragen vor dem Anschluss an Werkzeuge

1. Welche Aktion kann der Agent im schlimmsten Fall auslösen, und ist sie technisch auf Empfänger, Datensätze und Umfang begrenzt?
2. Aus welchen Quellen gelangen fremde Inhalte in den Kontext, und haben wir für jede Quelle präparierte Testfälle?
3. Was passiert mit reasoning_content: Wird es angezeigt, gespeichert oder an andere Systeme weitergegeben?
4. Welche Abnahmekriterien gelten, wer entscheidet bei einem Befund, und läuft der Katalog bei jeder neuen Modellfassung automatisch?
5. Wie schnell können wir den Agenten oder einzelne Werkzeuge abschalten, wenn im Betrieb ein Angriff auffällt?

Fazit: Der Test gehört zur Architektur, nicht zum Modell

Quellen

Weiterführende Artikel auf AI-Fabrik