Endpoint Detection and Response beantwortet seit zwei Jahrzehnten eine Frage gut: Tut dieser Prozess etwas, das schädlicher Code tun würde? Es prüft Signaturen, achtet auf anomales Verhalten und meldet unautorisierte Rechteausweitung. Ein KI-Agent mit Werkzeugzugriff bricht die Grundannahme dieser Frage — nicht, weil er schädlicher Code wäre, sondern weil er ein vertrauenswürdiges Programm ist, das dazu gebracht werden kann, seinen eigenen, völlig legitimen Zugriff zu missbrauchen.
Die Version dieses Problems von vor der KI hat schon einen Namen
Ein legitimes, signiertes Programm für etwas Schädliches zu benutzen, ist nicht neu. MITRE ATT&CK katalogisiert es als System Binary Proxy Execution (T1218): „Binärdateien, die mit vertrauenswürdigen digitalen Zertifikaten signiert sind, können auf Windows-Systemen mit Schutz durch Signaturprüfung typischerweise ausgeführt werden“ — genau deshalb tun sich Allowlisting und Signaturprüfungen schwer, sobald die vertrauenswürdige Binärdatei selbst zur handelnden Instanz wird. Ein KI-Agent überträgt dieselbe Schwäche auf ein Programm, das gar nicht erst mit schädlichem Code vorgeladen sein muss: Es kann zur Laufzeit umgelenkt werden, durch Text, den es liest.
Ein gekaperter Agent ist ein „confused deputy“
Der passende Begriff dafür ist das Confused-Deputy-Problem: „ein Computerprogramm, das von einem anderen Programm (mit weniger Privilegien oder Rechten) dazu gebracht wird, seine Autorität zu missbrauchen.“ Geben Sie einem Agenten echte Werkzeuge und lassen Sie ihn dann Inhalte lesen, die Sie nicht geprüft haben, und er kann von diesen Inhalten angewiesen werden. Genau dieses Muster beschreibt OWASPs Eintrag zu Prompt Injection, und es wurde bereits gezeigt, nicht nur theoretisch beschrieben: Ein Bericht von Invariant Labs vom 26. Mai 2025 zeigte, wie ein Coding-Agent, der ein gewöhnlich aussehendes GitHub-Issue in einem öffentlichen Repository liest, darin versteckten Anweisungen folgte und Daten aus einem privaten Repository preisgab — mit Werkzeugen, die ihm legitim erteilt worden waren. Die eigene Schlussfolgerung der Forscher: „Dies ist kein Fehler im Code des GitHub-MCP-Servers selbst, sondern ein grundlegendes architektonisches Problem, das auf Ebene des Agentensystems angegangen werden muss.“
process: python3 agent_worker.py --tool-socket 8443
user: developer (normal UID, no privilege escalation)
network: HTTPS POST to a domain the process has contacted before
signature: none matched, no known-bad hash
behaviour: consistent with routine developer tooling
# The same log line is produced whether agent_worker.py just fetched
# documentation the developer asked for, or was redirected by injected
# instructions to read a private file and POST it out.Das ist der eigentliche blinde Fleck: keine Lücke in einem einzelnen Produkt, sondern die Tatsache, dass der Protokolleintrag für „Agent hat seine normale Arbeit gemacht“ und „Agent wurde gekapert, um seine normale Arbeit zu missbrauchen“ auf Prozessebene identisch sein kann. An der Binärdatei hat sich nichts geändert. Am Muster der Systemaufrufe ist nichts neu. Nur die Absicht hinter der Anfrage hat sich geändert, und Absicht ist kein Feld in einem Prozessprotokoll.
Was das Risiko wirklich verringert — und was nicht
Es lohnt sich, genau zu sein, was die Person, die dieses Muster benannt hat, tatsächlich empfiehlt. Simon Willison, der die „lethal trifecta“ aus Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und externer Kommunikation zusammen in einem Agenten beschrieben hat, sagt ausdrücklich, dass das Vermeiden dieser Kombination die eigentliche Lösung ist, kein zusätzliches Sicherheitsnetz: „Der einzige Weg, dort sicher zu bleiben, besteht darin, genau diese tödliche Dreierkombination vollständig zu vermeiden.“ Er ist offen skeptisch gegenüber Produkten, die behaupten, eingeschleuste Anweisungen im Nachhinein zuverlässig zu erkennen, und merkt an, dass „wir immer noch nicht wissen, wie man das zu 100 Prozent zuverlässig verhindert“ und dass eine Trefferquote von 95 Prozent bei einer Sicherheitskontrolle „ganz klar nicht ausreichend“ sei.
- Design zuerst: Geben Sie einem Agenten nur die engstmöglichen Werkzeuge und den Datenzugriff, den seine Aufgabe braucht, damit eine erfolgreiche Injektion weniger auszunutzen hat (die architektonische Lösung, auf die sowohl Willison als auch Invariant Labs verweisen).
- Behandeln Sie jeden Inhalt, den der Agent liest und den Sie nicht selbst verfasst oder geprüft haben — Issues, abgerufene Seiten, heruntergeladene Dateien — grundsätzlich und jedes Mal als nicht vertrauenswürdige Eingabe.
- Wo Design und Prüfung nicht ausreichen: Der eine Schritt, den ein Versuch der Datenexfiltration nicht überspringen kann, ist eine ausgehende Netzwerkverbindung. Diese pro Prozess zu beobachten oder einzuschränken, verhindert nicht, dass ein Agent getäuscht wird, ist aber eine echte, unabhängige Schutzschicht, die nicht davon abhängt, die eingeschleuste Anweisung überhaupt zu erkennen.
Wo FireAI und HisnLabs ins Spiel kommen
No firewall makes a hijacked agent safe on its own, but the data it tries to send out still has to leave through a socket, and that is the one step FireAI watches regardless of which trusted binary the agent is running inside of.
FireAI ist das eigene Produkt von HisnLabs: eine KI-Firewall für den Mac, die direkt auf dem Gerät läuft. Sie zeigt jede Verbindung Ihrer Apps in verständlicher Sprache und lässt Sie entscheiden, was Ihren Mac verlässt — die KI arbeitet lokal, Ihr Datenverkehr wird also nie an uns oder irgendjemand anderen gesendet. Das Sicherheitsforschungsteam von HisnLabs sorgt dafür, dass diese Entscheidungen verlässlich bleiben: Es katalogisiert, welche Domains gewöhnliche Telemetrie und welche ein echter Dienst sind, verfolgt Land und Netzwerk hinter einer Verbindung und trainiert das lokale Modell (die Autopilot-Funktion) mit echten Verkehrsmustern — ohne dass irgendetwas davon Ihren Mac verlässt.
Die technischen Entscheidungen dahinter können Sie nachlesen — oder FireAI 17 Tage lang ausprobieren — unter FireAI, von HisnLabs.