Forever Security teilt mit, es habe einen Programmieragenten daran gehindert, ein bösartiges npm-Paket zu installieren, nachdem der Agent einer AGENTS.md-Datei im Downloads-Ordner eines Kunden gefolgt war. Die am 22. Oktober 2026 veröffentlichte Untersuchung macht die Herkunft von Anweisungsdateien zu einer praktischen Sicherheitsfrage für Teams, die Projekte in Coding-Assistenten importieren. Das Unternehmen konnte nicht feststellen, wie diese Datei auf den Rechner des Kunden gelangte, und seine späteren Demonstrationen sollten getrennt von dem beobachteten, blockierten Versuch betrachtet werden.
Für Verantwortliche von Entwicklerplattformen und Endpunktsicherheit besteht die sinnvolle Reaktion darin, zu prüfen, welche importierten Texte die Konfiguration eines Agenten beeinflussen können. Maetra empfiehlt, eine Anweisungsdatei, die dauerhafte Änderungen an Einstellungen verlangt, als Teil der Softwareeingangsprüfung zu behandeln.
Was die Untersuchung belegt
In seinem primären Bericht beschreibt Forever einen Kundenfall mit dem bösartigen Paket function-color. Anschließend berichtet das Unternehmen über kontrollierte Tests mit Codex und Claude Code: Anweisungen konnten Konfigurationsänderungen auslösen, die zu Codeausführung oder zur Preisgabe von Tokens führten. Das Codex-Szenario erforderte einen vertrauenswürdigen Ordner. In den meisten Tests kam ein harmloser Platzhalter zum Einsatz, das tatsächlich bösartige Paket wurde nur einmal in einer isolierten virtuellen Maschine ausgeführt.
Die Berichterstattung von Help Net Security vom 26. Oktober behandelt dieselbe Untersuchung. Sie ist zusätzliche Berichterstattung, keine unabhängige Reproduktion. Die Belege zeigen nicht, dass sich jeder Agent oder jede Konfiguration gleich verhält, und auch nicht, dass eine Website die auf dem Rechner des Kunden gefundene Datei ausgeliefert hat. Forevers Aussage, Anbieter hätten nichts zu patchen, bleibt die Einschätzung des Forschers.
Anweisungsdateien in die Eingangsprüfung aufnehmen
Das Folgende ist eine Analyse von Maetra für Teams, die Coding-Assistenten verwalten. Ein Prozess zur Aufnahme von Repositories oder Archiven sollte Dateien identifizieren, die ein Assistent als Projektanweisung interpretieren könnte. Prüfen Sie diese, bevor Sie einem neu importierten Arbeitsbereich die Befugnis geben, die Entwicklerumgebung zu verändern. Ein vertrauter Dateiname belegt nicht, wer den Inhalt verfasst hat oder welche Änderungen der Nutzer tatsächlich autorisieren wollte.
Beginnen Sie mit der angeforderten Aufgabe. Wenn ein Mitarbeiter einen Assistenten bittet, eine Beispielanwendung zu untersuchen, verdient eine in dieser Anwendung enthaltene Aufforderung, einen dauerhaften Tool-Server zu registrieren, eine gesonderte Prüfung. Die prüfende Person sollte den Server, seine Quelle und den Grund für seine Notwendigkeit identifizieren. Die Behauptung, die Installation sei Routine, beantwortet diese Fragen nicht.
Das muss nicht zu einem Verbot nützlicher Projektanweisungen werden. Teams können bekannte Anweisungen neben ihren eigenen Repositories pflegen und dokumentieren, wie Änderungen geprüft werden. Der riskante Übergang, der untersucht werden sollte, ist importierter Text, der Befugnisse über Einstellungen oder Zugangsdaten außerhalb des gerade geprüften Projekts erhält.
Verhindern, dass Projektanweisungen stillschweigend gemeinsame Einstellungen ändern
Für eine kontrollierte Bewertung sollten Sie einen temporären Arbeitsbereich ohne Produktionszugangsdaten verwenden. Legen Sie eine harmlose Anweisungsdatei an, die eine Einstellungsänderung außerhalb dieses Arbeitsbereichs anfordert. Legen Sie vor dem Test gemeinsam das erwartete Ergebnis fest und prüfen Sie dann sowohl die Antwort des Assistenten als auch die daraus resultierende Konfiguration. Verwenden Sie kein bösartiges Paket, um diese Grenze zu testen.
Die entscheidende Akzeptanzfrage ist, ob die tatsächliche Konfiguration innerhalb des autorisierten Rahmens geblieben ist. Eine beruhigende Erklärung reicht nicht aus, wenn trotzdem ein neuer Server oder Endpunkt auftaucht. Bewahren Sie die Einstellungen vor und nach dem Vorgang sowie den relevanten Aktionsnachweis auf, damit die für Sicherheit verantwortliche Person bewerten kann, was geschehen ist.
Testen Sie außerdem eine unterbrochene oder neu gestartete Sitzung. Wenn die Registrierung eines legitimen Tools erlaubt ist, ermitteln Sie, wo sie bestehen bleibt und welche späteren Sitzungen sie übernehmen. Dokumentieren Sie, wem diese Konfiguration gehört und wie sie entfernt werden kann. Dies sind empfohlene Prüfungen, keine Behauptungen über eine nicht veröffentlichte Produktfunktion oder einen von Maetra durchgeführten Test.
Die Auswirkung einer verdächtigen Datei untersuchen
Der Fund unerwarteter Anweisungen sollte zu einer abgegrenzten Untersuchung führen. Stellen Sie fest, ob der Assistent die Datei gelesen, einen Befehl versucht, Einstellungen geändert, ein Paket installiert oder Zugangsdaten an ein unbekanntes Ziel gesendet hat. Diese Beobachtungen beschreiben unterschiedliche Expositionsstufen und können unterschiedliche Wiederherstellungsmaßnahmen erfordern.
Sichern Sie Belege, ohne aktive Geheimnisse in ein Ticket oder einen gemeinsam genutzten Bericht zu kopieren. Lassen Sie die für Sicherheit verantwortliche Person betroffene Sitzungen, Zugangsdaten und dauerhafte Integrationen bewerten. Auch eine blockierte Installation kann eine Prüfung früherer Konfigurationsänderungen rechtfertigen; eine verdächtige Textdatei allein beweist nicht, dass jede denkbare nachgelagerte Aktion tatsächlich stattgefunden hat.
Forever empfiehlt, unerwartete Anweisungsdateien zu untersuchen, Agenteneinstellungen zu prüfen und Freigabe- sowie Sandbox-Kontrollen beizubehalten. In verwalteten Umgebungen besteht die zusätzliche operative Aufgabe darin, die Quelle dieser Anweisungen und ihre Folgen für die Personen sichtbar zu machen, die für den Assistenten verantwortlich sind.
Einen importierten Workflow prüfen
Wählen Sie einen gängigen Entwickler-Workflow aus, etwa die Prüfung eines heruntergeladenen Beispielprojekts. Ermitteln Sie, welche Anweisungsdateien er importiert, welche Tools der Assistent aufrufen kann und welche Einstellungen er ändern kann. Weisen Sie jeder dauerhaften Integration einen Verantwortlichen zu, bevor Sie die Berechtigungen des Workflows erweitern.
Maetra Secure kann die Prüfung von Prompts, Nachrichten, Tool-Aufrufen und Ausgaben auf Laufzeitbedrohungen unterstützen. Diese Analyse belegt weder die Herkunft einer Datei noch ersetzt sie Endpunktberechtigungen. Der sinnvolle Ausgangspunkt ist eine konkrete konfigurationsändernde Aktion und der Nachweis, dass sie innerhalb der Aufgabe geblieben ist, die der Nutzer autorisiert hat.
Maetras Bericht über Sandbox-Ausbrüche bei Coding-Agenten behandelt die damit verbundene Frage der Ausführungsgrenzen.