Chainguard verlagert Vertrauen vom Prompt in die Maschine

Chainguard hat die eigene Konferenz Assemble London am Mittwoch genutzt, um Sicherheit dorthin zu bringen, wo Coding-Agents arbeiten: Workspaces gibt jedem Agent eine MicroVM ohne langlebige Credentials, Checks macht aus CI ein signiertes Prüfergebnis, Harness setzt Claude Mythos 5.1 auf deine laufende Anwendung an, und MCP ist jetzt allgemein verfügbar. Die Idee dahinter: kontrolliere die Umgebung, nicht den Agenten.

Was hat Chainguard auf der Assemble London angekündigt?#

Chainguard ist für gehärtete Container-Images und OS-Pakete ohne offene CVEs bekannt, und auf der eigenen Konferenz ging es einen Schritt früher in den Lebenszyklus: dorthin, wo Agenten Code schreiben, testen und ausführen. Fünf Ankündigungen, drei davon in Beta:

• Chainguard Workspaces (Beta): eine entfernte MicroVM pro Entwickler und pro Agent. Pakete werden darin installiert, Skripte laufen, Konfigurationen ändern sich, und nichts davon berührt einen Laptop mit SSH-Keys und Cloud-Zugangsdaten. Jede baut auf Chainguards OS-Paketen ohne offene CVEs und wacht aus einem warmen Snapshot in Sekunden auf (Workspaces).
• Chainguard Checks (Beta): CI als schneller Pre-Commit-Check, aufrufbar über die chainctl CLI, einen Git-Hook, die GitHub App, einen MCP-Tool-Call oder ein SDK. Er läuft in einer warmen MicroVM mit aus der Lockfile vorgehaltenen Dependencies und liefert eine signierte Attestation, die Umgebung, Prüfergebnis und Commit-SHA bindet (Checks).
• Chainguard Harness (Beta-Warteliste): richtet Anthropics Claude Mythos 5.1 auf eine laufende Kopie deiner Anwendung, gebaut aus dem Source exakt so, wie er in Production geht, in einer MicroVM ohne Netzwerk-Egress und ohne Credentials (Harness).
• Chainguard MCP (GA): vier Server, die Dependency-Fragen mit verifizierten Daten beantworten. cg-oci prüft, ob ein Image-Tag oder Digest existiert, bevor er in einen Dockerfile landet, cg-apk findet die Chainguard-Äquivalente zu Paketnamen, cg-versions sagt, ob eine Version aktuell oder am Ende ihres Lebens ist, und cg-api liest Organisations-Policy und Entitlements. Funktioniert mit jedem MCP-Client, darunter Claude Code und Cursor, über Standard-OAuth.
• Libraries für Go und .NET (Early Access): gescannte Package-Endpunkte mit konfigurierbarem Cooldown. In der Beta meldete der Scanner bei mehr als 5.000 Go- und .NET-Paketen Schadsoftware, und über 10 Prozent dieser Verdicts hatten zum Zeitpunkt der Entdeckung keine Entsprechung in öffentlichen Quellen. Keins der Pakete hat einen Kunden erreicht.

Workspaces und Checks sind in Beta, die Harness-Warteliste ist offen, und Design-Partner Cuscal, der die Zahlungsinfrastruktur für mehr als 90 Banken, Fintechs und Konzerne betreibt, nutzt Checks seit der Alpha. Der vollständige Rundup steht im Chainguard-Blog.

Agenten erben deinen Zugriff#

Workspaces existiert, weil Agents heute dort arbeiten, wo deine Schlüssel liegen. Im Launch-Release heißt es direkt: Die meisten Agenten haben denselben Zugriff wie der Entwickler, der sie gestartet hat, direkt neben den Credentials, Cloud-Keys und Production-Systemen, und viele Entwickler laufen inzwischen mit einem Dutzend Agenten oder mehr gleichzeitig. Die Kontrollen, zu denen Teams zuerst greifen, Permission Prompts und Allowlists, hängen daran, dass der Agent die Regeln freiwillig befolgt.

Dan Lorenc, CEO und Mitgründer von Chainguard, bringt den Zielkonflikt im Launch-Release auf den Punkt: „Right now teams are choosing between letting agents run next to their production keys or babysitting them through approval prompts all day. Neither one scales.“

Workspaces beantwortet das architektonisch: Echte Credentials leben nie in der VM. Ein host-seitiger Proxy spielt kurzlebige Credentials in ausgehende Requests ein, Tools, die eine Datei brauchen, bekommen einen verschlüsselten Kurzzeit-Stellvertreter, der nutzlos ist, sobald er entwendet wird, und Egress-Policies blocken und protokollieren alles, was die Allowlist nicht abdeckt. The New Stack ergänzt, dass eine Policy die MicroVM bei einem unautorisierten Verbindungsaufbau direkt terminieren kann. Ein Flight Recorder hält jeden Befehl, jede Codeänderung und jeden Netzwerkaufruf in einem manipulationssicheren Protokoll fest. Erreicht ein Agent eine Entscheidung, die er nicht allein treffen sollte, leitet der Workspace die Frage an einen Entwickler weiter und suspendiert in einen Snapshot, ohne während des Wartens Rechenzeit zu verbrauchen.

