Qué pasa cuando tu app construida con IA llega a producción

Un agente que escribe código funcional rápido no escribe automáticamente código seguro para correr en producción —son habilidades distintas, y la mayoría de los agentes de código hoy solo tienen la primera. La brecha no se nota mientras la app corre en una laptop. Se nota en el momento en que es alcanzable desde internet con datos reales detrás, que es justo cuando es más difícil de notar.

Dónde está realmente la brecha

Casi nunca es la lógica de la aplicación. Son las cosas alrededor de ella sobre las que un agente no tiene razón para pensar a menos que se le pida explícitamente: dónde vive la contraseña de la base de datos, si una credencial de despliegue también puede borrar la base de datos, si un endpoint público expone en silencio una ruta de admin que nadie pensaba publicar. Nada de eso es un bug en el código generado —es contexto faltante sobre producción que nunca formó parte del prompt.

Lo que la plataforma maneja en vez de confiar en que el agente lo hizo

• Los secretos nunca están en texto plano. env_vars, build_secrets, git_token y registry_password están cifrados en reposo (cifrado de Active Record, no algo agregado después como parche). Una app generada que lee ENV["DATABASE_PASSWORD"] de la forma obvia recibe la misma protección que una escrita a mano —el cifrado es una propiedad de cómo la plataforma almacena el valor, no de cuán cuidadoso fue el código.
• Los secretos generados son realmente aleatorios, cada vez. Cuando una app necesita un SECRET_KEY_BASE o algo similar, se genera con SecureRandom, no con un placeholder que un agente podría dejar en un .env.example versionado y olvidarse de rotar.
• El acceso propio de un agente está acotado, no es ambiental. Si dejas que Claude Code, Cursor o cualquier otro agente opere la app desplegada después, el servidor MCP de Railyard le da un token con nivel de lectura, deploy o escritura —nunca acceso general— y las dos acciones genuinamente destructivas (eliminar una variable, eliminar la app) no se ejecutan desde un agente en absoluto. Crean una solicitud de aprobación sobre la que una persona tiene que actuar. Un agente con un token de solo lectura físicamente no puede ser convencido de desplegar nada, sin importar lo que se le indique.

La pregunta que vale la pena hacerse antes de publicar

No “¿el agente escribió código seguro?” —ese es el marco equivocado, porque “seguro” no es realmente una propiedad de unas cuantas líneas escritas en una tarde. La pregunta mejor: si este código hace algo mal, ¿cuál es el radio de impacto real? Un DATABASE_URL filtrado que solo esa base de datos puede usar es un mal día. Una credencial de despliegue que también puede tocar la facturación, otras apps o una cuenta de proveedor es un tipo de incidente completamente distinto. Esa es una respuesta a nivel de plataforma, no de ingeniería de prompts.

Lo que esto no reemplaza

Nada de esto revisa la lógica de la aplicación en sí —un agente todavía puede generar una ruta sin comprobación de autorización, o un formulario sin validación de entrada, y la plataforma no tiene forma de saber que eso está mal por su cuenta. Los secretos cifrados y los tokens de despliegue acotados cierran los modos de falla a nivel de infraestructura; no sustituyen leer de verdad lo que se generó antes de publicarlo.

Referencia completa sobre acceso de agentes: MCP para agentes de IA.