Einen KI-Agenten deine App deployen lassen, sicher

Einem Coding-Agenten Push-Zugriff auf Produktion zu geben klingt riskant, bis man sich ansieht, was er im Alltag tatsächlich braucht: prüfen, ob ein Deploy rausgegangen ist, die letzten 100 Logzeilen lesen, einen hängenden Prozess neu starten, vielleicht eine Umgebungsvariable setzen. Das meiste davon ist read-only. Der kleine Teil, der es nicht ist, sollte trotzdem ein Ja von einem Menschen brauchen.

Genau so ist Railyards Model Context Protocol-Server aufgebaut, nicht als nachträglicher Anbau an eine API, die für etwas anderes entworfen wurde.

Einen Agenten verbinden

Railyard betreibt einen MCP-Server unter https://app.railyard.run/api/mcp über streamable HTTP, authentifiziert mit denselben API-Tokens, die CLI und REST-API bereits nutzen. Erstelle einen unter Settings → Team → API tokens, wähle read, wenn der Agent nur zuschauen soll:

claude mcp add --transport http railyard https://app.railyard.run/api/mcp \
  --header "Authorization: Bearer rly_..."

Cursor oder jeder andere MCP-Client, der streamable HTTP spricht und einen Authorization-Header senden kann, verbindet sich genauso – URL eintragen, Token übergeben.

Was der Token tatsächlich erlaubt

Die Tool-Liste ist absichtlich klein: list_servers, list_apps, get_app und app_logs sind read-only. deploy_app, restart_app und set_env brauchen einen Write-Token. Das ist die gesamte Oberfläche für die tägliche Agenten-Arbeit – nichts zu Servern, Domains oder Datenbanken wird hier exponiert; das läuft weiterhin über die REST-API oder die CLI, standardmäßig bewusst außerhalb der Reichweite des Agenten.

Die Berechtigungsgrenze ist der Token, nicht ein Prompt. Ein Agent mit einem Read-Token kann physisch nichts deployen, egal was man ihn bittet oder was er selbst entscheidet – es gibt keine Instruktion, die einen Read-Token zu einer Write-Aktion überredet.

Der Teil, der auf dich wartet

Zwei Tools – unset_env und delete_app – sind als approval markiert, selbst bei einem Write-Token. Keines läuft, wenn der Agent sie aufruft. Statt dessen erscheint eine Anfrage auf der Approvals-Seite des Teams, sichtbar vom Dashboard aus, und nichts ändert sich, bis ein Team-Admin zustimmt. Zustimmen führt die Aktion aus und protokolliert das Ergebnis; Ablehnen verwirft sie einfach.

Das ist die Grenze, die zählt: Ein Agent kann deine App deployen, neu starten und ihre Umgebung anpassen, ganz allein, weil das reversibel ist – ein schlechtes Deploy wird zurückgerollt, ein Neustart ist nur ein Neustart. Eine Variable entfernen oder eine App löschen ist nicht auf dieselbe Art reversibel, also wartet es auf einen Menschen, jedes Mal, egal wie der Token gescoped war.

Deploys, die ein Agent anstößt, laufen weiterhin über die bestehende Deploy-Approval und das Rate Limit der App, genau wie ein Deploy vom Dashboard oder einem git push – der Agent bekommt keinen schnelleren oder lockereren Weg als du.

Gute Gewohnheiten, nicht nur gute Standardeinstellungen

• Gib jedem Agenten seinen eigenen Token mit Ablaufdatum, und widerrufe ihn, wenn die Aufgabe erledigt ist, statt ein langlebiges Credential in der Konfiguration eines Agenten liegen zu lassen.
• Standardmäßig einen Read-Token für Agenten, die hauptsächlich Fragen beantworten (“warum ist dieser Endpoint langsam?”), und Write nur dann vergeben, wenn der eigentliche Job des Agenten es erfordert.
• Behandle die Approvals-Seite als echten Review-Schritt, nicht als Abnick-Formalität – sie existiert, weil unset_env und delete_app die zwei Aktionen auf dieser Liste sind, die sich nicht einfach rückgängig machen lassen.

Vollständige Tool-Referenz und Token-Scopes: MCP für KI-Agenten.