Deixando um agente de IA fazer deploy da sua aplicação, com segurança

Dar a um agente de código acesso de push em produção parece imprudente até você olhar o que ele realmente precisa fazer no dia a dia: checar se um deploy saiu, ler as últimas 100 linhas de log, reiniciar um processo travado, talvez definir uma variável de ambiente. A maior parte disso é só leitura. A pequena parte que não é ainda deveria exigir que uma pessoa dissesse sim.

É esse o formato em torno do qual o servidor Model Context Protocol da Railyard foi construído, não um acréscimo de última hora numa API que foi desenhada pra outra coisa.

Conectando um agente

A Railyard roda um servidor MCP em https://app.railyard.run/api/mcp sobre streamable HTTP, autenticado com os mesmos tokens de API que o CLI e a API REST já usam. Crie um em Settings → Team → API tokens, escolha read se o agente só precisar olhar:

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

O Cursor, ou qualquer outro cliente MCP que fale streamable HTTP e consiga enviar um header Authorization, se conecta do mesmo jeito — aponte pra URL, passe o token.

O que o token realmente permite

A lista de tools é pequena de propósito: list_servers, list_apps, get_app e app_logs são só leitura. deploy_app, restart_app e set_env precisam de um token de escrita. Essa é toda a superfície pro trabalho do dia a dia de um agente — nada sobre servidores, domínios ou bancos de dados é exposto aqui; isso ainda passa pela API REST ou pelo CLI, deliberadamente fora do alcance do agente por padrão.

O limite de permissão é o token, não um prompt. Um agente com um token de leitura fisicamente não consegue fazer deploy de nada, independente do que for pedido a ele ou do que ele decida por conta própria — não existe instrução que convença um token de somente leitura a fazer uma ação de escrita.

A parte que espera por você

Duas tools — unset_env e delete_app — são marcadas como approval, mesmo num token de escrita. Nenhuma das duas roda quando o agente as chama. Em vez disso, aparece um pedido na página de Approvals da equipe, visível no painel, e nada muda até um admin da equipe aprovar. Aprovar executa a ação e registra o resultado; rejeitar simplesmente descarta o pedido.

Essa é a linha que importa: um agente pode fazer deploy da sua aplicação, reiniciá-la, e ajustar o ambiente dela por conta própria, porque essas ações são recuperáveis — um deploy ruim tem rollback, um restart é só um restart. Remover uma variável ou excluir uma aplicação não é recuperável do mesmo jeito, então isso sempre espera por uma pessoa, independente de como o token foi definido.

Deploys que um agente inicia ainda passam pela aprovação de deploy existente da aplicação e pelo rate limit, igual a um deploy disparado pelo painel ou por um git push — o agente não ganha um caminho mais rápido ou mais solto do que o seu.

Bons hábitos, não só bons padrões

Dê a cada agente o próprio token com uma expiração, e revogue quando a tarefa terminar em vez de deixar uma credencial de longa duração na configuração de um agente.
Use como padrão um token de leitura pra agentes que majoritariamente respondem perguntas (“por que esse endpoint está lento?”) e só dê escrita quando o trabalho real do agente exigir isso.
Trate a página de Approvals como uma etapa de revisão de verdade, não um carimbo automático — ela existe porque unset_env e delete_app são as duas ações dessa lista que você não desfaz facilmente.

Referência completa de tools e escopos de token: MCP para agentes de IA.