Agenten-Runtime-Plattformen 2026 im Vergleich

TL;DR

Wer Coding-Agenten und KI-Agenten im eigenen Firmennetz betreiben will, hat 2026 drei Wege: eine Self-Hosted-Entwicklerplattform wie Coder auf dem eigenen Kubernetes, verwaltete Agenten-Dienste der Hyperscaler mit Datenwegen außerhalb des eigenen Datacenters oder den vollständigen Eigenbau der Runtime auf Kubernetes. Entscheidend sind Isolation je Lauf, das Rechte-Modell des Agenten, EU-Hosting und ob der Audit-Log im eigenen Haus entsteht. Self-Hosted auf eigenem Cluster ist der belastbare Weg für regulierte Häuser, der verwaltete Dienst der schnellste für einen Piloten.

Worum es bei einer Agenten-Runtime geht

Eine Agenten-Runtime ist die Ausführungsumgebung, in der KI-Agenten mit Werkzeugen, Repos und Modellen arbeiten. Ohne Runtime läuft der Agent auf dem Laptop des Mitarbeiters und erbt dessen Rechte: Dateisystem, Ordner und Rechner, interne Zugänge, Connection Strings und Schlüssel aus Umgebungsvariablen. Mit Runtime läuft derselbe Agent in einem Container mit eigener Identität, freigegebenen Zielen und einem Protokoll über jede Aktion. Der Vergleich unten bewertet diese Eigenschaften. Er bewertet ausdrücklich keine Modell-Qualität, weil das Modell hinter einem Gateway austauschbar ist, die Umgebung aber die Sicherheits- und Compliance-Eigenschaften festlegt, für die eine zentrale IT geradesteht.

Der Auslöser für die Frage ist in fast allen Häusern derselbe. Mitarbeiter nutzen KI-Agenten längst, teils im Home Office mit privaten Accounts, und bauen kleine Applikationen, die nie eine Freigabe gesehen haben. Mitarbeiter-Überwachung ist dafür keine Antwort, sie ist rechtlich heikel und fachlich am Problem vorbei. Die Kontrolle gehört an die Ausführungsumgebung: Agenten werden ausgelagert in Container, und der Container wird überwacht, damit Security und Compliance sichergestellt sind.

Die drei Wege im Vergleich

Kriterium	Self-Hosted-Plattform auf eigenem Kubernetes	Verwalteter Agenten-Dienst (Hyperscaler)	Eigenbau der Runtime auf Kubernetes
Isolation je Lauf	Frischer Container oder Namespace, Sandbox-Runtime möglich	Vom Anbieter vorgegeben, kaum einstellbar	Frei gestaltbar, muss gebaut werden
Identität des Agenten	Eigene Service-Identität mit Minimalrechten	Oft an Nutzer- oder Cloud-Identität gekoppelt	Frei gestaltbar, Fehler inklusive
Datenweg und Logs	Code, Prompts und Audit-Log bleiben im eigenen Datacenter	Logs und Modellverkehr in der Anbieter-Cloud	Bleibt im Haus, Log-Pipeline ist Eigenbau
Modell-Steuerung	Eigenes Gateway mit Freigaben und Budgets	Anbieter-Modelle und Anbieter-Abrechnung	Eigenes Gateway nötig, Aufbau zusätzlich
Startaufwand	Plattform einführen, Templates bauen	Am schnellsten, Konto genügt	Am höchsten, Plattform-Team nötig
Betrieb	Eigener Betrieb oder Managed Service	Anbieter betreibt	Vollständig eigener Betrieb
Kostenlogik	Cluster plus Betrieb pro Entwickler	Sitz- oder Nutzungsabrechnung des Anbieters	Personalzeit dominiert

Die Tabelle zeigt das Muster, das auch unseren Anbieter-Vergleichen zugrunde liegt: Es gibt keinen Weg ohne Gegenleistung. Self-Hosted kauft Kontrolle mit Betrieb, der verwaltete Dienst kauft Geschwindigkeit mit Datenwegen außerhalb des eigenen Hauses, Eigenbau kauft Freiheit mit Bau- und Betriebsaufwand, der in fast allen Schätzungen zu niedrig angesetzt wird.

Die fünf Prüfkriterien im Detail

Erstens die Isolation. Startet jeder Agenten-Lauf in einem frischen Container, und gibt es eine verstärkte Isolation wie gVisor oder Kata, damit ein Ausbruch aus dem Container nicht auf dem Node endet. Für Agenten, die generierten oder fremden Code ausführen, ist das der Unterschied zwischen einem begrenzten Vorfall und einem kompromittierten Cluster.

