Chainguard startet Workspaces und Checks, um KI-Coding-Agenten abzusichern

Ein KI-Coding-Agent kann eine nützliche Fehlerbehebung schreiben und dabei trotzdem einen Sicherheitsvorfall verursachen. Er könnte eine kompromittierte Abhängigkeit installieren, Anweisungen in nicht vertrauenswürdigen Inhalten befolgen oder einen Befehl mit Zugangsdaten ausführen, die ihm weit mehr Zugriff gewähren, als die Aufgabe erfordert. Wenn Teams immer mehr Agenten parallel einsetzen, ist die Absicherung des von ihnen erzeugten Codes nur ein Teil des Problems.

Chainguard begegnet dieser umfassenderen Angriffsfläche mit drei Ankündigungen bei Assemble London: Workspaces, isolierte Umgebungen für Entwickler und Coding-Agenten; Checks, eine Prüf-Engine, die innerhalb des Entwicklungszyklus eines Agenten ausgeführt werden soll; und erweiterte Schutzmaßnahmen für Libraries, die zusätzliche Programmiersprachen und die Behebung von Schwachstellen abdecken.

Die Produkteinführungen verknüpfen drei Fragen, die sich Unternehmen zunehmend stellen müssen: Wo wird ein Agent ausgeführt, wie wird seine Arbeit überprüft und welche externe Software kann er in die Organisation einbringen? Workspaces und Checks starten in der Beta, während die neuen Libraries-Angebote für Go und .NET in den Early Access gehen.

Eine Sicherheitsgrenze für jeden Coding-Agenten schaffen

Chainguard Workspaces stellt jedem Entwickler und Agenten eine eigene Remote-Mikro-VM bereit. Die Umgebung synchronisiert den lokalen Arbeitsbaum des Entwicklers, sodass dieser seinen Editor und Git-Workflow beibehalten kann, während die Ausführung außerhalb seines Rechners stattfindet. Getrennte Umgebungen ermöglichen es außerdem mehreren Agenten, parallel Änderungen auszuprobieren, ohne dieselbe Arbeitsumgebung gemeinsam zu nutzen.

Diese Unterscheidung ist wichtig, denn die nützlichen Fähigkeiten eines Agenten – Befehle auszuführen, Pakete zu installieren und auf Dienste zuzugreifen – können zugleich mögliche Einfallstore für eine Kompromittierung sein. Eine in den Anweisungen eines Agenten festgelegte Richtlinie setzt voraus, dass der Agent sie befolgt. Eine von der Ausführungsumgebung durchgesetzte Grenze kann dagegen einschränken, was geschieht, selbst wenn das Modell eine schlechte Entscheidung trifft.

Laut der Mitteilung werden echte Zugangsdaten außerhalb des Workspace eingebunden. Tools, die Zugangsdaten auf dem Datenträger benötigen, erhalten stattdessen einen verschlüsselten Ersatz mit kurzer Gültigkeitsdauer. Optionale Richtlinien für ausgehenden Datenverkehr beschränken Verbindungen auf genehmigte Ziele und verringern so die Möglichkeit, dass eine kompromittierte Abhängigkeit oder ein durch Prompt-Injection manipulierter Agent Daten an andere Stellen sendet.

Diese Schutzmaßnahmen wirken unterschiedlichen Risiken entgegen. Die Hardware-Isolierung trennt Arbeitslasten; die Vermittlung von Zugangsdaten hält wiederverwendbare Geheimnisse außer Reichweite des Agenten; und Netzwerkrichtlinien schränken ein, mit welchen Stellen er kommunizieren kann. Ihre Wirksamkeit hängt weiterhin davon ab, welche Berechtigungen und Ziele eine Organisation genehmigt. Durch Isolierung wird nicht jede autorisierte Aktion harmlos.

Die Umgebungen verwenden Chainguard OS Packages und überprüfen Abhängigkeiten zur Laufzeit anhand der Lockdatei. Das bestehende Angebot an OS Packages von Chainguard umfasst kontinuierlich gepflegte Pakete, die aus dem Quellcode erstellt werden und Software-Stücklisten enthalten. Dieser Hintergrund erklärt den Ansatz des Unternehmens: Es erweitert seine kontrollierte Softwarebasis auf den Ort, an dem Agenten ausgeführt werden.

