Sichere KI-Agenten mit kagent auf Kubernetes erstellen

Entwickler können nun kagent, ein CNCF-Sandbox-Projekt, auf lokalen Laptops ausführen, um KI-Agenten zu erstellen, die als Kubernetes-Ressourcen operieren. Dieser am 12. Oktober 2026 von Antonio Berben und Felipe Vicens veröffentlichte Leitfaden zeigt, wie man einen Agent-Building-Tool erstellt, das andere Agenten sicher generiert. Der Prozess verlässt sich auf strenge Schutzmechanismen (Guardrails), anstatt dem Large Language Model (LLM) implizit zu vertrauen.

Was passiert ist

Der Artikel beschreibt eine schrittweise Anleitung zum Einrichten eines Agent-Builders unter Verwendung von kagent. Anstatt Agenten als eigenständige Prozesse zu behandeln, definiert kagent sie als Custom Resources in Kubernetes. Dieser Ansatz ermöglicht es einem bestehenden Agenten, YAML-Manifests für neue Agenten zu generieren, wodurch effektiv ein Self-Service-Builder entsteht. Das Setup nutzt Open-Source-Tools wie Docker, kind, kubectl, helm, jq und Ollama, um Kosten minimal zu halten und Cloud-Abhängigkeiten zu vermeiden.

Ein kritischer Teil des Setups umfasst die sichere Konfiguration des Tool-Servers. Standardmäßig könnten kagent-Charts cluster-admin-Rechte gewähren, was selbst für lokale Tests gefährlich ist. Der Leitfaden weist Benutzer an, Berechtigungen so einzuschränken, dass der Builder-Agent nur spezifische Ressourcentypen erstellen kann. Dies stellt sicher, dass die generierten Agenten innerhalb eines definierten Rahmens arbeiten und unbefugter Zugriff auf sensible Cluster-Komponenten wie Secrets oder Deployments verhindert wird.

Die Demonstration führt durch die Installation der erforderlichen Infrastruktur, die Auswahl eines leistungsfähigen lokalen Modells und die Interaktion mit dem Builder über eine Benutzeroberfläche oder API. Das Ziel ist zu zeigen, dass das Erstellen von Agenten keine Magie ist, sondern eine strukturierte Engineering-Aufgabe. Es wird betont, dass die initiale Einrichtung zwar einfach ist, die eigentliche Herausforderung jedoch im Management von Governance und Sicherheit liegt, wenn diese Agenten über eine einzelne Laptop-Umgebung hinaus skalieren.

Wie es funktioniert

Das System stützt sich auf drei unterschiedliche Sicherheitsebenen, die nicht allein vom Prompt abhängen. Erstens beschränkt eine Allowlist, welche Tools das Modell sehen kann. Von zweiundzwanzig verfügbaren Tools greift der Builder nur auf drei zu. Zweitens erfordert ein Human-in-the-Loop-Mechanismus die Genehmigung des Benutzers vor jeder Tool-Ausführung, die den Zustand ändert. Wenn der Agent eine Änderung vorschlägt, pausiert der Lauf, sodass der Benutzer das exakte Manifest prüfen kann, bevor es angewendet wird. Drittens stellt Role-Based Access Control (RBAC) auf Kubernetes-Ebene sicher, dass selbst wenn ein Manifest genehmigt wird, der API-Server jede Aktion ablehnt, die außerhalb der Berechtigungen des Service Accounts liegt.

Der Builder-Agent arbeitet, indem er eine Anfrage in natürlicher Sprache empfängt, beispielsweise die Erstellung eines Agenten für Support-Teams. Er generiert dann ein Kubernetes-Manifest für eine neue Agent-Ressource. Dieses Manifest enthält einen System-Prompt, eine Modellkonfiguration und eine eingeschränkte Menge an Read-only-Tools. Der Builder führt die Erstellung nicht direkt aus; stattdessen gibt er das YAML zur Prüfung aus. Nach der Genehmigung wendet der kagent-Controller das Manifest an und startet einen neuen Pod, der das Agent-to-Agent-(A2A)-Protokoll spricht.

