Sie haben Ihrem Agenten gesagt, er soll die Fehler beheben. Einer davon stammte von einem Angreifer.

Ein Entwickler öffnet seinen KI-Coding-Agenten und tippt die gewöhnlichste Anfrage der Welt: „Schau dir die offenen Sentry-Fehler an und behebe sie.“ Der Agent ruft die Fehlerliste über seinen Sentry-Konnektor ab, liest den obersten Eintrag, befolgt die Schritte zur Behebung, die direkt im Bericht stehen, und führt sie aus. Eine halbe Minute später hat er den Code eines Angreifers auf der Maschine des Entwicklers ausgeführt, mit den vollen Rechten des Entwicklers — und niemand hat etwas falsch gemacht.

Das ist Agentjacking, diesen Monat von Tenet Security offengelegt, und es funktionierte in 85 Prozent der Fälle gegen die drei verbreitetsten Coding-Agenten auf dem Markt: Claude Code, Cursor und Codex [1][2].

Was tatsächlich passiert ist

Zunächst, was Sentry ist: einer der meistgenutzten Fehlerüberwachungsdienste in der Software. Wenn Ihre Anwendung einen Fehler wirft oder abstürzt, erfasst Sentry ihn und legt den Bericht ab, den Ihre Entwickler triagieren — er steckt in einem großen Anteil der Anwendungen, mit denen Sie täglich zu tun haben. Um diese Berichte zu senden, bindet jede Anwendung einen DSN ein: einen clientseitigen Schlüssel, der absichtlich im Quelltext Ihrer Website ausgeliefert wird, damit der Browser Fehler nach Hause melden kann. Jeder kann ihn lesen. Und jeder, der ihn besitzt, kann ein Fehlerereignis per POST in Ihr Sentry-Projekt einstellen.

Das ist der ganze Schlüssel des Angriffs. Tenet hat ein gefälschtes Fehlerereignis gebaut, dessen message-Feld exakt im Format von Sentries eigener Behebungsanleitung gehalten war: ordentliches Markdown, eine „empfohlene Korrektur“, ein auszuführender Befehl. Eingereicht wurde es mit dem öffentlichen DSN. Dann warteten sie auf die natürlichste Handlung eines Entwicklers — den Agenten die Fehlerwarteschlänge abarbeiten zu lassen.

Der Agent fragt Sentry über seinen MCP-Konnektor ab. Der Konnektor liefert den Fehler als vertrauenswürdige Systemausgabe zurück. Der Agent kann einen echten Sentry-Bericht nicht von einem gefälschten unterscheiden; sie sind bytegenau in derselben Form. Also tut er, was ihm gesagt wird, und führt die „Korrektur“ aus, üblicherweise ein npx-Aufruf auf ein Paket des Angreifers. Ab diesem Punkt hat er alles, was der Entwickler hat: Umgebungsvariablen, Git-Zugangsdaten, private Repository-URLs, die Cloud-Schlüssel in ~/.aws/.

Tenet fand 2.388 Organisationen mit injizierbaren DSNs, von unabhängigen Entwicklern bis zur Fortune 100. In kontrollierten Tests führten Agenten die injizierten Anweisungen tatsächlich bei echten Unternehmen aus — darunter, so Tenet, ein 250-Milliarden-Dollar-Technologiekonzern aus der Fortune 100, dessen KI-Agent den gefälschten Fehlerbericht las und Tenets Code auf zwei seiner Firmenrechner ausführte [1][3]. Gegenüber Sentry offengelegt am 3. Juni, bestätigte das Unternehmen es noch am selben Tag und lehnte eine Behebung an der Wurzel ab; das Problem sei „technisch nicht verteidigbar“. Ausgeliefert wurde ein Inhaltsfilter, der eine bestimmte Payload-Zeichenkette blockiert [4].

Das ist kein Leichtsinn von Sentry

Jetzt der unangenehme Teil: In dieser Kette war nichts ein Bug. Der DSN sollte öffentlich sein. Der MCP-Server sollte Ihre Fehlerdaten zurückgeben. Der Agent sollte auf die Diagnosen reagieren, um deren Behebung Sie ihn gebeten haben. Jeder Schritt war autorisiert — und genau deshalb hat keine Firewall, kein EDR, keine Systemanweisung ihn erkannt.

