DeepSeek V4 Pro: Die Sicherheit hängt am Agenten-Framework – nicht nur am Modell

Unternehmen, die Agenten mit DeepSeek V4 Pro einsetzen, sollten nicht das Modell isoliert bewerten. Maßgeblich ist die vollständige Konfiguration aus Modell, Harness, Aufgabe und Umgebung.

Dass ein Modell über Web, Mobil-App, API, OpenAI Responses API oder eine Codex-Integration erreichbar ist, zeigt zunächst nur, dass die jeweilige Laufzeit mit dem Modell kommunizieren kann. Daraus folgt nicht, dass Prompts, Tools, Berechtigungen, Speicher, Wiederholungslogik oder Seiteneffekte in allen Umgebungen gleich funktionieren.

Die praktische Regel ist einfach: Freigegeben wird eine konkrete, unveränderlich festgelegte Konfiguration – und zwar erst, nachdem genau diese Konfiguration ihre Sicherheitstests bestanden hat.

Warum das Harness den tatsächlichen Agenten verändert

Ein Agent besteht aus mehr als seinem Sprachmodell. Das Harness – also die Laufzeit- und Orchestrierungsschicht des Agenten – entscheidet unter anderem, wie das Modell Anweisungen erhält, Tools auswählt, auf Daten zugreift, Fehler verarbeitet und externe Systeme beeinflusst.

Wichtige Unterschiede können bestehen bei:

• Systemprompts und Adaptern;
• Definition und Implementierung der Tools;
• Berechtigungsumfängen und Genehmigungsschranken;
• Dateisystempfaden und Netzwerkzugriffen;
• Herkunft von Zugangsdaten und verwendeter Identität;
• Unterprozessen und der Ausführung generierten Codes;
• Wiederholungen, Zeitüberschreitungen und Nebenläufigkeit;
• Sitzungszustand, Zusammenfassungen, Caches und dauerhaftem Speicher.

Deshalb kann derselbe DeepSeek-V4-Pro-Backend je nach Harness und Ausführungsumgebung ein anderes Risikoprofil haben. Ein kompatibles API-Schema ist eine Eigenschaft der Integration – keine Sicherheitszertifizierung.

Was die AgentS4D-Ergebnisse zeigen – und was nicht

AgentS4D bewertete vollständige Laufzeitkonfigurationen statt isolierter Modellantworten. Der Benchmark umfasste 328 Fälle mit absichtlich eingebrachten Risiken, vier Agenten-Harnesses und fünf Modell-Backends. Daraus entstanden 6.560 Ausführungen in einer Sandbox. In 4.461 Fällen wurde ein unsicheres Verhalten festgestellt – das entspricht 68,0 Prozent. 4.344 Läufe, also 66,22 Prozent, waren zugleich unsicher und wurden als abgeschlossen bewertet. 13

Die zentrale Erkenntnis: Ein erfolgreich abgeschlossenes Ergebnis kann mit einer unsicheren Ausführung einhergehen. Ein Agent kann also das gewünschte Artefakt erzeugen und dabei gleichzeitig eine verbotene Änderung vornehmen, sensible Daten falsch behandeln, eine vorgesehene Kontrolle umgehen oder einen anderen gefährlichen Seiteneffekt auslösen.

Diese Zahlen dürfen nicht als Produktionsvorfallrate von DeepSeek V4 Pro dargestellt werden. Getestet wurden gezielt riskante Fälle in einer kontrollierten Sandbox; außerdem wurden mehrere Kombinationen aus Modell und Harness gemeinsam ausgewertet. In der Praxis unterscheiden sich Aufgabenmix, Schutzmaßnahmen, Kontakt mit Angreiferinhalten, betroffene Ressourcen und die Definition eines Schadens. Der Benchmark zeigt, dass Laufzeitsicherheit direkt gemessen werden muss – er sagt nicht voraus, was in jeder Produktionsumgebung passieren wird. 135

Das maximale Schadenspotenzial begrenzen

Sicherheitsmaßnahmen sollten Fehler möglichst folgenarm machen – auch dann, wenn sich das Modell oder ein Tool unerwartet verhält.

Dedizierte Identitäten mit geringsten Rechten verwenden

Für Agenten, Umgebungen und Mandanten sollten getrennte Identitäten angelegt werden. Allgemeine Mitarbeiterkonten, Produktions-Administratorrechte und breit wiederverwendbare Geheimnisse gehören nicht in die Ausführungsumgebung eines Agenten. Jede Identität sollte nur auf die Ressourcen und Vorgänge zugreifen dürfen, die für den jeweiligen Auftrag erforderlich sind.

