Ein KI-Agent wirkt im Enterprise-Alltag oft wie eine kontrollierte Schnittstelle: Ein Nutzer stellt eine Aufgabe, das Modell entscheidet über den nächsten Schritt, und erst danach wird ein Tool ausgeführt. Genau auf diese Annahme bauen viele Sicherheitskonzepte auf. System-Prompts sollen Grenzen setzen, Guardrails sollen gefährliche Antworten verhindern, Freigaben sollen sensible Aktionen absichern. Die neue CoreBreak-Forschung, die Hedi Ingber und Aviyam Ivgi von Stealth auf der Black Hat USA 2026 vorgestellt haben und über die The Hacker News berichtet, zeigt jedoch ein praktischeres Problem: In mehreren Agenten-Laufzeiten konnte tool-call-förmige Eingabe an der Modellentscheidung vorbeikommen. Dann läuft nicht ein „überredetes“ Modell aus dem Ruder, sondern die Ausführungsschicht behandelt fremde oder gefälschte Tool-Aufrufe als autorisiert.
Das ist für Unternehmen relevant, weil Agenten zunehmend nicht nur Text generieren, sondern mit Repositorys, Ticketsystemen, Cloud-APIs, Secrets, Deployments oder Datenbanken verbunden werden. Wenn die Laufzeit nicht beweist, dass ein konkreter Tool-Aufruf aus einem legitimen Modellturn stammt, helfen rein promptbasierte Kontrollen an der falschen Stelle. Die Kernfrage lautet dann nicht: „Ist der Prompt gut genug?“, sondern: „Wer darf einen Tool-Aufruf in die Dispatch-Schicht bringen?“
Was technisch passiert ist
The Hacker News beschreibt drei unterschiedliche, aber strukturell verwandte Fälle bei Amazon Bedrock AgentCore, Googles Agent Development Kit für Python und Vercels AI-SDK-Harness-Paketen für Codex und OpenCode. Die Gemeinsamkeit: Die betroffenen Pfade prüften nicht hart genug, ob ein Tool-Aufruf tatsächlich von einem Modell erzeugt und freigegeben wurde. Daten, die wie ein Tool-Aufruf aussahen, konnten unter bestimmten Voraussetzungen direkt oder indirekt in die Ausführung gelangen.
Bei AWS betrifft der offizielle Security Bulletin CVE-2026-18830 im Amazon Bedrock AgentCore Harness. AWS beschreibt „insufficient input validation“ im InvokeHarness-API: Ein authentifizierter Nutzer konnte in der letzten Nachricht eines Requests einen tool-use-Content-Block platzieren. Die Event-Loop konnte dann das genannte Tool direkt dispatchen, ohne das Modell aufzurufen und ohne modellseitige Sicherheitskontrollen. AWS gibt als betroffenen Zeitraum die verwaltete InvokeHarness-API vor dem 31. Juli 2026 an. Die Plattformseite wurde laut AWS serverseitig so angepasst, dass vom Aufrufer gelieferte tool-use-Blöcke in der finalen Nachricht verworfen werden, bevor sie die Event-Loop erreichen. Kunden müssen für den Managed Service nach AWS-Angaben nichts aktiv tun.
Wichtig ist die Abgrenzung: Der potenzielle Schaden war laut AWS auf die Tools begrenzt, die im jeweiligen Harness konfiguriert waren. Ein Agent ohne sensible Tools kann dadurch weniger Schaden anrichten als ein Agent mit Zugriff auf Deployments, Secrets oder Cloud-Operationen. Genau deshalb ist Tool-Minimierung keine Nebensache, sondern ein zentraler Sicherheitsmechanismus.
Bei Google liegt der Fokus auf ADK for Python vor Version 2.5.0. The Hacker News nennt CVE-2026-18236 mit CVSS v4.0 9.3 für einen Bestätigungs-Forgery-Pfad: Ein Angreifer, der Events in der Session-Historie manipulieren oder injizieren konnte, konnte eine Tool-Bestätigung fälschen. Googles Patch prüft laut dem öffentlich einsehbaren Commit unter anderem, ob das Tool zum ausführenden Agenten gehört, ob es wirklich eine Bestätigung verlangt und ob Name und Argumente zum ursprünglichen Tool-Call in der Session passen. Ein zweiter Fix in ADK 2.5.0 verhindert außerdem, dass vom Nutzer stammende Events mit function_call-Teilen als direkte Werkzeuganweisung interpretiert werden; der Commit formuliert es ausdrücklich als Schutz vor einem LLM-Bypass und direkter Ausführung registrierter Tools.
Bei Vercel sind zwei GitHub Security Advisories besonders konkret. GHSA-qw9h-448j-6rph betrifft @ai-sdk/harness-codex bis einschließlich 1.0.28 und wurde als CVE-2026-64650 erfasst. GHSA-g48p-5rr5-8rgq betrifft @ai-sdk/harness-opencode bis einschließlich 1.0.27 und wurde als CVE-2026-64651 erfasst. Beide Advisories bewerten die Schwachstellen als „medium“ mit CVSS v4.0 6.3. Die technischen Voraussetzungen sind enger als bei AWS: Linux, eine aktive Harness-Session mit Host-Tools und bereits laufender untrusted Code im Sandbox-Kontext, etwa über eine bösartige Dependency, ein Build-Skript oder einen Lifecycle-Hook. Der Relay-Mechanismus vertraute Prozessen anhand eines Command-Line-Pfads zu einem erlaubten Helper-Skript. Die Patches entfernen diesen Prozesspfad-Fallback; akzeptiert werden nur noch exakte, kurzlebige, einmalige Autorisierungen, die zu einem beobachteten Modell-Event mit Toolname und Input passen.
Warum das mehr ist als Prompt Injection
CoreBreak ist kein klassischer Prompt-Injection-Fall. Bei Prompt Injection versucht ein Angreifer, das Modell mit Inhalt, Dokumenten oder Webseiten zu einer unerwünschten Entscheidung zu bewegen. Hier kann die Modellentscheidung in bestimmten Pfaden komplett fehlen. Wenn die Laufzeit tool-call-förmige Daten als Autorität akzeptiert, werden System-Prompt, Content-Filter und Modell-Guardrails nicht umgangen, sondern gar nicht erst beteiligt.
Für Enterprise-Architekturen ist das ein entscheidender Unterschied. Viele Teams testen heute, ob ein Agent auf gefährliche Anweisungen im Prompt korrekt reagiert. Das bleibt nötig, reicht aber nicht. Zusätzlich müssen sie die Herkunft jedes Tool-Aufrufs prüfen: aus welcher Session, von welchem Modellturn, für welchen Toolnamen, mit welchen Argumenten, nach welcher Bestätigung und mit welcher Gültigkeitsdauer. Die robusten Fixes in den drei Fällen zeigen dieselbe Richtung: Session- und Argumentbindung statt bloßer Formprüfung.
Konkrete Implikationen für Unternehmen
Erstens sollten Agenten-Tools grundsätzlich mit Least Privilege konfiguriert werden. Ein Agent, der nur ein internes Knowledge-Base-Tool lesen darf, hat eine andere Risikolage als ein Coding-Agent mit Shell, Secrets, GitHub-Token und Cloud-Deployments. Die Frage „Welche Tools sind angeschlossen?“ gehört in jedes Agenten-Risikoregister.
Zweitens brauchen Agenten-Laufzeiten eine harte Provenienzprüfung für Tool-Aufrufe. Ein gültiger Tool-Call sollte nicht nur syntaktisch korrekt sein. Er sollte kryptografisch oder zumindest sessionlogisch an ein beobachtetes Modell-Event, einen konkreten Toolnamen, konkrete Argumente und eine kurze Lebensdauer gebunden sein. Wiederverwendbare Freigaben, clientseitig fälschbare Bestätigungen oder Prozesspfad-Heuristiken sind schwache Vertrauenssignale.
Drittens müssen untrusted Inputs getrennt behandelt werden: Repository-Inhalte, Build-Skripte, Paket-Lifecycle-Hooks, Nutzer-Events und persistente Session-Historie sind keine vertrauenswürdige Steuerfläche. Wenn solche Daten direkt in die Agenten-Historie, in Resumable-Flows oder an Host-Tool-Relays gelangen können, entsteht eine Ausführungskette außerhalb des Modells.
Viertens sollten Unternehmen Monitoring nicht erst beim Modell beginnen lassen. Relevante Signale sind ungewöhnliche Tool-Aufrufe ohne vorausgehenden Modellturn, wiederholte fehlgeschlagene Autorisierungen, Tool-Ausführung aus Sandbox-Prozessen, Änderungen an Session-Historien und Tool-Aufrufe mit sensiblen Argumenten. Für Coding-Agenten gehört zusätzlich die Beobachtung von Child-Prozessen, Paketinstallationen und Netzwerkzielen dazu.
Grenzen der aktuellen Lage
Die bekannten Fälle haben unterschiedliche Voraussetzungen. AWS beschreibt einen authentifizierten Remote-Pfad in einem Managed Service, Google setzt manipulierbare Session-Events oder user-authored Function Calls voraus, Vercel bereits laufenden untrusted Code in einer Linux-Sandbox. Es gibt in den zitierten Quellen keinen belastbaren Hinweis, dass diese Pfade vor der Behebung aktiv gegen Live-Deployments ausgenutzt wurden. Die Forscher haben laut The Hacker News Proof-of-Concept-Code an die betroffenen Anbieter gegeben, aber nicht öffentlich veröffentlicht.
Trotzdem ist das Thema stark genug für sofortige Architekturarbeit. Agenten-Sicherheit darf nicht darauf reduziert werden, bessere Prompts zu schreiben oder gefährliche Wörter zu filtern. Sobald Tools echte Unternehmensrechte haben, muss die Ausführungsschicht selbst Sicherheitsgrenze sein.
Fazit
CoreBreak zeigt eine nüchterne Lektion: Ein KI-Agent ist nicht nur ein Modell mit Prompt, sondern ein verteiltes System aus Session-Speicher, Tool-Dispatcher, Freigaben, Sandbox, Host-Brücke und Identitäten. Jede dieser Schichten kann zur Steuerfläche werden. Unternehmen sollten daher prüfen, ob ihre Agentenplattformen Tool-Aufrufe eindeutig an legitime Modellereignisse binden, ob angeschlossene Tools minimal berechtigt sind und ob untrusted Daten jemals als ausführungsnahe Agenten-Historie akzeptiert werden. Die richtige Kontrollfrage lautet nicht mehr nur „Was darf das Modell sagen?“, sondern „Was darf die Laufzeit ausführen, wenn das Modell gar nicht gefragt wurde?“
