Was tun nach der DeepSeek-Harness-Prompt-Injection-Studie 2026?

Symptom: Ihr DeepSeek-Harness-Agent liest Webseiten, Dateien, Skills oder MCP-Inhalte und darf danach Befehle, Dateiänderungen oder externe Übermittlungen ausführen.
Schnellste Lösung: Sperren Sie sofort automatische Übergänge von nicht vertrauenswürdigen Inhalten zu sensiblen Tools, führen Sie eine unabhängige Freigabe ein und wiederholen Sie die Tests auf Ihrer eigenen Version. Die Studie rechtfertigt diese Einschränkung, aber ihre Erfolgsquoten dürfen nicht pauschal auf jede DeepSeek-Harness-Bereitstellung übertragen werden.

Für wen dieser Leitfaden gedacht ist:
Für Agentenentwickler, deren Harness Webseiten, Dokumente, Logs oder Code-Kommentare verarbeitet.
Für Sicherheitsteams, die aus einer Forschungsarbeit konkrete Quellen-zu-Operation-Regeln ableiten müssen.
Für technische Verantwortliche, die zwischen weiterem Pilotbetrieb, Funktionsbegrenzung und einer Pause für Hochrisikoaufgaben entscheiden.

Zuletzt aktualisiert am 19.08.2026; Daten abgeglichen mit der arXiv-Fassung vom 17.08.2026, dem untersuchten DeepSeek-Harness-Commit vom 13.08.2026, dem offiziellen Release v0.1.0-rc.7 und dem öffentlichen AI-Infra-Guard-Repositorium. (arXiv-Fassung der Studie)

Studienrahmen statt pauschaler Sicherheitsbewertung

Die DeepSeek-Harness-Prompt-Injection-Studie untersucht keine abstrakte Modellreaktion in einem Chatfenster. Bewertet wurde ein konkreter DeepSeek-Harness-Quellstand, nämlich der Commit 47f943859bef vom 13.08.2026. Zum Versuchsaufbau gehörten ein bestimmtes Modell-Backend, eine definierte Agentenpersönlichkeit, eine Basiskonfiguration ohne aktivierte Prompt-Hardening-Transformation und der originale TypeScript-Laufzeitpfad. Das ist für Ihre Risikobewertung entscheidend: Ein Versionswechsel, ein anderes Modell, andere Tool-Beschreibungen oder eine zusätzliche Freigabelogik können das Ergebnis verändern. (Methodik und Versuchsaufbau der Studie)

Die Arbeit beschreibt 14.560 kontrollierte Ausführungen. Darin enthalten waren 16 indirekte Inhaltskanäle, Text- und Dateiträger, 35 Angriffsziele, eine unveränderte Baseline und 12 veränderte Angriffsmethoden zusätzlich zur naiven Baseline. Die Quellen umfassten unter anderem Webseiten, Dokumente, E-Mail-Daten, Code-Kommentare, Skills, strukturierte Daten und versteckte Unicode-Zeichen. (Datengrundlage und Angriffskanäle)

Beweist die Studie, dass DeepSeek Harness grundsätzlich unsicher ist? Nein, diese Schlussfolgerung wäre zu weit. Die Arbeit zeigt, dass bestimmte Quellen-zu-Sink-Pfade unter einer klar beschriebenen Konfiguration missbrauchbar beeinflusst werden können. Sie zeigt nicht, dass jede Installation dieselbe Quote erreicht oder dass jede erkannte Beeinflussung eine reale Außenwirkung erzeugt.

Das Studienverfahren zeichnete Tool-Aufrufe und Argumente in lokalen Fixtures auf. Ein aufgezeichneter Sink-Aufruf bedeutet deshalb einen versuchten sensiblen Vorgang, nicht den tatsächlichen Versand einer Nachricht, die Ausführung eines Shell-Befehls oder eine Finanztransaktion. Die Autoren markieren die Prozentwerte ausdrücklich als deskriptive Ergebnisse der kontrollierten Konfiguration.

Veröffentlichungstag: Version und Messgrenze