Datei- und Netzwerkzugriff einschränken

• Nur ein eigens dafür vorgesehenes Arbeitsverzeichnis einbinden.
• Nicht benötigte Pfade tatsächlich unzugänglich machen, statt sie lediglich zu verstecken.
• Netzwerkziele, Methoden, Ports und – falls relevant – das Volumen ausgehender Daten per Allowlist begrenzen.
• Lesezugriff, Entwürfe, Schreiben in eine Testumgebung und Schreiben in die Produktion voneinander trennen.
• Geheimnisse über einen Broker oder ein System für kurzlebige Token bereitstellen.
• Langlebige Zugangsdaten niemals in Prompts, Arbeitsdateien, Umgebungsvariablen oder Tool-Ausgaben ablegen.

Aktionen mit hoher Tragweite – etwa Löschen, Veröffentlichen, Zahlungen, Berechtigungsänderungen, Deployments oder externe Kommunikation – sollten eine Richtlinienprüfung auf der Ausführungsebene durchlaufen oder eine ausdrückliche Freigabe erfordern.

Die gesamte Ausführungskette prüfen

Erstanbieter-Tools sind nur ein Teil der Angriffsfläche. Auch Kindprozesse, Shell-Befehle, generierter Code, Paketinstallationen, entfernte Tool-Server, Plugins und Skill-Code können Seiteneffekte erzeugen.

Für alle diese Wege müssen dieselben Richtlinien gelten. Insbesondere darf die Ausführung von Shell-Befehlen oder generiertem Code keine Kontrollen für Dateisystem, Netzwerk, Autorisierung, Protokollierung oder Freigaben umgehen können.

Tools müssen außerhalb des Modells durchsetzbar sein

Ein vom Modell erzeugter Tool-Aufruf ist zunächst eine nicht vertrauenswürdige Anfrage. Die Autorisierung und Sicherheitsregeln muss der Tool-Server durchsetzen – nicht das Modell.

Sinnvoll sind enge Schemata mit Kontrollen wie:

• begrenzten Aufzählungswerten und Längenlimits;
• normalisierten Pfaden und eindeutigen Ressourcenkennungen;
• Allowlists für Zieladressen;
• Grenzen für Seitennummerierung und Ergebnisgröße;
• einer Argumentprüfung außerhalb des Modells;
• serverseitiger Autorisierung für den konkreten Aufrufer, Mandanten, Zielwert und Vorgang.

Planungs- oder Vorschau-Tools sollten von Tools mit tatsächlicher Wirkung getrennt werden. Für zerstörerische oder nur schwer umkehrbare Vorgänge empfiehlt sich:

• eine Vorschau mit Bestätigung oder Freigabetoken;
• nach Möglichkeit Soft-Delete, Quarantäne oder umkehrbare Abläufe;
• die Pflicht zu Idempotenzschlüsseln;
• eine klare Definition des Verhaltens bei Wiederholungen;
• dauerhafte Belege, damit ein Retry keine Wirkung doppelt auslöst.

Diese Maßnahmen sind nötig, weil ein formal korrektes JSON-Tool-Objekt trotzdem ein nicht autorisiertes Ziel, einen gefährlichen Pfad, einen zu großen Berechtigungsumfang oder einen Vorgang enthalten kann, der eine menschliche Prüfung erfordert.

Zustand und Speicher vor dem Einsatz festlegen

Zustand kann Risiken über mehrere Nachrichten, Aufgaben, Nutzer und Umgebungen hinweg weitertragen. Unternehmen sollten deshalb Lebenszyklusregeln für Nachrichten, hochgeladene Dateien, Arbeitsdateien, Zusammenfassungen, Tool-Ergebnisse, Caches und dauerhaften Speicher dokumentieren und technisch durchsetzen.

Mindestens folgende Punkte müssen festgelegt sein:

• Isolation: Zustand nach Nutzer, Mandant, Aufgabe und Umgebung trennen; kein impliziter Austausch zwischen Sitzungen.
• Aufbewahrung: Fristen, Verschlüsselung, Zugriffskontrollen und Löschregeln definieren.
• Zurücksetzen: Einen dokumentierten Weg bereitstellen, um Kontext, Speicher, Arbeitsverzeichnis, Zugangsdaten und Caches zwischen Läufen zu löschen.
• Wiederholungen und Zeitüberschreitungen: Anzahl und Budget begrenzen; Wiederholungen müssen idempotent bleiben und dürfen Berechtigungen nicht unbemerkt erweitern.
• Nebenläufigkeit: Sperren und Konfliktbehandlung für gemeinsame Dateien, Freigaben und externe Vorgänge definieren.

