What happens when your AI-built app reaches production

An agent that writes working code fast doesn’t automatically write code that’s safe to run in production — those are different skills, and most coding agents today have only the first one. The gap doesn’t show up while the app is running on a laptop. It shows up the moment it’s reachable from the internet with real data behind it, which is exactly when it’s hardest to notice.

Where the gap actually is

It’s rarely the application logic. It’s the things around it that an agent has no reason to think about unless explicitly asked: where the database password lives, whether a deploy credential can also delete the database, whether a public endpoint quietly exposes an admin route nobody meant to ship. None of that is a bug in the generated code — it’s missing context about production that was never part of the prompt.

What the platform handles instead of hoping the agent did

• Secrets never sit in plaintext. env_vars, build_secrets, git_token and registry_password are encrypted at rest (Active Record encryption, not an afterthought bolted on). A generated app that reads ENV["DATABASE_PASSWORD"] the obvious way gets the same protection as one written by hand — the encryption is a property of the platform storing the value, not of how carefully the code was written.
• Generated secrets are actually random, every time. When an app needs a SECRET_KEY_BASE or similar, it’s generated with SecureRandom, not a placeholder an agent might leave in a committed .env.example and forget to rotate.
• An agent’s own access is scoped, not ambient. If you’re letting Claude Code, Cursor, or any other agent operate the deployed app afterward, Railyard’s MCP server gives it a token tiered to read, deploy, or write — never blanket access — and the two genuinely destructive actions (removing a variable, deleting the app) don’t execute from an agent at all. They create an approval request a human has to act on. An agent with a read token physically cannot be talked into deploying anything, regardless of what it’s instructed to do.

The question worth asking before shipping

Not “did the agent write secure code” — that’s the wrong frame, because “secure” isn’t really a property of a few hundred lines written in an afternoon. The better question: if this code does something wrong, what’s the actual blast radius? A leaked DATABASE_URL that only that one database can use is a bad day. A deploy credential that can also touch billing, other apps, or a provider account is a different kind of incident entirely. That’s a platform-level answer, not a prompt-engineering one.

What this doesn’t replace

None of this reviews the application logic itself — an agent can still generate a route with no authorization check, or a form with no input validation, and the platform has no way to know that’s wrong on its own. Encrypted secrets and scoped deploy tokens close off the infrastructure-level failure modes; they’re not a substitute for actually reading what got generated before it goes live.

Full reference on agent access: MCP for AI agents.