Am Veröffentlichungstag sollten Sie nicht zuerst die höchste Prozentzahl in eine Präsentation übernehmen. Legen Sie zunächst eine Beweiskette an:

1. Speichern Sie die konkrete arXiv-Fassung und das Einreichungsdatum 17.08.2026.
2. Notieren Sie den untersuchten Commit 47f943859bef und das Datum 13.08.2026.
3. Prüfen Sie, welches Modell-Backend, welche Persona und welche Baseline verwendet wurden.
4. Lesen Sie im Reproduktionscode nach, wie Quellen, Taint und simulierte Sinks verbunden werden.
5. Vergleichen Sie Ihre aktive DeepSeek-Harness-Version mit dem Forschungsstand.
6. Kennzeichnen Sie jede Abweichung als „nicht durch die Studie abgedeckt“.

Die Versionsprüfung ist am 19.08.2026 besonders wichtig. v0.1.0-rc.7 wurde am 17.08.2026 veröffentlicht. Die Release Notes nennen unter anderem Plugin-eigene Einstellungskarten, die Verwaltung von Subagent-Aufgaben im Job Panel, dauerhafte Bildanhänge für MCP und ACP sowie Fehlerkorrekturen im Bash-, Sitzungsverlauf- und PTY-Verhalten. Daraus folgt nicht automatisch eine Sicherheitsbehebung. Es muss separat geprüft werden, ob sich dadurch der untersuchte Kontextaufbau, die Tool-Aufrufkette oder die Berechtigungsgrenzen verändert haben. (offizielle Release Notes zu v0.1.0-rc.7)

Die Forschung verwendete zwei Auswerter. Der regelbasierte Prüfer bewertete 819 von 14.560 Läufen als vollständigen Erfolg, also 5,6 %. Der semantische LLM-Prüfer kam auf 772 vollständige Erfolge beziehungsweise 5,3 %. Bei teilweiser Beeinflussung lag der Unterschied deutlich höher: 2,0 % beim regelbasierten und 7,3 % beim semantischen Prüfer. (Erfolgsdefinitionen und Auswertervergleich)

Diese Abweichung ist kein nebensächliches Detail. Ein Tool-Aufruf kann stattfinden, ohne dass alle erwarteten Argumente korrekt sind. Ebenso kann ein Modell seine Planung sichtbar ändern, ohne die vollständige Angriffsaufgabe auszuführen. Für Ihr internes Reporting sollten Sie daher mindestens „vollständig“, „teilweise beeinflusst“ und „nicht erreicht“ getrennt führen.

Erster Tag: Hochrisiko-Pfade einfrieren

Die erste operative Entscheidung lautet nicht „DeepSeek Harness abschalten“, sondern „welche Übergänge dürfen bis zur lokalen Prüfung nicht mehr automatisch erfolgen?“.

Erstellen Sie eine Matrix aus Quelle und Zieloperation:

Die Studie beschreibt genau den problematischen Übergang: Ein Tool-Ergebnis kann als zusätzlicher Kontext in die Sitzung gelangen; danach kann das Modell ein weiteres Tool auswählen. Gleichzeitig stellt DeepSeek Harness laut der Quellcodeanalyse Tool-Guard- und Pre-Execution-Erweiterungspunkte bereit. Der Guard kann einen Aufruf mit einer Begründung ablehnen, und eine spätere Listener-Logik soll eine solche Ablehnung nicht wieder in eine Erlaubnis umwandeln. (Architektur der Tool-Ausführung)

Ihre temporäre Regel sollte deshalb lauten:

• Lesen aus externen Quellen bleibt möglich.
• Schreiben, Ausführen, Versenden und Übermitteln werden an eine unabhängige Policy gebunden.
• Ein Modell darf keinen Zugriff selbst erweitern, nur weil eine gelesene Datei dies behauptet.
• Ein Skill, Plugin oder MCP-Connector erhält zunächst die niedrigste Vertrauensstufe.
• Jede Ablehnung wird mit Quelle, Tool, Argumenten und Policy-Grund protokolliert.

