Leitplanken für Agenten

Ein Agent, der über PaaSbox arbeitet, stößt an zwei Stellen an Grenzen: im Portal, das entscheidet, welche Operationen sein Schlüssel anfordern darf, und auf dem Node, wo pbx-agent nur eine feste Liste von Operationen ausführt. Diese Seite listet jede Grenze, was sie verhindert und was nicht, damit du entscheiden kannst, was ein Agent anfassen darf.

Die Leitplanken

Leitplanke	Was sie verhindert	Was sie nicht verhindert	Stand
Ein Schlüssel pro Team, mit Scopes	Aufrufe außerhalb der Scopes des Schlüssels: Ein Agent sieht nur die Tools, die sie erlauben. Aufrufe in ein anderes Team: Dessen Cluster antworten mit „nicht gefunden“.	Ein Scope gilt für jeden Cluster im Team. Einen Schlüssel für nur einen Cluster gibt es nicht: Ein Schlüssel, der einen Testcluster löschen darf, darf auch die Produktion im selben Team löschen.	In Arbeit
Die Rechte der Person, die ihn angelegt hat	Ein Schlüssel tut nie mehr als der Admin, der ihn angelegt hat. Jede Änderung braucht einen Team-Admin.	Ein Schlüssel, den ein Admin angelegt hat, kann innerhalb seiner Scopes, was dieser Admin kann.	In Arbeit
Getippte Bestätigung	Ein Anlegen, Löschen, Abkoppeln oder Wiederherstellen ohne den Namen des Clusters in `confirm`.	Ein Agent, der den Namen kennt, kann ihn tippen. Das Portal prüft den Namen, nicht, ob ein Mensch zugestimmt hat.	In Arbeit
Eine feste Liste von Operationen auf dem Node	Alles auf dem Server, was keine Operationsart von `pbx-agent` ist: Es gibt keinen Kanal für beliebige Befehle, und `pbx-agent` lauscht auf keinem Port. Ein Release, dessen Signatur nicht stimmt, wird abgelehnt.	Was eine Kubeconfig im Cluster erlaubt.	Gebaut im Labor
Kubeconfigs, versiegelt für den Schlüssel des Agenten	Dass das Portal oder jemand dazwischen die Kubeconfig liest. Ein zweites Abholen: Sie wird einmal herausgegeben, an den Schlüssel, der angefragt hat, innerhalb von 5 Minuten.	Die Nutzung der Kubeconfig durch alle, die die entschlüsselte Datei haben, bis sie abläuft (10 Minuten bis 24 Stunden) oder widerrufen wird.	Gebaut im Labor für den Browser; In Arbeit für Schlüssel
Die Firewall auf Port 6443	Eine Kubeconfig, die von einer Adresse außerhalb der erlaubten Bereiche benutzt wird.	Die Nutzung aus den Bereichen heraus.	Gebaut im Labor
Rate-Limits	Mehr als 120 Aufrufe pro Minute und Schlüssel, oder mehr als 20 ändernde.	Ein zerstörerischer Aufruf ist ein Aufruf.	In Arbeit
Das Audit-Log	Nichts: Es hält fest. Jeden MCP-Tool-Aufruf und jeden REST-Aufruf, der etwas ändert oder eine Kubeconfig herausgibt, ohne Geheimnisse; Ablehnungen wegen eines Scopes, einer Rolle oder einer Bestätigung eingeschlossen.	Was im Cluster mit einer Kubeconfig geschieht, steht nicht darin.	In Arbeit

Im Cluster entscheidet die Kubeconfig

Die Leitplanken oben begrenzen die Operationen des Portals: welche Cluster ein Agent anlegen, löschen, wiederherstellen oder abkoppeln darf, welche Snapshots und Upgrades er starten darf, und dass du siehst, was er getan hat. Kubernetes begrenzen sie nicht. Ein Agent mit einer admin-Kubeconfig kann alles, was der Cluster erlaubt: Namespaces löschen, jedes Secret lesen, einen privilegierten Pod mit den Prozessen des Hosts starten. Im Labor vom 2026-10-10 liefen die Host-Befehle für die Messungen genau so, über einen privilegierten Pod und eine Admin-Kubeconfig.

Zwei Secrets in kube-system zählen hier. hcloud hält das Hetzner-Token im Cluster, und ein Hetzner-Token öffnet sein ganzes Projekt, lesend und schreibend. pbx-etcd-s3 hält die Schlüssel deines Buckets, die k3s bei jedem Snapshot liest. Ein Agent mit einer admin-Kubeconfig kann beide lesen.

Die Entscheidungen, die einen Agenten am stärksten begrenzen, fallen also, bevor er anfängt:

Welches Team. Ein Schlüssel reicht an jeden Cluster seines Teams. Halte die Produktion in einem Team, zu dem der Schlüssel eines Agenten nicht gehört, dann erreicht er sie gar nicht.
Welcher Cluster. Gib einem Agenten zum Testen einen Wegwerf-Cluster, der für den Test gebaut ist, nicht den Cluster, der die Produktion trägt. Ein Cluster mit einem Node pro Stage und pro App hält, was ein Agent kaputt macht, an einer Stelle. Warum isolierte Cluster für Agenten.
Welches Projekt. Das Hetzner-Token in einem Cluster öffnet sein Projekt. Ein Projekt, in dem nur Cluster liegen, beschränkt diese Reichweite auf Cluster.
Welche Rolle. Eine view-Kubeconfig nutzt die view-Rolle von Kubernetes: Sie liest Workloads, aber keine Secrets, und sie kann die Nodes nicht auflisten. Fordere admin nur an, wenn der Agent etwas ändern muss.
Welche Scopes. Lass k3s:destructive weg, es sei denn, der Agent legt Cluster an oder löscht sie.

Was PaaSbox einem Agenten nie gibt

Kein Tool und kein Endpunkt gibt das Token deines Hetzner-Projekts, das Token im Cluster, die Schlüssel des Buckets oder das Server-Token des Clusters heraus. Das Audit-Log speichert Argumente mit ersetzten geheimen Werten. Eine Kubeconfig erreicht den Agenten versiegelt für sein eigenes Schlüsselpaar; im Sicherheitsmodell steht, was das Portal hält.

Nicht die Aktionen des App-Katalogs

Agenten, die deine Apps betreiben beschreibt typisierte Aktionen pro App, deklariert im Katalogeintrag einer App und im Labor als MCP-Tools bereitgestellt. Das ist ein anderer Mechanismus, für den Betrieb von Apps. Diese Seite handelt von den Clustern von PaaSbox Clusters.

Einem Agenten Zugriff gebenEin Schlüssel mit nur den Scopes, die er braucht, verbunden über MCP oder REST, und sein Audit-Log.

Warum isolierte Cluster für AgentenWarum die Änderung eines Agenten in einem Cluster getestet wird, der für den Test gebaut ist.