senn-techAgentjacking: 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.
Weiterführende Quellen
Was ist Agentjacking genau?+
Agentjacking ist eine Form der Prompt-Injection über Werkzeug-Ausgaben. Ein Angreifer versteckt Anweisungen in Daten, die der Agent ohnehin liest — etwa einem Fehlerbericht von Sentry oder einer Logdatei. Weil der Agent Daten und Befehl nicht sauber trennt, führt er die Anweisung mit aus: ändert Code, liest Secrets oder führt Befehle aus.
Welche Leitplanken schützen wirksam vor Agentjacking?+
Least Privilege: der Agent läuft mit minimalen Rechten und ohne breiten Zugriff auf Secrets oder Produktion. Mensch in der Schleife: schreibende Aktionen werden bestätigt. Sandbox und Egress-Kontrolle kapseln die Ausführung und drosseln ausgehende Verbindungen. Werkzeug-Ausgaben werden als Daten behandelt, nicht als Anweisungen — bekannte Sicherheitsprinzipien statt neuer Werkzeuge.
Müssen wir deshalb auf KI-Agenten verzichten?+
Nein. Die Lehre ist nicht, keine Agenten einzusetzen, sondern wie immer in der IT-Sicherheit: Vertrauen explizit machen, Rechte klein halten, ausführende Schritte absichern. Eine klare Policy, die regelt, welche Werkzeuge ein Agent überhaupt anbinden darf, schließt einen Großteil der Angriffsfläche von vornherein. So nutzen wir die Stärke der Agenten, ohne die Flanke zu öffnen.