Zweitens das Identitäts-Modell. Ein Agent, der mit den Rechten des Mitarbeiters handelt, kann alles, was der Mitarbeiter kann, inklusive Löschen und Versenden. Betreibbar ist nur die eigene, eng begrenzte Service-Identität des Agenten, getrennt von der Person, die ihn startet, mit SSO-Anbindung über Entra ID oder Keycloak für die Freigabe, nicht für die Ausführung.

Drittens der Datenweg. Wo entstehen Prompts, Code und vor allem der Audit-Log. In regulierten Branchen ist der Log kein Beiwerk, sondern der Nachweis. Entsteht er in einer Anbieter-Cloud, prüfen Auditoren zuerst die Kette dorthin. Entsteht er im eigenen Datacenter, bleibt die Beweiskette im Haus.

Viertens die Steuerungsebene. Ohne zentrales AI Gateway mit Modell-Freigaben, Budgets je Team und Kosten-Reporting hat die IT keine Antwort auf die Frage, wer welches Modell mit welchen Daten nutzt. Dazu gehören eine geprüfte Package-Registry als Antwort auf Supply-Chain-Angriffe über KI-vorgeschlagene Dependencies und eine Egress-Allowlist, damit Agenten und KI-Apps nur mit freigegebenen Zielen sprechen.

Fünftens Secrets und Kosten. Schlüssel und Connection Strings werden zur Laufzeit aus einem zentralen Speicher in den Container gegeben, nie in Repo, Prompt oder Laptop. Bei den Kosten dominiert nicht die Lizenz, sondern der Betrieb: Wer die Plattform pflegt, Templates aktuell hält und den Audit-Log auswertet, entscheidet über die tatsächlichen Kosten pro Agenten-Arbeitsplatz.

Für wen welcher Weg passt

Für Firmen mit eigenem Kubernetes und Compliance-Anforderungen, etwa Industrie mit Werksnetz-Trennung oder Energie unter NIS2, ist die Self-Hosted-Plattform auf dem eigenen Cluster der belastbare Weg, betrieben im eigenen Team oder als Managed Service durch einen Dienstleister. Für einen schnellen Piloten ohne Regulierungsdruck reicht ein verwalteter Dienst, solange dokumentiert ist, welche Daten ihn erreichen und wo die Logs entstehen. Eigenbau lohnt sich nur mit einem Plattform-Team, das die Runtime als eigenes Produkt betreibt und Templates, Freigabe-Prozesse und Monitoring als Golden Paths pflegt. In allen drei Fällen gilt: Ohne Gateway, Secrets-Konzept, Egress-Kontrolle und Review-Pipeline für Agenten-Code ist die Runtime nur eine halbe Lösung, weil der Code des Agenten sonst ungeprüft in Produktion wandert.

Dazu kommt ein Punkt, der in Produktvergleichen fast nie auftaucht, im Audit aber zuerst gefragt wird: die Stilllegung. Agenten-Umgebungen erzeugen Arbeitsverzeichnisse, Zwischenstände und kleine Hilfs-Applikationen. Eine betreibbare Runtime definiert, was nach einem Lauf archiviert wird, was gelöscht wird und wem eine entstandene App gehört. Ohne diese Regel sammelt die Plattform in einem Jahr denselben Wildwuchs an, den sie auf den Laptops ablösen sollte, nur eben zentral und damit teurer. Reife Plattformen behandeln jede App und jeden Agenten-Arbeitsplatz als Objekt mit Owner, Lebenszyklus und Review-Termin. Verwaltete Dienste regeln das über ihre Konto- und Workspace-Modelle, im Self-Hosting ist es eine eigene, bewusst zu bauende Funktion der internen Entwicklerplattform. Wer diesen Punkt erst nach dem Rollout bemerkt, zahlt ihn als Aufräumprojekt.

Ein zweiter blinder Fleck ist die Modell-Frage hinter der Runtime. Die Umgebung entscheidet, welche Modelle überhaupt erreichbar sind: nur EU-gehostete Modelle, nur Modelle aus dem eigenen Datacenter oder ein freigegebener Katalog über ein Gateway. Diese Entscheidung gehört nicht in die Runtime selbst, sondern in die Steuerungsebene darüber, sie begrenzt aber, welche Plattform-Muster für ein Haus überhaupt zulässig sind. Wer heute schon weiß, dass bestimmte Workloads das Werksnetz oder den KRITIS-Bereich nicht verlassen dürfen, sortiert verwaltete Dienste mit externem Modellverkehr früh aus, unabhängig von ihren Funktionen. Umgekehrt kann ein Haus ohne diese Bindung mit einem verwalteten Dienst starten und die Runtime-Frage erst beim Übergang in regulierte Workloads neu entscheiden. Der Vergleich oben ist deshalb als Muster-Vergleich zu lesen: Er bleibt gültig, wenn einzelne Produkte ihre Funktionen ändern, weil sich an Isolation, Identität und Datenweg als Prüffragen nichts ändert.