Diese Architektur behandelt Prompts als Anfragen, nicht als Garantien. Die tatsächliche Durchsetzung erfolgt durch die Infrastruktur. Wenn das Modell beispielsweise einen Tool-Namen halluziniert oder versucht, ein Deployment statt eines Agenten zu erstellen, blockieren die Allowlist oder RBAC-Richtlinien die Aktion. Diese Trennung der Zuständigkeiten stellt sicher, dass Fehler in der Modellausgabe nicht zu Sicherheitsverletzungen oder unbeabsichtigten Cluster-Modifikationen führen.

Wichtige Details

• Das empfohlene lokale Modell ist qwen3-coder:30b-a3b, da kleinere Modelle oft scheitern, gültige Kubernetes-Manifests zu generieren.
• Der Builder verwendet eine Allowlist von drei Tools aus den zweiundzwanzig auf dem Server verfügbaren, um seine Fähigkeiten zu begrenzen.
• Für jeden Tool-Aufruf, der den Zustand ändert, ist eine menschliche Genehmigung erforderlich, was einen Kontrollpunkt vor der Ausführung bietet.
• RBAC-Richtlinien beschränken den Service Account des Builders darauf, nur Agent-Ressourcen zu erstellen, und blockieren den Zugriff auf Secrets oder Deployments.
• Das Setup nutzt kind für den Kubernetes-Cluster und Ollama für die lokale Modell-Inferenz, um Kosten zu minimieren.
• Die UI läuft auf localhost via kubectl port-forward, um sicherzustellen, dass sie während des Tests nicht dem öffentlichen Internet ausgesetzt ist.

Warum es wichtig ist

Für Software-Ingenieure und technische Leads verschiebt dieser Ansatz den Fokus vom Prompt-Engineering zum Infrastrukturdesign. Sich ausschließlich auf Prompts für die Sicherheit zu verlassen, ist unzureichend, da Modelle Anweisungen missverstehen oder Tool-Namen halluzinieren können. Indem Sicherheit in die Kubernetes-Schicht eingebettet wird, können Teams Agenten erstellen, die robust gegen Modellfehler sind. Diese Methode bietet eine klare Audit-Trail und erzwingbare Grenzen, die für Produktionsumgebungen unerlässlich sind.

Der Artikel hebt auch die Kluft zwischen lokaler Experimentierung und Enterprise-Governance hervor. Auf einem Laptop scheinen alle Aktionen vom selben Benutzer zu stammen, was es schwierig macht, Kosten oder Besitz nachzuverfolgen. In einer Unternehmensumgebung können mehrere Agenten und Frameworks koexistieren, jeweils mit unterschiedlichen Sicherheitsposturen. Diese Komplexität spricht für eine zentralisierte Governance-Schicht, die Traffic proxyt, Authentifizierung handhabt und Observability über alle Agent-Interaktionen hinweg bereitstellt.

Das Verständnis dieser Mechaniken hilft Entwicklern, über einfache Demos hinauszugehen und zuverlässige Systeme zu bauen. Es demonstriert, dass KI-Agenten in bestehende DevOps-Workflows integriert werden können, wobei vertraute Tools wie YAML und kubectl verwendet werden. Dies senkt die Einstiegshürde für Teams, die bereits in Kubernetes investiert sind, und ermöglicht ihnen, KI zu nutzen, ohne völlig neue operative Paradigmen adoptieren zu müssen.

Was Sie tun können

• Installieren Sie Docker, kind, kubectl, helm, jq und Ollama, um Ihre lokale Umgebung für das Labor vorzubereiten.
• Ziehen Sie das Modell qwen3-coder:30b-a3b mit Ollama, um eine zuverlässige Manifest-Generierung sicherzustellen.
• Erstellen Sie einen kind-Cluster namens kagent-builder und installieren Sie kagent mit eingeschränkten RBAC-Rechten.
• Richten Sie die Allowlist ein, um nur die benötigten Tools freizugeben, und konfigurieren Sie den Human-in-the-Loop-Prozess.
• Testen Sie die Generierung von Agent-Manifests lokal, bevor Sie sie in eine größere Umgebung übernehmen.