Welche Aufgaben sollten DeepSeek-Harness-Nutzer jetzt pausieren? Pausieren Sie bis zum erfolgreichen Regressionstest alle Aufgaben, bei denen ein externer Inhalt direkt eine nicht rückholbare Aktion auslösen kann: E-Mail-Versand, externe Formularübermittlung, produktive Shell-Ausführung, Änderungen an gemeinsamen Dateien, Zugriff auf Geheimnisse, Rechteänderungen und finanzielle Vorgänge. Reines Zusammenfassen oder Entwerfen kann weiterlaufen, sofern der Agent keine sensiblen Tools erreichen kann.

Erste drei Tage: Provenienz und Freigabe trennen

Die wichtigste Ergänzung ist eine Quellenmarkierung, die nicht nur im Benutzerinterface sichtbar ist. Jeder eingelesene Inhalt sollte mindestens diese Attribute behalten:

• Quelle oder Connector;
• Vertrauensstufe;
• Trägertyp, etwa HTML, PDF, E-Mail, Skill oder MCP;
• Zeitstempel und Versionsstand;
• verantwortlicher Eigentümer;
• zulässige Folgeoperationen.

Diese Metadaten müssen bis zur Tool-Policy erhalten bleiben. Eine bloße Markierung im Prompt genügt nicht, wenn der Inhalt später ohne Herkunft in einen allgemeinen Tool-Result-Block kopiert wird.

Warum können Skills und Webseiten einen sensiblen Tool-Aufruf beeinflussen? Weil beide als modelllesbarer Kontext in den Agentenpfad gelangen. Eine Webseite kann Anweisungen in sichtbarem Text, HTML-Feldern oder eingebetteten Darstellungen transportieren. Ein Skill ist noch kritischer, weil er als wiederverwendbare Handlungsbeschreibung in den normalen Arbeitsablauf eingebunden wird. Die Studie meldete für den Skills-Kanal bei Dateiträgern eine regelbasierte Vollerfolgsquote von 16,0 %. Das ist kein allgemeiner Skill-Risikowert, aber ein ausreichender Grund, Skills wie code-nahe Assets mit Eigentümer, Versionsprüfung und Berechtigungsgrenze zu behandeln. (Befunde zu Skills und Dateiträgern)

AI-Infra-Guard beschreibt seine Fähigkeiten als Agent-, Skill- und MCP-Scan sowie als Jailbreak- und Red-Team-Evaluierung. Für Ihr Vorgehen ist dabei nicht entscheidend, ein externes Scanergebnis blind zu übernehmen. Entscheidend ist, die Werkzeuge zur Erstellung einer wiederholbaren Testmatrix und zur Prüfung von Skill- und MCP-Quellen zu nutzen. (Dokumentation und öffentliches Repository von AI-Infra-Guard)

Eine Warnung im Systemprompt kann die gewünschte Sicherheitsbotschaft unterstützen, darf aber nicht die einzige Sperre sein. Der Grund ist strukturell: Der Angreifer kontrolliert den gelesenen Inhalt, während die Anwendung die eigentliche Autorisierung kontrollieren muss. Shell-Ausführung, Dateiänderung und externe Übermittlung benötigen deshalb eine Entscheidung außerhalb der Modellinterpretation.

Erste Woche: Skills, Dateien und Integrationen

Beginnen Sie mit den Trägern, die in der Studie besonders auffällig waren, und ergänzen Sie danach Ihre realen Integrationen. Prüfen Sie nicht nur den sichtbaren Text. Beziehen Sie Parser- und Darstellungsgrenzen ein:

1. Inventarisieren Sie alle Skills, MCP-Server, Plugins und Tool-Beschreibungen.
2. Erfassen Sie Eigentümer, Quell-Repository, Commit oder Paketversion und benötigte Rechte.
3. Prüfen Sie HTML, PDF-Metadaten, Tabellenfelder, E-Mail-Header und versteckte Unicode-Zeichen.
4. Normalisieren Sie Inhalte für die Sicherheitsprüfung, ohne den Originalträger zu verlieren.
5. Markieren Sie Anweisungen aus externen Quellen als Daten, nicht als Autorität.
6. Führen Sie jeden Test mit lokalen Fixtures und simulierten Sinks aus.
7. Speichern Sie den vollständigen Trace für eine manuelle Nachprüfung.

