Agentjacking: Wenn die Fehlermeldung den KI-Agenten kapert
Coding-Agenten sind im Alltag angekommen — und mit ihnen eine neue Angriffsklasse. Agentjacking nutzt nicht eine Lücke im Modell, sondern das Vertrauen des Agenten in seine Werkzeuge. Wer Agenten produktiv einsetzt, muss verstehen, dass hier eine neue Angriffsfläche entsteht — und dass bewährte IT-Sicherheits-Prinzipien unverändert gelten. Das gilt besonders für den Mittelstand, wo KI-Agenten zunehmend Anschlüsse an produktionsnahe Systeme bekommen und ein einziger fehlerhafter Automatismus schnell reale Folgen hat.
Wie der Angriff funktioniert
- Vertrauen als Einfallstor: KI-Coding-Agenten wie Claude Code oder Cursor lesen routinemäßig Tool-Ausgaben — etwa Fehlerberichte aus einem Error-Tracking-Dienst wie Sentry.
- Schadbefehl im Datenstrom: Ein Angreifer platziert in genau diesen Ausgaben verdeckte Anweisungen. Der Agent kann Daten und Befehl nicht sauber trennen und führt sie mit aus.
- Die Folge: Der Agent tut Dinge, die niemand beauftragt hat — Code ändern, Secrets auslesen, Befehle ausführen. Klassische Prompt-Injection, nur über einen Kanal, dem man bisher vertraut hat.
Das Tückische daran: Diese Kanäle gelten klassischerweise als unbedenklich. Ein Stacktrace oder eine Logdatei wird als reine Information wahrgenommen — nicht als potenzielle Befehlsquelle. Genau diese Annahme bricht der Angriff. Praktisch bedeutet das: Alles, was der Agent an Daten liest — eine API-Antwort, eine Webseite, eine vom Nutzer importierte Datei —, muss als potenziell feindlich betrachtet werden.
Was wirklich hilft
- Least Privilege: Der Agent läuft mit minimalen Rechten, ohne breiten Zugriff auf Secrets, Produktion oder das offene Internet.
- Mensch in der Schleife: Schreibende oder ausführende Aktionen werden bestätigt, nicht blind automatisiert.
- Sandbox & Egress-Kontrolle: Ausführung gekapselt, ausgehende Verbindungen eingeschränkt — exfiltrtierte Daten kommen so nicht weit.
- Quellen misstrauen: Tool-Ausgaben sind Daten, keine Anweisungen. Wer das im Agenten-Design verankert, nimmt der Angriffsklasse die Grundlage.
Diese Maßnahmen wirken banal, weil sie genau das sind, was gute IT-Sicherheit ohnehin verlangt. Gerade das ist die Pointe: Gegen Agentjacking hilft kein neues Werkzeug, sondern die konsequente Anwendung bekannter Prinzipien.
Warum gerade jetzt
Dass diese Angriffsklasse jetzt relevant wird, hat einen einfachen Grund: Agenten greifen zunehmend auf externe Datenquellen zu — Ticketsysteme, Dokumentationen, Log-Archiv. Jede zusätzliche Quelle ist ein potenzieller Injektionskanal. Je mehr Werkzeuge der Agent ansteuert, desto größer wird die Fläche, über die Anweisungen eingeschleust werden können. Dass das längst nicht mehr theoretisch ist, zeigt der Vorfall rund um die Modell-Evaluations-Pipeline von OpenAI und Hugging Face. Im Mittelstand, wo Agenten oft mit Zugang zu produktionsnahen Systemen arbeiten, wiegt das besonders. Hinzu kommt: Wer Agenten ohne klare Leitplanken einsetzt, weil die Zeit knapp ist, öffnet genau die Flanke, die der Angriff braucht. Eine klare Policy, die regelt, welche Werkzeuge ein Agent überhaupt anbinden darf, schließt einen Großteil dieser Fläche von vornherein.
Unsere Sicht
Agentic Coding ist gekommen, um zu bleiben — und damit auch diese Angriffsklasse. Die Lehre ist nicht "keine Agenten", sondern dieselbe wie immer in der IT-Sicherheit: Vertrauen explizit machen, Rechte klein halten, ausführende Schritte absichern. Wer Agenten so betreibt, nutzt ihre Stärke, ohne die offene Flanke zu öffnen.