Was passiert, wenn deine KI-gebaute App in Produktion geht

Ein Agent, der schnell funktionierenden Code schreibt, schreibt nicht automatisch Code, der sicher in Produktion läuft – das sind unterschiedliche Fähigkeiten, und die meisten Coding-Agenten heute haben nur die erste. Die Lücke zeigt sich nicht, während die App auf einem Laptop läuft. Sie zeigt sich in dem Moment, in dem sie vom Internet aus erreichbar ist, mit echten Daten dahinter – genau dann, wenn es am schwersten ist, sie zu bemerken.

Wo die Lücke eigentlich liegt

Es ist selten die Anwendungslogik. Es sind die Dinge darum herum, über die ein Agent keinen Grund hat nachzudenken, solange er nicht explizit danach gefragt wird: wo das Datenbank-Passwort liegt, ob ein Deploy-Credential auch die Datenbank löschen kann, ob ein öffentlicher Endpunkt still und leise eine Admin-Route offenlegt, die niemand ausliefern wollte. Nichts davon ist ein Bug im generierten Code – es ist fehlender Kontext über Produktion, der nie Teil des Prompts war.

Was die Plattform übernimmt, anstatt zu hoffen, dass der Agent es getan hat

• Secrets liegen nie im Klartext. env_vars, build_secrets, git_token und registry_password werden verschlüsselt gespeichert (Active-Record-Verschlüsselung, kein nachträglich angeschraubter Zusatz). Eine generierte App, die auf dem naheliegenden Weg ENV["DATABASE_PASSWORD"] liest, erhält denselben Schutz wie eine von Hand geschriebene – die Verschlüsselung ist eine Eigenschaft der Plattform, die den Wert speichert, nicht davon, wie sorgfältig der Code geschrieben wurde.
• Generierte Secrets sind jedes Mal tatsächlich zufällig. Wenn eine App einen SECRET_KEY_BASE oder Ähnliches benötigt, wird er mit SecureRandom erzeugt, nicht als Platzhalter, den ein Agent in einer committeten .env.example zurücklassen und vergessen könnte, zu rotieren.
• Der Zugriff eines Agenten ist abgegrenzt, nicht pauschal. Wenn du Claude Code, Cursor oder einen anderen Agenten die deployte App danach betreiben lässt, gibt Railyards MCP-Server ihm ein Token, abgestuft auf Lesen, Deployen oder Schreiben – nie pauschalen Zugriff –, und die beiden tatsächlich destruktiven Aktionen (eine Variable entfernen, die App löschen) laufen überhaupt nicht von einem Agenten aus. Sie erzeugen eine Freigabe-Anfrage, auf die ein Mensch reagieren muss. Ein Agent mit einem Lese-Token kann physisch nicht dazu gebracht werden, irgendetwas zu deployen, egal was man ihm anweist.

Die Frage, die es wert ist, vor dem Ausliefern gestellt zu werden

Nicht “hat der Agent sicheren Code geschrieben” – das ist der falsche Rahmen, denn “sicher” ist eigentlich keine Eigenschaft von ein paar hundert Zeilen, die an einem Nachmittag geschrieben wurden. Die bessere Frage: Wenn dieser Code etwas Falsches tut, wie groß ist der eigentliche Schadensradius? Ein geleakter DATABASE_URL, den nur diese eine Datenbank nutzen kann, ist ein schlechter Tag. Ein Deploy-Credential, das auch Billing, andere Apps oder ein Provider-Konto berühren kann, ist ein ganz anderer Vorfall. Das ist eine Antwort auf Plattformebene, keine aus Prompt-Engineering.

Was das nicht ersetzt

Nichts davon überprüft die Anwendungslogik selbst – ein Agent kann immer noch eine Route ohne Autorisierungsprüfung generieren, oder ein Formular ohne Eingabevalidierung, und die Plattform hat keine Möglichkeit, das von sich aus als falsch zu erkennen. Verschlüsselte Secrets und abgegrenzte Deploy-Tokens schließen die Fehlerarten auf Infrastrukturebene – sie sind kein Ersatz dafür, tatsächlich zu lesen, was generiert wurde, bevor es live geht.

Vollständige Referenz zum Agentenzugriff: MCP für KI-Agenten.