Der Schwachpunkt ist strukturell, und er ist nicht Sentries allein. Jedes Werkzeug, das einem Agenten Text zuführt, den ein Außenstehender beeinflussen kann — ein Fehlertracker, eine Ticketliste, eine abgerufene Webseite, ein geteiltes Dokument —, ist ein Injektionskanal, und der Agent behandelt all das als einen einzigen, nicht unterschiedenen Strom von Anweisungen. Prompt Injection ist zwei Jahre in der Agenten-Ära immer noch ungelöst: Sie können feindseligen Text nicht zuverlässig aus dem Schließen einer Modells heraushalten. Gehen Sie davon aus, dass es Ihnen nicht gelingt.

Die Injektion ist nicht die Katastrophe

Der Teil, über den es sich nachzudenken lohnt. Der Grund, warum Agentjacking ein Fünf-Alarm-Feuer ist, ist nicht, dass der Agent hereingelegt wurde. Es ist das, was der hereingelegte Agent erreichen konnte. Er lief mit dem vollen dauerhaften Zugriff des Entwicklers: jeder Schlüssel in der Umgebung, jede Zugangsdatei auf der Festplatte, der ganze Schlüsselbund einen Befehl entfernt.

Dieser Wirkungsbereich ist kein Naturgesetz. Er ist eine Konfiguration. Der Agent hatte dauerhaften Zugriff auf all das, weil Zugangsdaten heute so gespeichert werden — überall verfügbar, auf dem Rechner, lesbar für alles, was dort läuft. Entfernen Sie das, und derselbe Überlauf läuft gegen eine Wand.

Bewusst dafür gebaut

Eine Clavitor-Zugangsdaten liegt nie in der Umgebung, in der der Agent läuft. Es gibt keine ~/.aws/credentials zum Lesen, keinen API-Schlüssel in einer Umgebungsvariable zum Abziehen, weil der geheime Wert nie dort landet, wo der Code ausgeführt wird — der Agent erhält das Ergebnis der Verwendung einer Zugangsdaten, nicht die Zugangsdaten selbst. Er erreicht nur die eine Sache, für die sie benannt wurde, und kann den Speicher daher nicht aufnehmen, um herauszufinden, was noch darin liegt. Und die Freigabe ist begrenzt und widerrufbar, sodass eine Sitzung, die sich plötzlich wie ein Angreifer verhält, mitten in der Aktion abgeschnitten werden kann.

Der ehrliche Vorbehalt: Das stoppt nicht die Injektion, und es stoppt nicht einen gekaperten Agenten daran, einen Befehl auszuführen. Prompt Injection ist ungelöst, und wir behaupten nicht, sie zu lösen. Was sich ändert, ist die Ausbeute. Der Code des Angreifers läuft weiterhin — und findet eine Umgebung vor, in der ihm nichts Stehendes etwas Wertvolles zum Stehlen bietet. Der Übergriff gelingt, der Raubzug scheitert.

Wir haben die Regeln aufgeschrieben, die ein Zugangsdatensystem einhalten muss, sobald der Agent selbst gegen Sie gedreht werden kann — angefangen damit, dass das Geheimnis nie dort lebt, wo der Code läuft, und ein Agent nur je erreicht, wofür er benannt wurde. Prüfen Sie Ihre eigenen daran entlang: clavitor.ai/rules.

Die Lehre lautet nicht „Sentry patchen“

Sentry kann das nicht beheben, und hat das gesagt. Und das nächste vergiftete Werkzeug wird nicht Sentry sein. Solange Ihre Agenten überall verfügbare, dauerhafte Zugangsdaten mit sich führen, ist jedes vertrauenswürdige Werkzeug, das sie lesen, eine geladene Waffe — und Prompt Injection ist der Abzug, den Sie nicht sichern können.

Sie werden den bösartigen Text nicht draußen halten. Also hören Sie auf, die Zugangsdaten in Reichweite des Agenten zu halten, der ihn liest.

Clavitor (@clavitorai) ist der Tresor für Zugangsdaten, gebaut für KI-Agenten — und gegen sie. clavitor.ai

Quellen

[1] Tenet Security — "Agentjacking: hijacking coding agents with fake Sentry errors" (85% Erfolgsquote; 2.388 Organisationen; Mechanismus): https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/

[2] The Hacker News — "Agentjacking Attack Tricks AI Coding Agents Into Running Malicious Code": https://thehackernews.com/2026/06/agentjacking-attack-tricks-ai-coding.html

[3] The New Stack — "A public Sentry key is all it takes to hijack Claude Code, Cursor, and Codex": https://thenewstack.io/agentjacking-sentry-mcp-attack/

[4] Infosecurity Magazine — "New 'Agentjacking' Attacks Could Hijack AI Coding Agents" (Sentry's response): https://www.infosecurity-magazine.com/news/agentjacking-attacks-hijack-ai/