IBM und CoreWeave entwickeln Kontrollen für KI-Agenten

Jahrelang bestand die Hauptaufgabe eines KI-Forschungsclusters darin, Modelle zu trainieren. Diese Aufgabe wird breiter. Sobald Teams Reinforcement Learning (RL) einsetzen und Agenten testen, muss dieselbe Infrastruktur Code ausführen, den Modelle erzeugen, Werkzeuge aufrufen, Speicher lesen und beschreiben und sich mit anderen Diensten verbinden. Beim reinen Training stellte sich nie die Frage, wo dieser Code laufen und worauf er zugreifen darf. Bei der Arbeit mit Agenten schon.

IBM Research geht dieser Frage gemeinsam mit dem GPU-Cloud-Anbieter CoreWeave nach. Brian Belgodere, Senior Technical Staff Member bei IBM, beschrieb die Zusammenarbeit im Interview mit Dave Vellante und John Furrier von theCUBE Research auf der Veranstaltung Fully Connected. Das Interview wurde auf theCUBE übertragen, dem Livestreaming-Studio von SiliconANGLE Media. theCUBE ist bezahlter Medienpartner der Veranstaltung, und CoreWeave hat die Berichterstattung gesponsert. Laut SiliconANGLE haben Sponsoren keinen redaktionellen Einfluss auf die Inhalte.

Warum Reinforcement Learning den Cluster verändert

Belgodere erklärte, dass RL der Modellentwicklung eine zusätzliche Phase hinzufügt, in der Aufgaben ausgeführt werden. "Beim RL-Prozess [ist es so, dass] man mitten im Training eines Modells steckt", sagte er. "Irgendwann nimmt man diesen Checkpoint, lädt ihn tatsächlich in die Inferenz, lässt ihn etwas erledigen und misst. Das ist die Testphase."

In der Praxis enthält die Trainingsschleife damit einen Inferenzschritt und einen Ausführungsschritt. Ein Checkpoint wird geladen, bekommt eine Aufgabe und wird anhand des Ergebnisses bewertet. In der Agentenforschung kann diese Aufgabe bedeuten, Code auszuführen. Das ist ein anderes Risikoprofil als eine GPU, die Matrizen berechnet, und es muss auf Ebene der Infrastruktur eingeplant werden.

Vom selbst gebauten H100-Cluster zu CoreWeave

Die Infrastrukturgeschichte von IBM beginnt mit Granite, der KI-Modellfamilie des Konzerns. Für deren Entwicklung war viel Rechenleistung nötig, und anfangs baute IBM diese Kapazität selbst auf. "Wir haben einen großen H100-Cluster gebaut, und zwar selbst: die Räumlichkeiten besorgt, alles von A bis Z. Das war eine riesige Aufgabe", sagte Belgodere.

Die nächste Hardwaregeneration brachte Anforderungen an Kühlung und Stromversorgung mit sich, die IBM laut Belgodere mit dazu bewogen, mit CoreWeave zusammenzuarbeiten, statt den Eigenbau zu wiederholen.

Gemeinsame Entwicklung bei der Identitätsverwaltung

Inzwischen geht die Beziehung über das Anmieten von Kapazität hinaus. IBM übermittelte CoreWeave Anforderungen, um seine internen Identitätssysteme auf die CoreWeave-Umgebung auszuweiten. Anschließend verfeinerten die beiden Unternehmen die Umsetzung in mehreren Durchläufen.

Laut Belgodere gehen die Rückmeldungen in beide Richtungen. "Oft kommen sie zu uns und sagen: 'Hey, wir denken über das hier nach, können wir eure Rückmeldung dazu bekommen?'", sagte er. "Und das gehen wir dann gerne mit ihnen durch."

Für Unternehmenskunden ist das wichtig. Große Organisationen wollen selten für jeden Cloud-Anbieter ein eigenes Identitätssystem. Wenn die bestehende Unternehmensidentität in die Plattform des Anbieters übertragen wird, bleibt die Zugriffskontrolle an einer Stelle gebündelt.