Workspaces erstellt außerdem signierte Aufzeichnungen zur Umgebung, zu Codeänderungen und zu Prüfergebnissen. Für Sicherheitsteams bietet dies eine Möglichkeit, zu untersuchen, was ein Agent getan hat, statt sich allein auf dessen eigene Zusammenfassung der Sitzung zu verlassen.

Verifizierung in den Arbeitszyklus des Agenten integrieren

Code lässt sich schnell generieren, doch bis verifizierter Code vorliegt, kann es dauern. Ein Agent nimmt eine Änderung vor und übermittelt sie an die kontinuierliche Integration. Dann wartet er, bis ein Runner eingerichtet ist, und erhält schließlich eine Fehlermeldung, nachdem sich sein Arbeitskontext bereits geändert hat. Wiederholt sich dieser Prozess bei vielen Agenten, können sich Warteschlangen verlängern und Einrichtungsarbeiten doppeln.

Chainguard Checks integriert die Verifizierung als Tool-Aufruf in diesen Arbeitszyklus. In Verbindung mit Workspaces wird die Agentensitzung während der Prüfungen angehalten und anschließend mit strukturierten Fehlerprotokollen im Kontext fortgesetzt. Der vorgesehene Ablauf ist iterativ: eine Änderung vornehmen, Prüfungen ausführen, den Fehler untersuchen und es erneut versuchen, bevor das Ergebnis übergeben wird.

Vorgewärmte Snapshots enthalten vorinstallierte Abhängigkeiten und werden neu erstellt, wenn sich die Lockdatei ändert. Jeder Workflow-Schritt wird in einer eigenen, hardwareisolierten Mikro-VM ausgeführt. In der Mitteilung werden außerdem das Einfügen kurzlebiger Zugangsdaten in ausgehende Anfragen auf Host-Seite sowie deklarative Richtlinien für den Netzwerkzugriff beschrieben.

Bei einem erfolgreichen Durchlauf wird eine signierte Attestierung erstellt, die Umgebung, Testergebnis und Commit miteinander verknüpft. Nachgelagerte Merge-Schranken können diese Nachweise überprüfen und das Ergebnis akzeptieren, ohne dieselbe Testsuite erneut auszuführen, so Chainguard.

Das ist ein nützlicher Unterschied: Nachweise zu übermitteln ist etwas anderes, als lediglich die Behauptung eines Agenten weiterzugeben, die Tests seien bestanden. Eine Attestierung kann belegen, welche Prüfungen für welchen Commit in welcher Umgebung ausgeführt wurden. Sie kann nicht belegen, dass die Tests jedes wichtige Verhalten abdeckten oder dass eine bestandene Änderung alle Sicherheitsanforderungen erfüllt. Teams benötigen weiterhin geeignete Tests, vertrauenswürdige Prüfungsrichtlinien und Überprüfungen, wo menschliches Urteilsvermögen gefragt ist.

Chainguard zufolge liefert das Design Ergebnisse innerhalb von Sekunden und verringert redundanten Rechenaufwand. Die Unterlagen zur Produkteinführung enthalten jedoch keine unabhängig bestätigte Benchmark-Analyse, die für alle Repositories eine allgemeine Verbesserung von Geschwindigkeit oder Kosten belegt.

Die von Agenten eingebundenen Abhängigkeiten absichern

Die dritte Ankündigung erweitert Chainguard Libraries, den verwalteten Katalog mit Endpunkten für Open-Source-Sprachabhängigkeiten. Der bestehende Dienst ist darauf ausgelegt, sich in Artefaktmanager und Entwicklungsabläufe einzufügen. Für von Chainguard erstellte Pakete bietet er Herkunftsnachweise und signierte Software-Stücklisten.

Der neue Go-Endpunkt umfasst Scans auf Malware und Grauzonensoftware, konfigurierbare Paketregeln und die Behebung von CVEs. Der .NET-Endpunkt bietet mit Scan- und Regelkontrollen eine Alternative zum direkten Bezug von NuGet-Paketen. Beide gehen in den Early Access.

