Dejar que un agente de IA despliegue tu app, de forma segura
Darle a un agente de código acceso de push a producción suena temerario hasta que miras lo que de verdad necesita hacer en el día a día: revisar si salió un despliegue, leer las últimas 100 líneas de log, reiniciar un proceso atascado, tal vez definir una variable de entorno. La mayoría de eso es solo lectura. La parte pequeña que no lo es debería seguir necesitando que una persona diga que sí.
Esa es la forma sobre la que está construido el servidor de Model Context Protocol de Railyard, no algo añadido después a una API diseñada para otra cosa.
Conectar un agente
Railyard corre un servidor MCP en https://app.railyard.run/api/mcp sobre HTTP con streaming, autenticado con los mismos tokens de API que ya usan la CLI y la API REST. Crea uno en Settings → Team → API tokens, elige read si el agente solo debe poder mirar:
claude mcp add --transport http railyard https://app.railyard.run/api/mcp \
--header "Authorization: Bearer rly_..."Cursor, o cualquier otro cliente MCP que hable HTTP con streaming y pueda enviar un header Authorization, se conecta de la misma forma — apúntalo a la URL, pásale el token.
Qué permite en realidad el token
La lista de herramientas es pequeña a propósito: list_servers, list_apps, get_app y app_logs son de solo lectura. deploy_app, restart_app y set_env necesitan un token de escritura. Esa es toda la superficie para el trabajo diario de un agente — nada sobre servidores, dominios o bases de datos está expuesto aquí; eso todavía pasa por la API REST o la CLI, deliberadamente fuera del alcance del agente por defecto.
El límite de permisos es el token, no un prompt. Un agente con un token de lectura físicamente no puede desplegar nada, sin importar qué se le pida o qué decida por su cuenta — no hay instrucción que convenza a un token de solo lectura de hacer una acción de escritura.
La parte que espera por ti
Dos herramientas — unset_env y delete_app — están marcadas como aprobación, incluso con un token de escritura. Ninguna corre cuando el agente las llama. En su lugar, aparece una solicitud en la página de Approvals del equipo, visible desde el panel, y nada cambia hasta que un admin del equipo la apruebe. Aprobarla corre la acción y registra el resultado; rechazarla simplemente la descarta.
Esta es la línea que importa: un agente puede desplegar tu app, reiniciarla, y ajustar su entorno por su cuenta, porque esas acciones son recuperables — un despliegue malo se revierte, un restart es solo un restart. Eliminar una variable o eliminar una app no es recuperable de la misma forma, así que espera a una persona, siempre, sin importar cómo se haya delimitado el token.
Los despliegues que inicia un agente siguen pasando por la aprobación de despliegue y el límite de tasa ya existentes de la app, igual que un despliegue disparado desde el panel o un git push — el agente no tiene un camino más rápido ni más laxo que el tuyo.
Buenos hábitos, no solo buenos valores por defecto
- Dale a cada agente su propio token con una fecha de vencimiento, y revócalo cuando la tarea termine en vez de dejar una credencial de larga vida en la configuración de un agente.
- Usa por defecto un token de lectura para agentes que sobre todo responden preguntas (“¿por qué este endpoint está lento?”) y entrega escritura solo cuando el trabajo real del agente lo requiera.
- Trata la página de Approvals como un paso de revisión real, no un sello de goma — existe porque
unset_envydelete_appson las dos acciones de esta lista que no puedes deshacer fácilmente.
Referencia completa de herramientas y alcances de token: MCP para agentes de IA.