Checks schließt den Kreis von der anderen Seite. Ein bestandener Lauf erzeugt die signierte Attestation, ein Merge-Gate kann das Ergebnis also verifizieren, ohne die Suite neu zu fahren. Ein fehlgeschlagener Lauf liefert strukturierte Logs, anhand derer der Agent sich korrigiert. Im Workspace beendet der bestandene Verdict den Loop des Agenten. Das ist das Governance-Argument aus der Snyk-Session, die ich diese Woche aufgeschrieben habe, diesmal in Hardware gegossen: Regeln, die auf freiwilliger Befolgung beruhen, scheitern bei Leuten, und bei Agenten scheitern sie genauso.

Harness jagt Schwachstellen mit Reproduktionspflicht#

Die offensive Version dieser Fähigkeit existiert schon. Drei Open-Source-Agent-Frameworks haben seit Juli eine Angriffskampagne gegen Online-Shops gefahren, durchschnittlich 25,46 $ pro abgeschlossenem Scan, und die Rekonstruktion aus dem Staging-Server des Angreifers habe ich im September aufgeschrieben. Harness ist dasselbe Arsenal, nach innen gerichtet und als Dienst verkauft. Du gibst eine Codebasis hinein, Harness baut die Anwendung so, wie Production sie sieht, bootet sie in einer MicroVM ohne Egress und ohne Credentials und lässt Claude Mythos 5.1 nach Logikfehlern, Injection und Resource Exhaustion suchen. Anthropic beschränkt dieses Modell auf Project Glasswing-Teilnehmer, deshalb läuft das Angebot über Chainguard, und über den Claude Marketplace lässt es sich auf bestehende Anthropic-Verpflichtungen anrechnen.

Die Disziplin um die Funde ist der Teil, den ein kleines Team kopieren kann. Exploits werden in frischen MicroVMs so lange abgespielt, bis sie jedes Mal landen. Ein Fix zählt erst, wenn der Exploit gegen den Originalcode läuft und gegen die gepatchte Version scheitert. Ein Chainguard-Ingenieur prüft jeden Bericht, bevor ein Kunde ihn sieht. Der erste öffentliche Fund ist eine vLLM-Schwachstelle, gefixt in v0.31.0 und laut The New Stack unter GHSA-6cxc-2vcg-w5qc erfasst: In früheren Versionen konnte ein Client die Ausgabe erzwingen, die an andere Clients auf derselben Engine zurückging, und die manipulierte Antwort kam als normale Completion daher, ohne einen Eintrag im Protokoll. Genau solche stillen Ausfälle fürchten Multi-Tenant-Backends.

Ob sich das alles durchsetzt, hängt an der Patch-Bereitschaft, und Chainguard hat sich dazu eine Zahl beschafft. Das Unternehmen beauftragte Wakefield Research mit der AI Exploit Gap Umfrage, die 1.300 Security-Leader in neun Märkten befragte: Mehr als die Hälfte gab an, dass ihre Organisationen High- und Critical-Schwachstellen mindestens manchmal wissentlich ungepatcht lassen, bei Firmen ab 1 Milliarde Dollar Umsatz erreicht die Zahl 66 Prozent, unter 250 Millionen Dollar liegt sie bei 27 Prozent (The New Stack).

Ohne Vendor nachbauen#

Kein Stück davon braucht einen Vendor, und alles läuft auf Infrastruktur, die du schon betreibst. In der Reihenfolge, in der ich es anfassen würde:

1. Verlagere die Ausführung von der Maschine mit den Keys. Ein Container oder eine VM ohne SSH-Keys, ohne Cloud-Credentials und ohne Produktionszugriff deckt den Kern dessen ab, was Workspaces verkauft. Docker kann das heute.
2. Blocke Egress standardmäßig und protokolliere, was du erlaubst. Ein prompt-injizierter Agent oder eine kompromittierte Dependency telefoniert genau einmal nach Hause, wenn die Policy den Versuch mitloggt.
3. Injiziere Credentials, speichere sie nie. Kurzlebige Tokens pro Request lassen nichts Wertvolles auf der Platte zurück.
4. Pinne Dependencies an die Lockfile und prüfe sie zur Laufzeit. Ein Paketname, den sich ein Agent ausdenkt, bleibt der billigste Supply-Chain-Angriff überhaupt.
5. Beende den Loop des Agenten erst mit einem verifizierten Ergebnis. Lass die Testsuite entscheiden, wann die Arbeit fertig ist, und halte das Ergebnis im Protokoll fest, damit der Review später darauf vertrauen kann.
6. Zeichne alles auf. Jeder Befehl und jeder Netzwerkaufruf, Diff inklusive. Der Support-Agent auf dieser Seite läuft schon so, in klein: ein skriptbasierter Fallback und ein Trace, den ich nach jedem Gespräch lesen kann.

Workspaces, Checks und Harness sind Betas mit offenen Wartelisten, MCP ist bereits allgemein verfügbar, und jede Behauptung oben ist ein Vendor-Claim, bis Kundenberichte eintreffen. Die Richtung ist trotzdem ablesbar. Die Protokollschicht um die Agenten braucht dieselbe Behandlung: Eine Woche später zeigte der OX-Security-Scan von 15.465 öffentlichen MCP-Servern Tunnel auf Heimrechner und Startbefehle, die wortwörtlich ausgeführt werden. Die Kontrollen, die entschieden, wo Code laufen durfte, sind einen Schritt früher im Lebenszyklus gelandet, von der Pipeline auf die Maschine des Agenten, und ein Team, das das Muster diese Woche von Hand nachbaut, erkennt die Produkte wieder, sobald die Wartelisten sich leeren.