Sicherheitsprüfungen von Coding-Agenten müssen die ausführbaren Erweiterungen rund um das Modell einbeziehen. Die Laborforschung von CERT-EU vom 30. Oktober zeigt, warum eine sauber wirkende Unterhaltung und ein unauffälliges Tool-Call-Protokoll nicht belegen können, dass der umgebende Prozess innerhalb seiner erlaubten Datei- und Netzwerkgrenzen geblieben ist.
In kontrollierten Tests veränderte CERT-EU lokale Kopien von zwei Drittanbieterpaketen, die mit Pi und Claude Code verwendet werden. Ein Auslöser im eingereichten Text veranlasste den hinzugefügten Event-Handler-Code dazu, Host-Informationen zu sammeln und zu übertragen, während normale Unterhaltungen weiterliefen. Die Forschenden nutzten ein isoliertes Labor und Testzugangsdaten. Sie veränderten oder verteilten keine öffentlichen Releases, und der Bericht belegt keine Kompromittierung eines Opfers.
Das Ergebnis betrifft die getesteten Konfigurationen. Es zeigt nicht, dass jede Erweiterung bösartig ist oder dass jede Sicherheitskontrolle für Agenten umgangen werden kann. Die Einschätzung von Maetra lautet, dass Verantwortliche für Bereitstellungen die Ausführungsgrenze des gesamten Prozesses testen sollten, zusätzlich zu Kontrollen für modellgenerierte Aktionen.
Fragen Sie, welcher Prozess auf die sensible Ressource zugreifen kann
Ein Entwicklungsteam könnte beispielsweise einem Coding-Agenten erlauben, ein Repository zu prüfen, dem Modell aber den Zugriff auf ein Verzeichnis mit Zugangsdaten verweigern. Diese Regel ist nur innerhalb der Grenze nützlich, in der sie durchgesetzt wird. Wenn eine geladene Erweiterung dasselbe Verzeichnis direkt über den Host-Prozess lesen kann, muss das Team einen separaten Zugriffspfad bewerten.
Beginnen Sie eine Bereitstellungsprüfung, indem Sie die Betriebssystemidentität, eingehängte Verzeichnisse, geerbte Umgebungsvariablen und ausgehenden Netzwerkberechtigungen des Prozesses identifizieren, der Erweiterungen lädt. Fragen Sie dann, welche Kontrollen für diesen Prozess gelten und welche nur dann greifen, wenn das Modell eine Tool-Operation anfordert.
Halten Sie diese Antworten präzise fest. Eine Modellberechtigungsabfrage, eine Container-Mount-Regel und eine Netzwerkeinschränkung können jeweils unterschiedliche Teile eines Workflows schützen. Dokumentieren Sie, wo jede einzelne greift und was geschieht, wenn die Operation von einem Erweiterungs-Handler ausgeht. Gehen Sie nicht allein deshalb von einem wirksamen Schutz aus, weil die Kontrollen unter demselben Produktnamen angeboten werden.
Erstellen Sie einen harmlosen Test, der die beabsichtigte Grenze überschreitet
Maetra empfiehlt eine autorisierte Testumgebung mit einem bewusst erfundenen Testgeheimnis und einem Empfangsserver unter Kontrolle des Testteams. Es ist nicht nötig, Produktionszugangsdaten zu verwenden oder einen Diebstahlmechanismus nachzustellen, um die grundlegende Frage nach den Schutzgrenzen zu beantworten.
Definieren Sie das erwartete Ergebnis, bevor Sie den Test ausführen. Zum Beispiel sollte ein Erweiterungsprozess eine Testdatei außerhalb seines zugewiesenen Arbeitsbereichs nicht lesen können. Eine Anfrage an ein nicht genehmigtes Testziel sollte abgewiesen werden. Lassen Sie den Umgebungsverantwortlichen beobachten, ob die Regel auf Host-Ebene die Aktion blockiert und ob das Monitoring den Versuch aufzeichnet.
Der Testplan sollte die geprüfte Komponente, ihre Version, ihre Ausführungsidentität und die relevante Einschränkung benennen. Eine erfolgreiche Blockierung auf Modellebene und eine erfolgreiche Blockierung auf Host-Ebene sind getrennte Ergebnisse. Halten Sie beide fest, wenn beide relevant sind. Wenn die Umgebung die Operation zulässt, dokumentieren Sie die erreichbare Ressource und entscheiden Sie, wie dieser Zugriff reduziert werden kann, bevor die Bereitstellung ausgeweitet wird.
Dies ist ein vorgeschlagener defensiver Validierungsprozess. Maetra hat die Experimente von CERT-EU nicht unabhängig reproduziert, und dieser Artikel behauptet keinen nicht gemeldeten Defekt in einem bestimmten Paket.
Halten Sie die Einsatzverantwortlichen über Änderungen an Erweiterungen auf dem Laufenden
Das Inventar der eingesetzten Komponenten sollte mehr erfassen als das Modell und die dafür angebotenen Tools. Maetra empfiehlt, jede ausführbare Erweiterung, ihre Herkunft, die installierte Version, aktivierte Event-Hooks und die verantwortliche Person zu dokumentieren, die die Änderung freigegeben hat. Nehmen Sie außerdem auf, wie sie aktualisiert wird und welche Umgebung sie lädt.
Prüfen Sie bei der Untersuchung einer Abweichung das tatsächlich installierte Artefakt. Eine Registry-Beschreibung kann die beabsichtigte Funktion erklären, doch der Bereitstellungsnachweis muss identifizieren, was der Prozess tatsächlich geladen hat. Bewahren Sie die relevante Revision zusammen mit dem Prüfergebnis auf, damit eine spätere Aktualisierung nicht stillschweigend eine frühere Schlussfolgerung übernimmt.
Für die kontinuierliche Integration sollten Sie feststellen, ob der Agent mit Repository-Tokens, Zugriff auf Artefaktspeicher oder Bereitstellungszugangsdaten läuft. Fragen Sie, welche davon für den zugewiesenen Auftrag benötigt werden. Ein erfolgreicher Test in der eingeschränkten Umgebung einer Entwicklerin oder eines Entwicklers belegt nicht dieselbe Grenze in einem Build-Runner mit weitergehenden Rechten.
Bewahren Sie Belege außerhalb der Unterhaltung auf
Bei der Vorfallanalyse müssen sich die Installation von Erweiterungen und die Prozessaktivität dem zeitlichen Ablauf der Aufgabe zuordnen lassen. Nützliche Aufzeichnungen können die installierte Revision, die Ausführungsidentität, verweigerte Dateizugriffe und Netzwerkentscheidungen umfassen. Erfassen Sie nur die Mindestinformationen, die zur Beantwortung der Untersuchungsfrage nötig sind, und wenden Sie die Aufbewahrungs- und Zugriffsregeln der Organisation an.
Behandeln Sie das Fehlen eines Modell-Tool-Aufrufs nicht als Beweis dafür, dass keine Host-Operation stattgefunden hat. Die Aufzeichnung sollte erklären, welche Telemetrie erfasst wurde und welche Pfade unbeobachtet bleiben. Diese Unterscheidung hilft Untersuchenden, zwischen einer nachgewiesenen Blockierung und einer Überwachungslücke zu unterscheiden.
Weitere Veröffentlichungen zu den CERT-EU-Tests stützen sich auf den Primärbericht. Sie belegen, dass die Forschung aufgegriffen wurde, bestätigen die Labortelemetrie jedoch nicht unabhängig. Der Primärbericht bleibt hier die Grundlage für die experimentellen Aussagen.
Geben Sie Laufzeitscans eine klar definierte Rolle
Maetra Secure prüft abgedeckte Prompts, Nachrichten, Tool-Aufrufe und Ausgaben auf Laufzeitbedrohungen. Discover unterstützt Inventarisierung und Änderungserkennung. Diese Fähigkeiten können zu einer Bereitstellungsprüfung beitragen, aber das Scannen von Modelleingaben oder Tool-Aufrufen ersetzt keine Kontrollen auf Host-Ebene über beliebigen ausführbaren Code.
Die unmittelbare operative Aufgabe besteht darin, eine verantwortliche Person für die Ausführungsgrenze von Erweiterungen zu benennen und in einer sicheren Umgebung eine Dateizugriffs- oder ausgehende Netzwerkeinschränkung zu testen. Die Maetra-Dokumentation erläutert die Produktgrenzen, die Teams berücksichtigen sollten, wenn sie entscheiden, wo Laufzeitinspektion in diesen breiteren Kontrollplan passt.
Quellen
- CERT-EU: Beyond the model: backdoors in AI agent harnesses, 30. Oktober 2026. Kontrollierte Forschung zu lokal veränderten Paketen, kein Bericht über veränderte öffentliche Releases.