KI-Agenten auf Kubernetes im Fokus

7. April 2026

Die Cloud Native Computing Foundation (CNCF) hat in diesem Jahr eine völlig neue, an mehreren Standorten stattfindende Veranstaltung ins Leben gerufen: Der Agentics Day, der sich ganz den KI-Agenten auf Kubernetes widmet. Wenn die CNCF ein eigenes Event für etwas organisiert, bedeutet das nur eines: Das ist kein Experiment mehr, es ist die nächste grundlegende Technologie.

Viele Gespräche auf dem Agentics Day strapazierten nicht die Frage, ob man Agenten auf Kubernetes ausführen sollte – denn das steht zumeist schon fest. Die schwierigen Fragestellungen lauteten dagegen: Wie autorisiert man einen Agenten? Wie gibt man ihm eine stabile Identität? Wie verhindert man, dass er außerhalb seines vorgesehenen Anwendungsbereichs agiert, wenn er Zugriff auf die Produktions-API hat?

Das ist der Blickwinkel, über den die meisten Teams noch nicht gründlich nachgedacht haben. Derzeit setzen Tausende von Unternehmen KI-Agenten auf einer Kubernetes-Infrastruktur ein, die für zustandslose Microservices konzipiert ist. Darum geht es: keine persistente Agentenidentität, keine fein abgestufte RBAC für Agentenaktionen und keine Isolation zwischen Agenten-Tenants. Dieselbe Steuerungsebene, die CI/CD verwaltet, verwaltet nun autonome Systeme, die echte Entscheidungen treffen können. Das erweist sich als ein echtes Problem.

Das MCP (Model Context Protocol) ist das, was einem Standard für die Kommunikation zwischen Agenten und Tools am nächsten kommt. Es wurde im Dezember 2025 der Linux Foundation gespendet und innerhalb eines Jahres nach der Einführung von OpenAI, Google, Microsoft und jeder ernstzunehmenden KI-Plattform übernommen.

Diese Entwicklung ähnelt der von HTTP im Jahr 1995, aber auch HTTP hat weder das Problem der Authentifizierung noch der Autorisierung gelöst. Es hat ein Jahrzehnt gedauert, um OAuth, OIDC und eine ganze Identitätsinfrastruktur darauf aufzubauen.
A

PI-Gateways, Zero-Trust-Netzwerke, Service-Meshes – all das kam erst nach dem Protokoll. Wir befinden uns gerade am „HTTP-Moment“ für Agenten. Die Identitätsschicht existiert noch nicht. Die Teams, die dies als Erste herausfinden, werden nicht diejenigen sein, die den cleversten Agenten bereitgestellt haben. Es werden diejenigen sein, die die Steuerungsebene aufgebaut haben, in der Agenten sicher operieren können.

Die Antwort ist nicht Namespace-RBAC auf einem gemeinsam genutzten Cluster, denn es ist bereits bekannt, dass dieses Muster bei Multi-Tenancy versagt. Es ist die Isolierung von Arbeitsbereichen auf der Ebene der Steuerungsoberfläche: Jeder Agent erhält eine vollständig isolierte API-Oberfläche, deren Umfang genau auf die Ressourcen beschränkt ist, auf die er Zugriff hat.

Nichts anderes ist sichtbar, nichts anderes ist zugänglich. Dieses Architekturmuster existiert bereits für Kubernetes. Bislang hat es aber noch niemand mit dem Problem der Agentenautorisierung in Verbindung gebracht.

Sebastian Scheele ist CEO von Kubermatic.

Kubermatic

Lesen Sie auch