Chainguard ergänzt außerdem die Behebung von CVEs für JavaScript und Go, einschließlich rückportierter Korrekturen für Schwachstellen mit kritischem und hohem Schweregrad. Rückportierungen sind wichtig, wenn ein Team nicht sofort auf eine neuere Hauptversion umsteigen kann, ohne Änderungen an der Anwendung vorzunehmen oder umfangreiche Tests durchzuführen. Sie können das Risiko verringern, während das größere Upgrade geplant wird.

Für Java und Python erklärt das Unternehmen, dass Athena, seine Branchenkoalition, bereinigte Artefakte für Schwachstellen bereitstellen wird, die von Spitzen-KI-Modellen entdeckt werden – und zwar an dem Tag, an dem diese Schwachstellen öffentlich bekannt werden. Diese Aussage bezieht sich auf die Reaktion zum Zeitpunkt der öffentlichen Bekanntgabe und ist keine Garantie dafür, dass keine unentdeckten Schwachstellen existieren.

Eine Umfrage zeigt, warum das Patchen allein zunehmend unter Druck gerät

Parallel zu den Produkten veröffentlicht Chainguard The AI Exploit Gap, eine bei Wakefield Research in Auftrag gegebene Umfrage. Im September 2026 wurden dafür Antworten von 1.300 Cybersicherheitsverantwortlichen aus neun Märkten erhoben. Die Befragten hatten mindestens die Position eines Direktors inne und arbeiteten in der Regel in Unternehmen mit mindestens 500 Beschäftigten; in Singapur und den Vereinigten Arabischen Emiraten/Saudi-Arabien lag die Mindestzahl bei 250 Beschäftigten.

In der Umfrage gaben 54 % an, dass ihre Unternehmen wissentlich zumindest gelegentlich Schwachstellen mit hohem oder kritischem Schweregrad ungepatcht lassen. 93 % äußerten die Sorge, KI-gesteuerte Exploits nicht schnell genug beheben zu können. 76 % berichteten von einem bestätigten oder vermuteten KI-gesteuerten Angriff im vorangegangenen Jahr.

Die letzte Zahl umfasst sowohl bestätigte Vorfälle als auch bloße Vermutungen. Sie sollte nicht als unabhängig verifizierte Messgröße für durch KI verursachte Angriffe verstanden werden. Allgemeiner gesagt handelt es sich dabei um Berichte und Einschätzungen der Befragten, nicht um Telemetriedaten, die belegen, wie häufig eine bestimmte Angriffstechnik erfolgreich ist.

Die Ergebnisse zum operativen Alltag sind aufschlussreich. Bei Unternehmen mit einem Umsatz von mindestens 1 Milliarde US-Dollar gaben 66 % an, dass sie zumindest gelegentlich Schwachstellen mit hohem oder kritischem Schweregrad ungepatcht lassen. Bei Unternehmen mit einem Umsatz von weniger als 250 Millionen US-Dollar waren es dagegen 27 %. Größere Unternehmen verwiesen auf geschäftliche Abwägungen, etwa auf mögliche Betriebsstörungen und konkurrierende Produktprioritäten. Die Unterschiede betreffen also nicht nur die Fähigkeit, Schwachstellen aufzudecken, sondern auch die Fähigkeit, Änderungen umzusetzen.

Mehr Autonomie erfordert besser überprüfbare Kontrolle

Chainguards drei Markteinführungen bilden einen stimmigen Ansatz: die Ausführungsumgebung einschränken, Agenten eine schnelle und nachvollziehbare Verifizierung ermöglichen und die von ihnen verwendeten Abhängigkeiten kontrollieren. Jede Maßnahme setzt an einem anderen Teil desselben Entwicklungsablaufs an.

In der Praxis wird sich zeigen, ob sich diese Kontrollen in reale Repositories, Dienstintegrationen und Release-Richtlinien einfügen lassen, ohne zu einem weiteren Engpass zu werden. Durch den Beta- und Early-Access-Status steht diese Arbeit noch aus. Die Richtung ist jedoch klar: Wenn Coding-Agenten zunehmend eigenständig handeln können, brauchen Unternehmen Sicherheitskontrollen, die während des gesamten Arbeitsprozesses durchsetzbar und überprüfbar bleiben.