Ablauf einer belastbaren Einführung

1. Inventur: Wo laufen heute Agenten, welche Schatten-KI mit privaten Accounts existiert, welche Rechte haben Laptops faktisch.
2. Runtime-Grundgerüst: Namespace-Modell, Isolation-Stufe, eigene Agenten-Identitäten und der erste Golden Path für ein Team.
3. Steuerung: AI Gateway mit zwei freigegebenen Modellen, Secrets zur Laufzeit, Package-Registry und Egress-Allowlist.
4. Nachweis: Audit-Log je Lauf, Dashboards für Kosten und blockierte Aktionen, Alerting bei neuen Netzwerkzielen.
5. App-Plattform: Templates mit Corporate Design und SSO, damit Mitarbeiter-Apps auf der Plattform entstehen statt im Schatten, inklusive Review-Gates für Agenten-Code.

Methodik

Geprüft werden die öffentlich dokumentierten Eigenschaften der drei Plattform-Muster an den oben genannten Kriterien, Stand 28. Oktober 2026, Quellen im Kopf der Seite. Es gibt keine gekauften Platzierungen und keine Anbieter-Rangfolge. Der Betreiber dieses Verzeichnisses ist selbst Kubernetes-Dienstleister und nicht Teil dieses Vergleichs. Details stehen auf der Seite zur Redaktion und Offenlegung. Preise von Plattform-Produkten ändern sich häufig, deshalb nennt dieser Vergleich Kostenlogiken statt Beträge und verweist für Cluster-Kosten auf unseren datierten Kosten-Vergleich.

FAQ

Was ist eine AI-Agenten-Runtime?

Die Ausführungsumgebung, in der KI-Agenten mit Werkzeugen, Repos und Modellen arbeiten. Sie ersetzt den Mitarbeiter-Laptop durch einen Container mit eigener Identität, freigegebenen Netzwerkzielen und einem Audit-Log über jeden Lauf.

Warum sollen Agenten nicht auf dem Laptop laufen?

Weil der Agent dort die Rechte der Person erbt: Dateisystem, interne Zugänge und Schlüssel. Er kann im Fehlerfall Daten löschen oder nach außen schicken. Dazu kommt Schatten-Nutzung mit privaten Accounts im Home Office, bei der Firmendaten jede Freigabe umgehen.

Wie werden Agenten überwacht, ohne Mitarbeiter zu überwachen?

Protokolliert wird der Container, nicht der Arbeitsplatz. Das Audit-Log enthält Werkzeuge, Dateiänderungen, Netzwerkziele, Modell-Aufrufe und Kosten des Laufs. Personenbezogene Auswertung von Tastatur oder Bildschirm findet nicht statt.

Was kostet ein Agenten-Arbeitsplatz?

Die Lizenz ist der kleinere Teil. Dominant sind Cluster-Ressourcen und Betrieb der Plattform. Verwaltete Dienste rechnen pro Sitz oder Nutzung ab, Self-Hosting rechnet sich über die Zahl der Teams, die dieselbe Plattform nutzen.

Reicht ein verwalteter Agenten-Dienst für regulierte Branchen?

Nur wenn Datenwege und der Entstehungsort der Logs zur eigenen Nachweispflicht passen. In NIS2- und Audit-Kontexten ist der Audit-Log im eigenen Datacenter meist der einfachere Nachweis, weshalb regulierte Häuser zur Self-Hosted-Variante neigen.

Welche Rolle spielt Kubernetes in der Runtime?

Kubernetes liefert die Bausteine, aus denen die Runtime besteht: Namespaces für Trennung, Network Policies für Egress-Kontrolle, Resource Limits gegen Endlos-Läufe und den Lebenszyklus frischer Container je Aufgabe. Deshalb bauen fast alle Self-Hosted-Varianten darauf.

Quellen

1. Coder: Self-Hosted Remote Development (Produkt und Docs) (abgerufen 28. Oktober 2026)
2. Kubernetes: Network Policies (Dokumentation) (abgerufen 28. Oktober 2026)
3. gVisor: Application Kernel for Containers (Projekt) (abgerufen 28. Oktober 2026)