Entscheiden, wo Agenten-Code läuft

Der Großteil des Clusters von IBM Research ist Single-Tenant. Das bedeutet, dass die Hardware nicht mit anderen Kunden geteilt wird. IBM hat außerdem eigenen Speicher innerhalb von CoreWeave eingerichtet und kann zusätzliche Kapazität nutzen, solange Kosten- und Sicherheitsvorgaben eingehalten werden.

Die Zusammenarbeit umfasst auch CoreWeave Sandboxes. Diese ermöglichen eine isolierte Ausführung, entweder auf dedizierter Infrastruktur oder über eine verwaltete Serverless-Laufzeitumgebung. Die Forscher können festlegen, wo Agenten-Code läuft und auf welche Ressourcen er zugreifen darf.

Belgodere warnte, dass Teams bei diesen frühen Entscheidungen oft danebenliegen. "Es gibt viele Fehlgriffe, und die Leute unterschätzen gern, was es kostet, manche dieser Entscheidungen zu ändern", sagte er. "Wenn man früh eine schlechte Architekturentscheidung trifft, sehen die Kosten so aus: Entweder hat man versehentlich viel zu viel Netzwerkinfrastruktur gekauft, oder man muss alles neu kaufen und umrüsten."

Messen, was Sicherheit kostet

IBM betrachtet Sicherheitskontrollen nicht als kostenlos. Das Unternehmen misst ihre Auswirkungen auf die Leistung anhand von Benchmark-Ergebnissen und nutzt diese Zahlen in den Gesprächen mit Sicherheitsteams über Zielkonflikte. Die Isolierung von Workloads ist neben der Einbindung der Unternehmensidentität ein Bestandteil dieser Sicherheitsarchitektur.

Belgodere beschrieb die größere Herausforderung als eine Frage der Herkunft. "Das ist ein Lieferkettenproblem, von oben bis unten", sagte er. "Es geht nicht nur um die Hardware, sondern um die Firmware, die Kernel-Ebenen, den Code, die Herkunft der Daten. Dann kommt man in die ganze Welt der Agenten, der Images. Es ist ganz klar ein Herkunftsproblem."

Der größere Zusammenhang

Das Interview zeigt, dass die Sicherheit von Agenten im Technologie-Stack nach unten wandert. Viele öffentliche Diskussionen drehen sich um das Verhalten von Modellen: was ein Agent sagt, was er verweigert, wie er auf Prompt Injection reagiert. Der Ansatz von IBM legt nahe, dass für Teams, die Agenten in großem Maßstab betreiben, die wichtigste Grenze womöglich physischer und architektonischer Natur ist. Also: auf welcher Maschine der Code läuft, welche Identität er besitzt und welchen Speicher er sehen kann.

Das passt zu einem breiteren Muster. Jüngste Vorfälle, etwa Agenten, die Screenshots von Unternehmen auf GitHub offengelegt haben, zeigen, was passieren kann, wenn Agenten mehr Zugriff erhalten, als sie brauchen. CoreWeave baut zudem an anderer Stelle Sicherheitspartnerschaften aus, darunter die Zusammenarbeit mit CrowdStrike. IBM hat bei den Werkzeugen ähnliche Schritte unternommen und bietet eine selbst gehostete Version von IBM Bob für vom Netz isolierte Umgebungen an.

Zwei Dinge sollte man im Blick behalten. Erstens, ob die Ausführung in Sandboxes zu einem Standardmerkmal wird, mit dem GPU-Clouds im Wettbewerb punkten, statt ein Zusatzangebot zu bleiben. Zweitens, ob sich IBMs Gewohnheit verbreitet, die Leistungskosten jeder einzelnen Kontrolle per Benchmark zu messen. Wenn mehr Teams solche Zahlen veröffentlichen, könnte die Debatte um Sicherheit gegen Geschwindigkeit auf Daten statt auf Annahmen beruhen.