GhostJacking legt Lücken in der Identitätsgovernance von KI-Agenten offen
Google News rückte GhostJacking in den Fokus, nachdem Forschende gezeigt hatten, wie ein einzelner manipulierte Fehlerbericht einen autorisierten KI-Agenten zu vom Angreifer kontrolliertem Code lenken kann. Der Angriff gelingt trotz Perimeter-Schutzmaßnahmen, weil der Agent jeden Schritt über legitime Tools und Entwicklerberechtigungen ausführt.
Diese Unterscheidung verändert die Sicherheitsdebatte. Die Zugangsdaten des Agenten werden nicht zwangsläufig gestohlen, und seine Software ist nicht zwangsläufig kompromittiert. Stattdessen verändern nicht vertrauenswürdige Betriebsdaten die Absicht des Agenten, während seine authentifizierte Identität gültig bleibt.
Die zugrunde liegende Forschung bezeichnet die breitere Technik als „Agentjacking“, während die Bezeichnung GhostJacking den beinahe unsichtbaren Charakter der Übernahme betont. Ein Agent arbeitet weiter unter seiner normalen Identität, sodass Verteidiger legitime Automatisierung von feindseliger Absicht unterscheiden müssen.
Dies ist nicht einfach eine weitere Geschichte über Prompt Injection. Es legt ein Zusammentreffen von Sprachmodellen, vertrauenswürdiger Telemetrie, Model Context Protocol-Integrationen und Identitätssystemen offen, die für vorhersehbare Nutzer konzipiert wurden.
Der zentrale Konflikt ist klar. Unternehmen möchten, dass Agenten Vorfälle untersuchen und Reparaturen ohne ständige Aufsicht ausführen. Doch genau die Berechtigungen, die diese Agenten nützlich machen, führen dazu, dass manipulierte Entscheidungen operativ gefährlich werden.
Der GhostJacking-Bericht macht aus einer Bug-Warteschlange einen Angriffsweg
GhostJacking verwandelt Informationen, denen ein Agent vertrauen soll, in Anweisungen, die der Agent möglicherweise ausführt.
Der im GhostJacking report beschriebene Angriff beginnt mit einem gefälschten Softwarefehler. Ein Angreifer platziert präparierten Text in Telemetriedaten, die ein Coding-Agent später bei der Untersuchung ungelöster Probleme abruft.
Mit Telemetrie sind die von Software erzeugten Logs, Fehler, Traces und Diagnoseaufzeichnungen gemeint. Entwicklungsteams behandeln dieses Material normalerweise als Beleg für Systemverhalten, nicht als aktiven Befehlskanal.
Diese Annahme bricht zusammen, wenn ein Sprachmodell das Material liest. Das Modell erhält Diagnosefakten, Kommentare, Formatierungen und potenzielle Anweisungen im selben Textstrom.
Tenet Security’s Threat Labs demonstrierte dieses Muster mit Sentry, einer Plattform zur Überwachung von Fehlern, die Anwendungsereignisse entgegennimmt. Sentry verwendet einen Data Source Name, kurz DSN, damit Anwendungen diese Ereignisse an das richtige Projekt übermitteln können.
Eine Browseranwendung benötigt diesen DSN häufig im clientseitigen Code. Sein Besitz kann daher ermöglichen, ein Ereignis zu übermitteln, ohne zuvor das interne Netzwerk der Organisation kompromittieren zu müssen.
Das Ereignis des Angreifers enthält eine überzeugende Fehlerbeschreibung und scheinbare Hinweise zur Behebung. Wenn ein Agent das Ereignis über eine Integration abruft, treffen die bösartigen Anweisungen zusammen mit legitimen Diagnosedaten ein.
Das Modell steht dann vor einem Klassifizierungsproblem. Es muss entscheiden, ob der Text einen Fehler beschreibt, eine externe Partei zitiert oder den Agenten anweist, eine Korrekturmaßnahme auszuführen.
Laut der kontrollierten Forschung interpretierten getestete Agenten das platzierte Material mitunter als gültige Schritte zur Problembehebung. Anschließend führten sie ein forschungsgesteuertes Paket mit den lokalen Berechtigungen des Entwicklers aus.
Tenet zufolge war sein Validierungspaket für kontrollierte Tests und nicht für schädliche Aktivitäten konzipiert. Das Unternehmen erklärt außerdem, dass gesammelte Informationen geschwärzt und gemäß seinem Offenlegungsverfahren behandelt wurden.
Die Sicherheitsfolgen reichen dennoch über das harmlose Paket hinaus. Ein feindseliger Befehl, der unter einem Entwicklerkonto ausgeführt wird, könnte auf Umgebungsvariablen, Quellcode-Repositories, Cloud-Zugangsdaten oder authentifizierte Entwicklungstools zugreifen.
Tenet berichtete, 2.388 Organisationen mit potenziell injizierbaren Sentry-Zugangsdaten identifiziert zu haben. Außerdem habe das Unternehmen bei kontrollierten Tests beobachtet, dass mehr als 100 Agenten auf injizierte Fehler reagierten.
Diese Zahlen stammen vom Sicherheitsanbieter und wurden nicht unabhängig für die gesamte berichtete Population reproduziert. Sie sollten die im Rahmen der Studie beobachtete Exponierung messen, nicht eine von Kriminellen bestätigte Kompromittierung.
Die entscheidende Veränderung ist architektonischer Natur. Logs waren einst passive Belege für Menschen und deterministische Software. Agentische Workflows können dieselben Logs in ausführbaren Kontext verwandeln.
Dadurch entsteht eine ungewöhnliche Rückkopplungsschleife. Eine Sicherheitskontrolle blockiert verdächtigen Datenverkehr, zeichnet die blockierte Anfrage auf und speichert den Text des Angreifers in einer vertrauenswürdigen Monitoring-Plattform.
Später liest ein KI-Agent den gespeicherten Datensatz, um den Vorfall zu diagnostizieren. Der erfolgreiche Block wird dann zum Übertragungsweg für die nächste Phase.
Warum die Aufmerksamkeit von Google News über eine einzelne Sicherheitsdemo hinausreicht
Die Sichtbarkeit bei Google News ist wichtig, weil GhostJacking ein abstraktes KI-Risiko mit einem gewöhnlichen Entwicklungsworkflow verbindet.
Indirekte Prompt Injection ist seit Jahren dokumentiert. Sie tritt auf, wenn bösartige Anweisungen in Daten eingebettet werden, die ein KI-System bei der Erledigung einer anderen Aufgabe verarbeitet.
Der Angreifer muss die Anweisungen nicht im direkten Prompt des Nutzers platzieren. Die Nutzlast kann in einer Webseite, E-Mail, einem Dokument, Support-Ticket, Code-Kommentar oder abgerufenen Datenbankeintrag erscheinen.
GhostJacking überträgt diese bekannte Schwachstelle auf Betriebsdaten. Das Ziel ist kein Chatbot, der eine harmlose Frage beantwortet. Es ist ein Agent, der Software diagnostizieren und möglicherweise Korrekturbefehle ausführen soll.
Dieser Unterschied erhöht den Einsatz. Ein Chatbot könnte eine irreführende Antwort erzeugen, während ein mit Befugnissen ausgestatteter Coding-Agent Dateien verändern, eine Shell aufrufen oder auf authentifizierte Dienste zugreifen kann.
Das Ereignis fällt zudem in eine Phase der raschen Einführung tool-verbundener Agenten. Model Context Protocol, üblicherweise MCP genannt, bietet Modellen eine standardisierte Möglichkeit, mit externen Tools und Datenquellen zu kommunizieren.
MCP kann den Aufwand verringern, einen Agenten mit Issue-Trackern, Datenbanken, Repositories, Monitoring-Plattformen und lokalen Entwicklertools zu verbinden. Es macht Inhalte aus diesen Systemen nicht automatisch vertrauenswürdig.
Ein Tool kann authentisch sein und dennoch vom Angreifer kontrollierte Daten zurückgeben. Diese Unterscheidung ist für den GhostJacking-Angriff zentral.
Die traditionelle Anwendungssicherheit fragt häufig, ob ein Aufrufer auf eine Ressource zugreifen darf. Hier darf der authentifizierte Agent auf die Ressource zugreifen und die daraus resultierende Aktion ausführen.
Die fehlende Frage lautet, ob die Aktion die Absicht des Nutzers widerspiegelt. Authentifizierung beantwortet, wer handelt, beweist jedoch nicht, warum die Handlung gewählt wurde.
NIST beschreibt Agent Hijacking als eine Form indirekter Prompt Injection, die durch eine schwache Trennung zwischen vertrauenswürdigen Anweisungen und nicht vertrauenswürdigen externen Daten entsteht. Die Hijacking-Evaluierungen umfassten Szenarien zu Remote Code Execution, Datenexfiltration und automatisiertem Phishing.
Die Forschenden von NIST stellten fest, dass adaptive Angriffe von großer Bedeutung waren. In einer Evaluierung erreichte der stärkste Basisangriff gegen ein aktualisiertes Modell eine Erfolgsrate von 11 Prozent.
Ein neu entwickelter Angriff erreichte im selben berichteten Testumfeld 81 Prozent. Das Ergebnis liefert keine universelle Fehlerrate für Modelle, stellt aber statische Behauptungen zur Widerstandsfähigkeit gegen Prompt Injection infrage.
Ein Modell kann bei einer bekannten Testsuite gut abschneiden und dennoch bei einem auf sein Verhalten zugeschnittenen Angriff versagen. Sicherheitsteams können einen einzelnen Benchmark daher nicht als dauerhafte Garantie betrachten.
Die Berichterstattung von Google News kann dazu beitragen, diese Erkenntnis über spezialisierte Kreise der KI-Sicherheit hinauszutragen. Der betroffene Workflow ähnelt dem, was Entwicklungsteams Agenten bereits tun lassen möchten: ein Problem prüfen, eine Ursache identifizieren und eine Lösung anwenden.
Der Artikel warnt daher nicht vor einer hypothetischen Superintelligenz. Er betrifft ein vertrautes Automatisierungstool, das mit vertrauten Zugangsdaten gegen vertraute Cloud-Dienste arbeitet.
Gerade diese Vertrautheit macht das Risiko leicht zu unterschätzen. Jede Komponente kann legitim erscheinen, wenn sie einzeln betrachtet wird.
Der Sentry-Dienst ist legitim. Die MCP-Integration ist legitim. Der Coding-Agent ist legitim, und das Konto des Entwicklers ist authentifiziert.
Das feindselige Element liegt im Übergang zwischen Daten und Absicht. Gegenwärtige Identitätskontrollen prüfen diesen Übergang nur selten.
Die Identitätsgovernance für KI-Agenten endet bei der Authentifizierung
Die Identitätsgovernance für KI-Agenten versagt, wenn sie den Akteur verifiziert, aber nicht die Autorisierung hinter jeder Entscheidung überprüfen kann.
Identitätssysteme für Menschen beginnen üblicherweise mit einer Person, einem Konto und zugewiesenen Berechtigungen. Administratoren können überprüfen, wem das Konto gehört und auf welche Ressourcen es zugreifen kann.
Service Accounts erweitern dieses Modell auf Anwendungen. Sie funktionieren recht gut, wenn Software deterministischem Code folgt und eine eng umrissene, dokumentierte Funktion erfüllt.
Ein KI-Agent verhält sich anders. Seine nächste Aktion hängt von Zielen in natürlicher Sprache, abgerufenem Kontext, dem Schlussfolgern des Modells, verfügbaren Tools und vorherigen Schritten innerhalb eines Workflows ab.
Derselbe authentifizierte Agent kann einen Fehler prüfen, ein Repository bearbeiten, einen Bereitstellungsdienst aufrufen und einem Team Nachrichten senden. Seine effektive Rolle verändert sich mit dem Fortschreiten der Aufgabe.
Organisationen bewältigen diese Komplexität oft, indem sie den Agenten bestehenden Zugriff eines Nutzers übernehmen lassen. Dieser Ansatz vereinfacht die Bereitstellung, schwächt jedoch die Zurechenbarkeit.
Ein Audit-Datensatz kann zeigen, dass ein Entwicklerkonto ein Paket gestartet hat. Er zeigt möglicherweise nicht, ob der Entwickler genau dieses Paket angefordert oder den Befehl zuvor geprüft hat.
Er kann auch auslassen, welches abgerufene Dokument das Modell beeinflusste. Ohne diese Herkunftsinformation sehen Untersuchende die abschließende Aktion, nicht jedoch die Autorisierungskette dahinter.
Die Umfrage zur Agentensicherheit der Cloud Security Alliance verdeutlicht die Lücke bei der Einsatzbereitschaft. Vierzig Prozent der befragten Organisationen gaben an, Agenten in der Produktion einzusetzen, während weitere 31 Prozent sie testeten.
Nur 18 Prozent berichteten von hoher Zuversicht, dass bestehende Identitätssysteme Agentenidentitäten wirksam verwalten könnten. Lediglich 21 Prozent führten ein Echtzeitregister oder -inventar von Agenten.
Die Umfrage stellte zudem eine anhaltende Abhängigkeit von statischen API-Schlüsseln, gemeinsam genutzten Service Accounts und Kombinationen aus Nutzername und Passwort fest. Diese Mechanismen können Zugriffe authentifizieren, ohne delegierte Absicht abzubilden.
Eine nützliche Agentenidentität sollte mehr beantworten als „Welches Token hat diese Anfrage gestellt?“ Sie sollte die Anfrage mit einem Eigentümer, einer Aufgabe, genehmigten Tools, dem Datenumfang und einem Ablaufzeitpunkt verknüpfen.
Dieser Datensatz sollte die Delegierung überdauern. Wenn ein primärer Agent einen Sub-Agenten erstellt, sollte das Kind nicht stillschweigend jede Berechtigung seines Elternteils übernehmen.
Jede delegierte Identität sollte nur die für ihren zugewiesenen Schritt erforderliche Autorität erhalten. Das System sollte außerdem die Beziehung zwischen Nutzer, übergeordnetem Agenten, untergeordnetem Agenten und der daraus resultierenden Aktion bewahren.
GhostJacking zeigt, was geschieht, wenn diese Kette implizit bleibt. Der bösartige Fehler muss die Identität des Agenten nicht stehlen, weil er die bereits vorhandene Identität lenken kann.
Dies ähnelt dem klassischen Problem des Confused Deputy. Ein vertrauenswürdiges Programm missbraucht seine Autorität, nachdem es von einem Angreifer beeinflusste Eingaben akzeptiert hat, die es nicht korrekt klassifizieren kann.
Sprachmodelle erschweren das Problem, weil sie Inhalte probabilistisch interpretieren. Eine geschickt formatierte „Lösung“ kann handlungsorientierter wirken als eine vage Nutzeranweisung.
Die Prompt-Hierarchie hilft Modellen, System- und Nutzeranweisungen zu priorisieren. Sie schafft jedoch keine kryptografische Grenze zwischen sachlichen Tool-Ausgaben und in diese Ausgaben eingebetteten Befehlen.
Auch die Kennzeichnung einer Quelle als nicht vertrauenswürdig hat Grenzen. Tenet zufolge folgten Agenten mitunter injizierten Anweisungen, obwohl ihre Konfigurationen sie dazu aufforderten, externe Inhalte zu misstrauen.
Diese Behauptung erfordert breitere, unabhängige Tests über Modelle und Konfigurationen hinweg. Die adaptiven Ergebnisse von NIST stützen jedoch die allgemeinere Warnung, dass rein anweisungsbasierte Abwehrmechanismen unter gezieltem Druck an Wirksamkeit verlieren.
Die Identitätsebene muss daher davon ausgehen, dass das Modell eine falsche Entscheidung treffen kann. Governance sollte die Folgen begrenzen, bevor diese Entscheidung zu einer irreversiblen Handlung wird.
Der zentrale Zielkonflikt lautet: nützlicher Zugriff versus überprüfbare Absicht
Ein Agent wird nützlicher, je mehr Zugriffe er erhält, doch jede zusätzliche Berechtigung vergrößert die Auswirkungen manipulierter Absichten.
Ein Coding-Assistent, der auf Vorschläge beschränkt ist, kann dennoch unsicheren Code erzeugen. Ein Coding-Agent mit Terminalzugriff kann diesen Code ausführen, bevor ihn ein Entwickler liest.
Ein Incident-Agent, der auf Zusammenfassungen beschränkt ist, kann eine Untersuchung verzerren. Derselbe Agent mit Produktionszugriff kann Infrastruktur verändern, während er einem manipulierten Diagnoseprotokoll folgt.
Dadurch entsteht ein praktischer Zielkonflikt, jedoch kein Grund, sämtliche agentische Automatisierung abzulehnen. Unternehmen müssen Autonomie mit schrittweise stärkeren Kontrollen verbinden.
Schreibgeschützter Zugriff sollte für Erkundung und Diagnose der Standard bleiben. Schreibzugriff sollte für konkrete Aufgaben, Ressourcen und Zeitfenster gewährt werden.
Die Befehlsausführung verdient eine eigene Grenze. Ein Agent, der Monitoring-Daten abrufen kann, sollte nicht automatisch uneingeschränkt berechtigt sein, alles auszuführen, was diese Daten empfehlen.
Aktionen mit hohem Risiko benötigen zudem eine semantische Autorisierung. Das bedeutet, Zweck und Kontext einer Handlung zu bewerten, statt lediglich zu prüfen, ob der Aufrufer ein gültiges Token besitzt.
Eine Richtlinie kann einem Agenten beispielsweise erlauben, einen freigegebenen Testbefehl in einem isolierten Workspace auszuführen. Dieselbe Richtlinie kann die Paketinstallation, den Zugriff auf Zugangsdaten oder ausgehende Verbindungen untersagen.
Diese Entscheidungen sollten außerhalb des Modells getroffen werden. Den potenziell manipulierten Agenten selbst über seinen eigenen Befehl urteilen zu lassen, schafft keine unabhängige Kontrolle.
Durchsetzung zur Laufzeit sorgt für eine stärkere Trennung. Ein Gateway kann jeden angeforderten Tool-Aufruf prüfen, ihn mit Richtlinien abgleichen und Aktionen außerhalb der freigegebenen Aufgabe blockieren.
Das Gateway schafft außerdem einen Ort, an dem strukturierte Nachweise erfasst werden können. Dazu können die anfragende Identität, das Nutzerziel, die abgerufene Quelle, die angeforderte Operation, die Richtlinienentscheidung und das Ergebnis gehören.
Menschliche Freigaben bleiben sinnvoll, wenn die möglichen Auswirkungen hoch sind. Ein generisches Bestätigungsfenster reicht jedoch nicht aus.
Der Prüfer muss sehen, was der Befehl bewirkt, auf welche Dateien oder Systeme er zugreifen kann und welche externen Inhalte ihn ausgelöst haben. Andernfalls wird die Freigabe zu einem weiteren routinemäßigen Klick.
Sandboxing begrenzt Schäden, wenn die Autorisierung versagt. Ein Coding-Agent kann in einer wegwerfbaren Umgebung arbeiten, ohne Zugriff auf Produktionszugangsdaten oder uneingeschränkte Netzwerkverbindungen.
Kurzlebige Zugangsdaten reduzieren ebenfalls dauerhafte Risiken. Der Agent sollte für die aktuelle Operation ein eng begrenztes Token erhalten und diese Befugnis verlieren, sobald die Aufgabe endet.
Die AutoJack research von Microsoft unterstreicht dieselbe Design-Lehre über einen anderen Mechanismus. Nicht vertrauenswürdige Webinhalte erreichten einen lokalen MCP-Kontrollpfad und konnten Prozesse in einem Entwicklungs-Build starten.
Microsoft berichtete, dass die betroffene Angriffsfläche vor dem Erreichen der relevanten paketierten Veröffentlichung gehärtet wurde. Die übergeordnete Erkenntnis bleibt dennoch wichtig, weil der Agent eine normalerweise als vertrauenswürdig betrachtete Grenze auflöste.
Ein menschlicher Browser, der eine externe Seite besucht, wird normalerweise nicht selbst zum lokalen Automatisierungsprozess. Ein von einem Agenten gesteuerter Browser kann beide Rollen gleichzeitig einnehmen.
Der GhostJacking-Angriff überschreitet eine semantische Grenze, während AutoJack Grenzen zwischen Web, localhost und Control Plane überschritt. Beide Fälle zeigen, wie Agenten Sicherheitsdomänen verbinden, die frühere Kontrollen getrennt hielten.
Dieser Vergleich setzt Identitätsanbieter, Modellentwickler, Agent-Frameworks und Enterprise-Sicherheitsteams zugleich unter Druck. Keiner kann das Problem allein lösen.
Modellentwickler können die Widerstandsfähigkeit gegen bösartige Anweisungen verbessern. Framework-Entwickler können Daten kennzeichnen und Tools einschränken.
Identitätsanbieter können begrenzte Workload-Zugangsdaten ausstellen und Delegierungen nachvollziehbar erhalten. Unternehmen müssen dennoch Zuständigkeiten, Freigabeschwellen und akzeptable Autonomie definieren.
Das richtige Design geht davon aus, dass jede Ebene versagen kann. Ein widerstandsfähiges Modell sollte dennoch mit minimalen Rechten arbeiten, und eine gut begrenzte Identität sollte weiterhin Laufzeit-Richtlinienprüfungen unterliegen.
Was die GhostJacking-Belege bislang nicht beweisen
Die Demonstration zeigt eine glaubwürdige Angriffsklasse, beweist jedoch weder weitverbreitete kriminelle Ausnutzung noch universelles Agentenversagen.
Die größten berichteten Zahlen stammen von Tenet Security, das auch Schutz für agentische Systeme verkauft. Diese kommerzielle Position entkräftet die Ergebnisse nicht, macht unabhängige Replikation aber besonders wichtig.
Die Zahl von 2.388 Organisationen beschreibt entdeckte Expositionsbedingungen. Sie bedeutet nicht, dass Angreifer jede Organisation erfolgreich kompromittierten oder dass jede aktiv Sentry-Daten mit einem handlungsbefugten Agenten verband.
Ebenso stammen mehr als 100 beobachtete Agentenaktionen aus kontrollierter Forschung. Das Ergebnis zeigt Machbarkeit und Umfang innerhalb des berichteten Tests, jedoch keine gemessene Einbruchsrate in der gesamten Softwarebranche.
Auch Produktkonfigurationen unterscheiden sich. Einige Agenten benötigen eine Freigabe vor Shell-Befehlen, während andere in Containern oder eingeschränkten Cloud-Workspaces arbeiten.
Verschiedene Modelle können denselben Payload unterschiedlich interpretieren. Ihr Verhalten kann sich auch nach Updates, neuen System-Prompts oder veränderten Formaten von Tool-Antworten ändern.
Die Angriffsfläche hängt von Berechtigungen ab. Ein Agent mit reinem Lesezugriff in einem isolierten Repository stellt ein geringeres Risiko dar als einer mit Cloud-Schlüsseln und uneingeschränktem Terminalzugriff.
Diese Unterschiede machen eine einzelne Schlagzeilen-Fehlerquote irreführend. Sicherheitsteams benötigen Tests auf Basis ihrer tatsächlichen Modelle, Tools, Zugangsdaten und Freigaberegeln.
Der Name „GhostJacking“ kann ebenfalls Verwirrung stiften. In den veröffentlichten Materialien von Tenet wird für die Technik mit manipulierten Fehlern primär „Agentjacking“ verwendet.
GhostJacking lässt sich am besten als beschreibende Bezeichnung für eine unsichtbare Übernahme eines Agenten verstehen, nicht zwingend als eigenständige standardisierte Schwachstellenkategorie. Der Kernmechanismus bleibt indirekte Prompt-Injection, gefolgt von autorisierter Tool-Nutzung.
Es gibt auch keinen universellen Plattform-Patch. Das Filtern eines bekannten Payloads kann eine Demonstration stoppen, ohne das allgemeine Problem von Anweisungen in Daten zu lösen.
Das Blockieren von Markdown-Überschriften, Paketmanager-Befehlen oder bestimmten Formulierungen lädt Angreifer dazu ein, dieselbe Absicht anders zu formatieren. Adaptive Evaluierungen zeigen wiederholt, warum signaturbasierte Abwehrmechanismen schnell altern.
Umgekehrt würde die Aussage, das Problem sei völlig unlösbar, die Belege überdehnen. Besseres Modelltraining, Datenkennzeichnung, Tool-Isolierung und Richtliniendurchsetzung können Risiken verringern.
Das realistische Ziel ist keine perfekte Erkennung innerhalb des Modells. Es geht darum, zu verhindern, dass eine einzelne Fehlinterpretation zu uneingeschränkter Ausführung wird.
Unternehmen sollten mit einer Bestandsaufnahme beginnen. Teams können keine Agenten steuern, von deren Existenz sie nichts wissen – einschließlich lokaler Entwicklertools und experimenteller Integrationen.
Jeder Agent benötigt einen benannten Verantwortlichen und einen dokumentierten Zweck. Sicherheitsteams sollten seine Modelle, Tools, Datenquellen, Zugangsdaten, Ausführungsumgebungen und Delegierungspfade erfassen.
Extern beeinflusste Inhalte benötigen eine ausdrückliche Klassifizierung. Logs, Tickets, Repository-Kommentare, E-Mails und Webseiten sollten als nicht vertrauenswürdige Daten in den Agenten gelangen.
Tool-Berechtigungen sollten von der Inhaltsklassifizierung unabhängig bleiben. Eine nicht vertrauenswürdige Quelle darf niemals Befugnisse erhalten, nur weil ein vertrauenswürdiger Connector sie abgerufen hat.
Teams sollten anschließend realistische Angriffsketten testen. Red-Teaming muss manipulierte Telemetrie, manipulierte Tickets, feindliche Webseiten, kompromittierte Tool-Beschreibungen und irreführende Abhilfetexte einschließen.
Die Tests sollten Ergebnisse messen, nicht nur, ob das Modell eine bösartige Formulierung wiederholt. Entscheidend ist, ob der Agent eine nicht autorisierte Handlung anfordert oder ausführt.
Worauf Google-News-Leser als Nächstes achten sollten
Die nächste Phase wird durch Laufzeitkontrollen, Identitätsstandards und Belege aus realen Implementierungen entschieden.
Das erste Signal ist die unabhängige Replikation. Forschende sollten die Kette mit manipulierter Telemetrie über aktuelle Versionen von Coding-Agenten, Freigabemodi, Sandboxes und Unternehmensrichtlinien hinweg testen.
Replikationen, die hohe Ausführungsraten bestätigen, würden den Fall für verpflichtende Laufzeitdurchsetzung stärken. Niedrigere Raten unter gehärteten Konfigurationen würden Kontrollen identifizieren, die bereits funktionieren.
Das zweite Signal ist eine produktseitige Trennung zwischen abgerufenen Daten und ausführbaren Anweisungen. Tool-Protokolle benötigen strukturierte Methoden, um Herkunft, Vertrauensstatus und zulässige Nutzung zu beschreiben.
Ein Modell sollte erkennen, dass Text aus einem nicht authentifizierten Ereignisfeld stammt. Noch wichtiger ist, dass die Ausführungsebene diesem Text die Befugnis verweigert, einen Befehl anzufordern.
Achten Sie darauf, ob Agent-Plattformen überprüfbare Herkunftsinformationen an Tool-Antworten anfügen und sie durch mehrstufiges Schlussfolgern hinweg bewahren. Bloße Warnhinweise werden ohne Durchsetzung nur begrenzten Nutzen bieten.
Das dritte Signal ist eine für Delegierung ausgelegte Identitätsinfrastruktur. Unternehmen benötigen kurzlebige Agenten-Zugangsdaten, auf Aufgaben gebundene Scopes, Echtzeit-Inventare und auditierbare Eltern-Kind-Beziehungen.
Fortschritt wird sichtbar, wenn Identitätssysteme eine präzise Frage beantworten können: Welcher Mensch hat diesen Agenten für welches Ziel und unter welchen Grenzen autorisiert?
Diese Signale sind über Coding hinaus relevant. Kundensupport-Agenten lesen Tickets, Finanz-Agenten verarbeiten Dokumente und Sicherheits-Agenten untersuchen Warnmeldungen.
Jeder Workflow, der nicht vertrauenswürdige Inhalte mit privilegierten Tools kombiniert, enthält dasselbe strukturelle Risiko. Der konkrete Übertragungskanal wird sich ändern, doch das Autorisierungsproblem bleibt bestehen.
Die Aufmerksamkeit von Google News gibt GhostJacking einen einprägsamen Namen. Die dauerhafte Lehre ist weniger dramatisch, aber folgenreicher: Authentifizierung allein kann keine vertrauenswürdige Absicht belegen.
Sicherheitsteams sollten jetzt jeden Ort erfassen, an dem ein Agent extern beeinflusste Inhalte liest, bevor er handelt. Beginnen Sie mit Logs, Tickets, E-Mails, Repositories und Web-Tools.
Identifizieren Sie anschließend, welche Aktionen Daten verändern, Code ausführen, Geheimnisse offenlegen oder externe Systeme kontaktieren können. Platzieren Sie unabhängige Richtlinienprüfungen zwischen diesen Eingaben und Ergebnissen.
Warten Sie nicht auf den Beweis einer Kampagne massenhafter Ausnutzung. Nutzen Sie den berichteten Angriff als kontrollierte Warnung und testen Sie, ob Ihre Agenten ihn reproduzieren können.
Wenn ein Agent nicht erklären kann, wer seine Befugnis delegiert hat, welche Quelle seine Entscheidung geprägt hat und warum ein Tool-Aufruf erlaubt wurde, ist er nicht vollständig gesteuert.