Gerade der Vergleich von Text- und Dateimodus darf nicht entfallen. Die Studie meldete im Dateimodus eine höhere regelbasierte Vollerfolgsquote als im Textmodus: 6,2 % gegenüber 5,1 %. Beim versteckten Unicode lag der Dateimodus bei 25,5 %, während im Textmodus kein vollständiger Erfolg registriert wurde. Der Befund zeigt nicht, dass jedes PDF oder jede Datei gefährlich ist. Er zeigt, dass eine reine Kopie des sichtbaren Textes relevante Parser- und Repräsentationseffekte auslassen kann. (Ergebnisse nach Träger und Darstellungsform)

Ihre Testumgebung sollte keine echten Kundendateien, Zugangsdaten oder produktiven Endpunkte verwenden. Ein sauberer Testfall braucht:

• eine harmlose Benutzeraufgabe;
• einen kontrolliert manipulierten Träger;
• ein klar definiertes Ziel-Tool;
• erwartete Argumente;
• einen lokalen Sink, der nur protokolliert;
• eine Entscheidung, ob der Aufruf blockiert oder bestätigt werden musste.

Für technische Teams ist außerdem eine getrennte Arbeitsumgebung sinnvoll. Bei der Wahl zwischen Bare Metal und Virtualisierung sollten Sie neben der Leistung auch Snapshot-Fähigkeit, Zugriffstrennung, Datenlöschung und die Nachvollziehbarkeit von Regressionen bewerten. Eine Gegenüberstellung von Bare Metal und macOS-Virtualisierung kann dafür als technische Orientierung dienen. Eine zweite getrennte Testumgebung lässt sich nach denselben Kriterien bewerten: Entscheidend sind reproduzierbare Snapshots, minimale Zugangsdaten und eine nachvollziehbare Löschung der Testdaten.

Vor der Ausweitung: Eigene Regression

Die Studienquote ist ein Risikosignal. Ihre Freigabeentscheidung muss jedoch aus eigenen Fällen entstehen. Wählen Sie wenige, aber repräsentative Szenarien:

• Webseite lesen, danach nur Zusammenfassung erzeugen;
• PDF mit manipulierten Metadaten lesen, danach einen Entwurf erstellen;
• Skill laden, danach eine ungefährliche lokale Analyse starten;
• MCP-Ergebnis verarbeiten, danach eine blockierte externe Übermittlung anfordern;
• Code-Kommentar lesen, danach einen Patch ohne Schreibrecht erzeugen;
• E-Mail-Inhalt lesen, danach Empfänger und Nachricht getrennt zur Bestätigung vorlegen.

Erfassen Sie pro Fall vier getrennte Beobachtungen:

Bewerten Sie nicht nur den Endstatus. Ein Agent, der den Sink nicht ausführt, aber seine Planung wegen eines manipulierten Dokuments ändert, ist für eine weitere Analyse relevant. Der semantische Prüfer der Arbeit wurde gerade für solche Teilbeeinflussungen eingesetzt; seine 7,3 % lagen deutlich über den 2,0 % des regelbasierten Prüfers.

Abnahme-Checkliste für den Pilotbetrieb

