Die Frage kommt in jedem Projekt, in dem ein Agent deployen soll: Wie kommt der Code auf den Server? Die schnelle Antwort ist ein SSH-Schlüssel. Sie ist auch die falsche. Ein Agent mit SSH-Zugang kann alles, was der Benutzer kann – andere Container anfassen, Logs fremder Anwendungen lesen, Host-Pfade einbinden. Nicht, weil er es will, sondern weil nichts ihn daran hindert, wenn ein Prompt missverständlich ist oder eine Anleitung im Netz es so vorschlägt.
Das Prinzip
Wir haben es umgedreht. Jede Applikation auf unserer Hosting-Plattform hat ein eigenes Token. Gespeichert wird nur ein Hash; der Klartext wird genau einmal angezeigt. Wer das Token hat, darf exakt sechs Dinge tun – und sonst nichts:
- Den Stand abfragen: Port, Limits, letzter Deploy
- Die Regeln lesen: was in der Compose-Datei erlaubt ist und was nicht
- Ein Paket hochladen und bauen lassen
- Logs lesen
- Auf den vorherigen Stand zurückrollen
- Die Seite für Suchmaschinen freigeben oder sperren
Kein SSH, kein Zugriff auf den Container des Nachbarn, kein Weg auf den Host. Das Token gilt für eine Applikation, und ein neues macht das alte ungültig.
Was der Host prüft
Least Privilege auf der Zugangsseite reicht nicht, wenn das Paket selbst ausbrechen kann. Deshalb wird jede Compose-Datei vor dem Start gegen feste Regeln geprüft: höchstens sechs Dienste, kein privileged, keine zusätzlichen Capabilities, keine Geräte, kein Host-Netzwerk, Bind-Mounts nur relativ zum Projektordner, genau ein veröffentlichter Port – der eigene. Speicher und CPU sind pro Dienst begrenzt, Logs rotieren. Ein Verstoß führt zur Ablehnung mit Begründung, und die Begründung ist so formuliert, dass der Agent sie versteht und das Paket korrigiert.
Warum Rollback und Logs dazugehören
Ein Agent, der deployen darf, aber nicht sehen kann, was passiert ist, wird raten. Raten ist teuer. Also gehören zwei Dinge zwingend zum Token: Logs und Rollback. Der Ablauf eines Deployments sieht so aus:
- Entpacken und prüfen. Das Paket wird gegen die Regeln gehalten. Ablehnung heißt: nichts wurde angefasst.
- Alten Stand sichern. Der laufende Stand wird gestoppt und als „vorher“ aufbewahrt. Named Volumes bleiben, Datenbankdaten überleben.
- Bauen und starten.
docker compose up -d --build, mit Zeitlimit von zehn Minuten für den Build. - Warten. Bis zu 60 Sekunden, bis der Port mit einem sauberen HTTP-Status antwortet.
- Entscheiden. Antwort da: fertig. Keine Antwort oder Startfehler: automatisch zurück auf „vorher“, und der Agent bekommt die Logs des gescheiterten Versuchs.
Der Agent muss nicht wissen, wie der Rollback funktioniert. Er bekommt eine Antwort, die entweder „läuft“ oder „lief nicht, hier ist warum“ sagt – und kann im zweiten Fall sofort nachbessern.
Was das in der Praxis ändert
Der Kunde gibt seinem Agenten das Token, nicht uns. Er beschreibt, was er will, die KI liest die Regeln vom Server, baut, deployt, liest die Logs, korrigiert. Diese Website ist genau so entstanden: Ein Agent hat das WordPress-Projekt gebaut, hochgeladen, die Logs geprüft und das Versandpostfach eingerichtet. Zu keinem Zeitpunkt hatte er eine Shell. Und wenn beim nächsten Deployment etwas schiefgeht, ist die Seite nach 60 Sekunden wieder auf dem alten Stand – ohne dass jemand nachts aufstehen muss.
Die Regel, die wir daraus in unseren Kodex aufgenommen haben: Ein Agent bekommt den kleinsten Zugang, mit dem die Aufgabe lösbar ist – und immer die Mittel, sein Ergebnis selbst zu prüfen.