O que acontece quando o app que sua IA construiu chega à produção

Um agente que escreve código funcional rápido não escreve automaticamente código seguro para rodar em produção — são habilidades diferentes, e a maioria dos agentes de código hoje só tem a primeira. A lacuna não aparece enquanto o app está rodando num laptop. Ela aparece no momento em que fica acessível pela internet com dados reais atrás dele, que é exatamente quando é mais difícil de notar.

Onde a lacuna de fato está

Raramente é na lógica da aplicação. São as coisas em volta dela que um agente não tem motivo para considerar a menos que seja explicitamente perguntado: onde a senha do banco de dados vive, se uma credencial de deploy também consegue apagar o banco de dados, se um endpoint público expõe silenciosamente uma rota de admin que ninguém pretendia publicar. Nada disso é um bug no código gerado — é contexto faltando sobre produção que nunca fez parte do prompt.

O que a plataforma trata em vez de esperar que o agente tenha feito

• Segredos nunca ficam em texto puro. env_vars, build_secrets, git_token e registry_password são criptografados em repouso (Active Record encryption, não uma reflexão tardia parafusada depois). Um app gerado que lê ENV["DATABASE_PASSWORD"] do jeito óbvio recebe a mesma proteção que um escrito à mão — a criptografia é uma propriedade da plataforma que guarda o valor, não de quão cuidadosamente o código foi escrito.
• Segredos gerados são de fato aleatórios, toda vez. Quando um app precisa de um SECRET_KEY_BASE ou similar, ele é gerado com SecureRandom, não um placeholder que um agente poderia deixar num .env.example commitado e esquecer de rotacionar.
• O próprio acesso de um agente tem escopo, não é ambiente. Se você está deixando o Claude Code, Cursor, ou qualquer outro agente operar o app depois de implantado, o servidor MCP do Railyard dá a ele um token em camadas de leitura, deploy ou escrita — nunca acesso total — e as duas ações genuinamente destrutivas (remover uma variável, apagar o app) simplesmente não executam a partir de um agente. Elas criam um pedido de aprovação que um humano precisa agir sobre. Um agente com um token de leitura fisicamente não pode ser convencido a fazer deploy de nada, independente do que for instruído a fazer.

A pergunta que vale fazer antes de publicar

Não “o agente escreveu código seguro” — esse é o enquadramento errado, porque “seguro” não é realmente uma propriedade de algumas centenas de linhas escritas numa tarde. A pergunta melhor: se esse código fizer algo errado, qual é o raio de explosão real? Um DATABASE_URL vazado que só aquele banco de dados pode usar é um dia ruim. Uma credencial de deploy que também consegue tocar faturamento, outros apps, ou uma conta de provedor é um tipo de incidente completamente diferente. Essa é uma resposta de nível de plataforma, não de prompt engineering.

O que isso não substitui

Nada disso revisa a lógica da aplicação em si — um agente ainda pode gerar uma rota sem verificação de autorização, ou um formulário sem validação de entrada, e a plataforma não tem como saber que isso está errado por conta própria. Segredos criptografados e tokens de deploy com escopo bloqueiam os modos de falha no nível de infraestrutura; eles não substituem de fato ler o que foi gerado antes de colocar no ar.

Referência completa sobre acesso de agente: MCP for AI agents.