• [ ] Aktive DeepSeek-Harness-Version und Commit sind dokumentiert.
• [ ] Abweichungen zum untersuchten Commit vom 13.08.2026 sind bewertet.
• [ ] v0.1.0-rc.7 wurde nicht ohne eigenen Diff als Sicherheitsfix eingestuft.
• [ ] Jede externe Quelle besitzt Herkunft, Vertrauensstufe und Trägertyp.
• [ ] Skills und MCP-Integrationen haben Eigentümer und Versionsnachweis.
• [ ] Sensible Tools besitzen eine unabhängige Allowlist oder Freigaberegel.
• [ ] Datei-, Text-, Metadaten- und Unicode-Fälle sind enthalten.
• [ ] Alle Sinks sind im Test lokal oder anderweitig ohne echte Außenwirkung.
• [ ] Traces speichern Benutzeraufgabe, Quelle, Tool-Aufruf und Policy-Entscheidung.
• [ ] Ein negativer Test bestätigt, dass das Modell eine Ablehnung nicht umgehen kann.
• [ ] Ein positiver Test bestätigt, dass legitime Aufgaben weiterhin funktionieren.
• [ ] Die Entscheidung für Pilotfortsetzung oder Einschränkung ist schriftlich festgehalten.

Nachfolgende Versionen: Entscheidung an Änderungen knüpfen

Die Kontrolle endet nicht mit der ersten Regression. Bei jedem neuen Release prüfen Sie vier Änderungsflächen:

1. Hat sich der Agentenloop oder die Session-Ereigniskette verändert?
2. Können Tool-Ergebnisse zusätzliche Kontexte anders einfügen?
3. Wurden Skills, Plugins, MCP- oder ACP-Anhänge erweitert?
4. Haben sich Standardberechtigungen, Freigaben oder Sandbox-Grenzen verändert?

Wenn eine dieser Flächen betroffen ist, führen Sie mindestens die repräsentativen Quellen-zu-Sink-Fälle erneut aus. Eine neue Forschungsarbeit oder eine überarbeitete arXiv-Fassung ersetzt Ihre lokale Messung nicht. Umgekehrt darf ein lokaler Fehlschlag nicht automatisch als allgemeine Aussage über alle DeepSeek-Harness-Installationen gelten.

Die Entscheidungsmatrix kann einfach bleiben:

Für die technische Isolation sollten Sie außerdem prüfen, ob Test- und Produktivumgebung tatsächlich getrennt sind. Ein eigener, verworfener Arbeitsbereich, minimale Zugangsdaten und getrennte Netzwerkregeln helfen gegen Folgeschäden, beheben aber nicht die Ursache einer manipulierten Tool-Entscheidung. Für reproduzierbare Regressionen kann ein separater Testknoten gegenüber einem gemeinsam genutzten Entwicklerrechner Vorteile bieten. Entscheidend sind dabei nicht allein die Rechenleistung, sondern getrennte Zugangsdaten, ein klarer Datenlebenszyklus und eine Umgebung, die nach dem Test zurückgesetzt werden kann.

Wenn Ihre aktuelle Lösung auf einem gemeinsam genutzten Windows- oder Linux-Arbeitsplatz läuft, bleiben drei Nachteile: Quellen, Geheimnisse und Arbeitsdateien liegen oft näher beieinander; Freigaben werden leichter durch lokale Gewohnheiten umgangen; und ein reproduzierbarer Snapshot der Testumgebung ist schwerer sauber zu halten. Für kurzfristige Regressionen oder einen begrenzten Pilotbetrieb kann ein gemieteter Mac von MacDate deshalb die bessere Arbeitsumgebung sein: getrennte Instanz, klarer Testumfang und weniger Risiko, den privaten Rechner mit Agentenrechten zu vermischen. Für dauerhaft hohe Last, besondere physische Schnittstellen oder langfristig konstante Nutzung ist der Kauf eigener Hardware weiterhin die ehrlichere Option.

Wenn Sie den Forschungsbefund jetzt in einen kontrollierten Ablauf übersetzen möchten, beginnen Sie mit der Prüfung Ihrer Berechtigungen, des Skill-Vertrauens und der Arbeitsbereichsisolierung. Dokumentieren Sie jede Abweichung zwischen Ihrer Installation und dem untersuchten Stand. Entscheidend ist nicht, ob eine fremde Prozentzahl beruhigt oder alarmiert, sondern ob Ihre eigene Policy einen manipulierten Inhalt vor dem sensiblen Tool zuverlässig stoppt.