Das Zurücksetzen des Zustands gehört zur Sicherheitsgrenze. Wenn alte Anweisungen, Zugangsdaten oder Tool-Ergebnisse unerwartet in einer neuen Aufgabe auftauchen können, kann ein Modell-Upgrade oder eine Prompt-Änderung das Risiko verändern – ohne dass Antworttests allein dies sichtbar machen.

Jeden möglichen Risikoträger als nicht vertrauenswürdig behandeln

Prompt-Injection muss nicht in einer direkten Nutzernachricht stehen. Riskante Anweisungen können eingebettet sein in:

• hochgeladene Dokumente und Repository-Dateien;
• abgerufene Webseiten;
• externe Skills und Plugins;
• Antworten von Tool-Diensten;
• dauerhaft gespeicherte Erinnerungen;
• Zusammenfassungen und gecachten Kontext;
• vom Nutzer bereitgestellten Text.

Solche Inhalte sollten geparst, gekennzeichnet und als Daten zitiert werden. Sie dürfen weder die Autorität des Agenten noch Richtlinien, Tool-Auswahl, Nutzung von Zugangsdaten oder Anforderungen an Freigaben verändern. Diese Trennung muss die Laufzeit erzwingen; man sollte sich nicht allein darauf verlassen, dass das Modell bösartige Anweisungen erkennt.

Checkliste für die Freigabe eines konkreten Harnesses

Vor der Freigabe sollte die exakte Konfiguration eingefroren und dokumentiert werden:

1. Modell und Routing: Modellkennung und -version, Provider-Route, Inferenzparameter oder Aufwandsstufe sowie Kompatibilitätsadapter.
2. Verhalten des Harnesses: Harness-Version, Systemprompt, Sitzungslogik, Wiederholungs- und Timeout-Regeln, Unterprozessrichtlinie und Speicherimplementierung.
3. Tools und Richtlinien: Definitionen und Versionen der Tools, Richtlinienversionen, Freigabeschwellen, Autorisierungslogik und Vertrauensgrenzen der Tool-Server.
4. Berechtigungen: Identitäten, Umfänge, Dateisystemwurzeln, Netzwerkziele, Quellen der Zugangsdaten und Wege zum Schreiben in die Produktion.
5. Semantik des Zustands: Isolation, Aufbewahrung, Zurücksetzen, Cache-Verhalten, Nebenläufigkeit und Grenzen zwischen Sitzungen.
6. Angriffstests: Prompt-Injection über jeden Risikoträger, Confused-Deputy-Versuche, Offenlegung von Zugangsdaten, Pfad-Traversal, SSRF oder Missbrauch des ausgehenden Datenverkehrs, bösartige Tool-Antworten, doppelte Wirkung durch Wiederholungen, Memory Poisoning und das Umgehen von Freigaben.
7. Nachweise: Prompts und Richtlinienversionen, Tool-Aufrufe und -Ergebnisse, Freigaben, Richtlinienentscheidungen, Änderungen am Arbeitsverzeichnis, ausgehende Anfragen, verwendete Identität, finale Artefakte sowie Abschluss- und Sicherheitsergebnis unter einer stabilen Lauf-ID.

Abschluss und Sicherheit müssen getrennt bewertet werden. Ein korrektes finales Artefakt darf einen unsicheren Seiteneffekt nicht ausgleichen – genau darin liegt die zentrale Lehre aus den AgentS4D-Ergebnissen. 12

Nach jeder relevanten Änderung erneut testen

Testziel ist die festgelegte Konfiguration, nicht ein dauerhaftes Etikett wie „DeepSeek-V4-Pro-Agent“. Die konfigurationsspezifische Testsuite sollte nach jeder wesentlichen Änderung erneut ausgeführt werden, etwa bei:

• Modell oder Provider-Route;
• Inferenzparametern oder Aufwandsstufe;
• Systemprompt oder Adapter;
• Harness- oder Sitzungslogik;
• Tools oder entfernten Tool-Servern;
• Berechtigungs- und Freigaberichtlinien;
• Weiterleitung von Zugangsdaten;
• Speicher-, Retry-, Timeout- oder Nebenläufigkeitsverhalten;
• Netzwerk- oder Dateisystemgrenzen.

So wird Laufzeitsicherheit von einer pauschalen Annahme über die Modellqualität zu einer messbaren Freigabeentscheidung – gebunden an genau die Umgebung, die reale Auswirkungen erzeugen kann.