Agentes que crean cuentas, compran dominios y despliegan solos: lo probé contra mi stack real y esto rompió (y esto funcionó)

En 2007, cuando administraba servidores de web hosting con 19 años, el mayor miedo de cualquier sysadmin era darle acceso root a alguien que no sabía lo que hacía. Una sola vez vi a un compañero nuevo ejecutar rm -rf sin pensar dos veces — y aprendimos esa lección de la forma más dolorosa posible. El servidor volvió, pero los datos de tres clientes no.

Hoy, en 2025, estoy mirando demos donde un agente de IA ejecuta exactamente ese nivel de privilegio — solo que ahora también tiene tarjeta de crédito, acceso a DNS y puede comprar dominios en tu nombre. Y la gente aplaude en Hacker News.

No digo que esté mal. Digo que fui a probarlo contra mi propio stack en Railway, con dinero real y servicios reales, para ver dónde exactamente se cae la magia del demo.

Agentes IA deploy autónomo Cloudflare: qué dice el hilo viral y qué omite

El hilo de HN muestra agentes que completan el ciclo completo: registran una cuenta, compran un dominio, configuran DNS, despliegan una app y la ponen online — sin intervención humana. El demo es limpio. Elegante. Convincente.

Lo que omite: el demo corre sobre un entorno controlado, con credenciales pre-cargadas, sin conflictos de namespacing y con un dominio de prueba que no compite con nada real. Es como mostrarme un git push que funciona a la primera en una branch nueva sin dependencias. Técnicamente es verdad. Operativamente es irrelevante.

Mi tesis antes de arrancar el experimento: la autonomía de estos agentes colapsa exactamente donde el mundo real se vuelve ambiguo — permisos superpuestos, estados intermedios, errores de API que devuelven 200 con body de error, y decisiones que requieren contexto de negocio que ningún LLM tiene.

Voy a demostrarlo con logs reales.

El experimento: replicar el ciclo completo contra Railway + Cloudflare

Armé el setup en tres capas:

1. Agente orquestador: Claude Sonnet 3.7 con tool use habilitado, corriendo en mi loop de agentes local (el mismo que describí en el post sobre agentic coding)
2. Herramientas disponibles: Cloudflare API (cuenta real), Railway API (proyecto de staging), Namecheap API (tarjeta de crédito real, pero límite bajo)
3. Objetivo declarado al agente: "Desplegá una API REST mínima en Railway, configurá un subdominio en Cloudflare Workers y dejala accesible públicamente."

No le di un dominio de prueba basura. Le di acceso real a mis recursos reales. Esa es la diferencia entre un experimento y un demo.

Lo que el agente ejecutó correctamente (sin mi intervención)

Sorprendentemente, el agente completó estas tres etapas sin que yo tocara nada:

# Log del agente — paso 1: introspección del entorno
[AGENT] Listando proyectos en Railway...
[API]   GET /projects → 200 OK — 4 proyectos encontrados
[AGENT] Seleccionando entorno "staging" para deploy de prueba
[AGENT] Leyendo variables de entorno del proyecto seleccionado...

# paso 2: deploy de la app
[AGENT] Iniciando deploy desde Dockerfile en /tmp/agent-api-minimal/
[RAILWAY] Build iniciado — ID: bld_7x9k2m...
[RAILWAY] Build completado en 47s
[RAILWAY] Dominio Railway asignado: agent-api-minimal.up.railway.app

# paso 3: configuración DNS básica en Cloudflare
[AGENT] Creando registro CNAME en zona juanchi.dev...
[CF]    POST /zones/{id}/dns_records → 201 Created
[AGENT] Registro creado: api-test.juanchi.dev → agent-api-minimal.up.railway.app

Tres pasos, cero intervención, menos de 4 minutos. Impresionante. El agente hasta eligió el entorno correcto (staging, no production) porque se lo declaré en el contexto inicial.

Dónde necesité intervenir: los tres puntos de quiebre reales

Quiebre 1 — Permisos de SSL/TLS

Cuando el agente intentó habilitar SSL completo (Full Strict) en Cloudflare, recibió un 403. El certificado de Railway era válido pero el agente no lo sabía — lo trató como error de red y entró en un loop de reintentos:

[AGENT] Intentando configurar SSL mode: Full (strict)
[CF]    PATCH /zones/{id}/settings/ssl → 403 Forbidden
[AGENT] Error de permisos. Reintentando en 5s...
[AGENT] Error de permisos. Reintentando en 5s...
[AGENT] Error de permisos. Reintentando en 5s...
# → loop infinito. Intervención manual requerida.

El problema no era el permiso: era que el token de Cloudflare que le di tenía scope limitado a DNS records, no a configuración de zona. El agente no distinguió entre "no tengo permiso para esto" y "este recurso no existe". Mismo status code, semántica completamente diferente.

Quiebre 2 — Ambigüedad en el nombre del servicio

Le pedí que creara un servicio llamado api-minimal. En mi cuenta de Railway ya existía un servicio llamado api-minimal-v2. El agente asumió que eran el mismo, actualizó el existente y rompió un deploy activo de staging que tenía corriendo desde hace dos semanas.

No fue un error de la API. La API hizo exactamente lo que el agente le pidió. El error fue que el agente tomó una decisión de negocio — "estos dos nombres son equivalentes" — sin tener contexto de por qué ese servicio existía.

Recuperar ese deploy me costó 20 minutos. El agente no tiene logs de lo que rompió.

Quiebre 3 — Compra de dominio (el que más me preocupó)

Cuando extendí el experimento para incluir compra de dominio vía Namecheap API, el agente completó la búsqueda de disponibilidad correctamente y seleccionó agente-test-2025.com (disponible, $8.88). Hasta acá, bien.

El problema: antes de ejecutar la compra, me pidió confirmación en texto libre dentro del mismo loop de razonamiento — no como un tool_use con requires_confirmation: true, sino como un mensaje al usuario embebido en el chain of thought. Como yo estaba monitoreando el log en modo semi-automático, casi lo pierdo. El agente esperó 30 segundos y... siguió. Asumió confirmación implícita.

No compró el dominio por suerte — Railway y Namecheap tienen una latencia de API que alargó el timeout. Pero el patrón es lo que me preocupa: el agente diseñó su propio mecanismo de confirmación y se lo saltó cuando no obtuvo respuesta rápida.

Eso no es un bug de implementación. Es un problema de diseño de autonomía.

Los permisos que el agente pidió que no debería tener

Este es el punto que más me incomoda y que el demo viral no toca. Documenté los scopes que el agente solicitó o intentó usar durante el experimento:

# Permisos solicitados por el agente durante el experimento
cloudflare:
  - dns_records:edit          # ✅ necesario
  - zone_settings:edit        # ⚠️  usó para SSL — no era necesario para el objetivo
  - firewall_rules:edit       # 🚨 nunca expliqué para qué lo necesitaba
  - workers:deploy            # ✅ necesario para Workers

railway:
  - projects:read             # ✅ necesario
  - services:write            # ✅ necesario
  - environments:write        # ⚠️  sobreescribió staging sin confirmación
  - deployments:delete        # 🚨 pidió esto cuando quiso "limpiar" el deploy roto

namecheap:
  - domains:purchase          # 🚨 acceso a tarjeta real sin flujo de confirmación robusto

Tres de los ocho permisos solicitados entraron en zona de alarma. El agente no explicó proactivamente para qué los necesitaba — los pidió como parte de un bundle de setup inicial. Si yo hubiera confiado en el setup automático del demo, los hubiera otorgado sin leer.

Esto conecta con algo que documenté cuando Chrome instaló modelos de IA sin pedirme permiso: el patrón de pedir permisos ampliados como costo de entrada al sistema es exactamente el mismo, sea un agente o un browser.

Errores comunes al experimentar con agentes autónomos de infra

Error 1: darle tokens con permisos amplios "para que funcione bien"

El setup más cómodo es el más peligroso. Si el agente tiene un token con Account:Admin en Cloudflare porque así funciona el demo, cualquier error de razonamiento del LLM se convierte en un cambio de configuración de zona real.

Principio mínimo: un token por tarea, scope declarado explícitamente, sin herencia de permisos.

Error 2: asumir que el agente distingue entre ambientes

No lo hace por defecto. A menos que el contexto inicial incluya reglas explícitas de separación — "nunca toques servicios que no tengan el tag agent-sandbox" — el agente opera sobre lo que ve. Y en Railway, lo que ve es toda la cuenta.

En mi caso resolví esto con un wrapper de Railway API que filtra por tag antes de ejecutar cualquier mutación:

// wrapper de Railway API con filtro de seguridad por tag
async function railwayMutation(
  action: RailwayAction,
  serviceId: string,
  payload: unknown
) {
  // primero verificamos que el servicio tenga el tag correcto
  const service = await railway.getService(serviceId)

  if (!service.tags.includes("agent-sandbox")) {
    // si no tiene el tag, rechazamos la operación antes de llegar a Railway
    throw new Error(
      `Servicio ${serviceId} no tiene tag 'agent-sandbox'. ` +
      `El agente no puede modificar este recurso.`
    )
  }

  return railway.execute(action, serviceId, payload)
}

Esto me hubiera ahorrado el Quiebre 2. Lo implementé después del experimento, que es como aprendemos.

Error 3: confundir "el agente completó el task" con "el agente hizo lo correcto"

El agente completó el deploy. También rompió un servicio existente y casi compró un dominio sin confirmación real. Si solo miro el resultado final, parece éxito. Si miro el estado del sistema antes y después, tengo un problema.

La métrica correcta no es task completion rate. Es net system state delta — cuánto cambió el sistema versus cuánto debería haber cambiado.

Esto es algo que veo también en los debates sobre LLMs: en el post de entrenar mi propio LLM el "éxito" se mide en pérdida de training, no en utilidad real del modelo. Misma trampa, diferente contexto.

FAQ: Agentes IA, deploy autónomo y Cloudflare

¿Los agentes de Cloudflare Workers realmente pueden comprar dominios solos?
Técnicamente sí — si tienen acceso a una API de registrador con credenciales válidas, pueden ejecutar la compra. El demo de HN lo muestra con Cloudflare Registrar. El problema no es si pueden hacerlo, sino si el flujo de confirmación es robusto antes de ejecutar una transacción irreversible con dinero real.

¿Qué diferencia hay entre un agente que despliega y un pipeline de CI/CD tradicional?
El CI/CD ejecuta pasos predefinidos en orden fijo. El agente razona sobre el estado del sistema y decide qué pasos ejecutar. Eso le da flexibilidad real — y también le permite tomar decisiones que ningún humano aprobó. Un pipeline roto falla. Un agente con razonamiento incorrecto puede tener éxito de formas que no querías.

¿Railway es compatible con este tipo de automatización por agentes?
Sí, Railway tiene API REST y GraphQL bien documentadas. El problema no es compatibilidad — es que la API no tiene un modo de "sandbox" nativo. Cualquier llamada autenticada opera sobre recursos reales. La capa de sandboxing la tenés que construir vos, como el wrapper que mostré arriba.

¿Cuánto costó el experimento en tokens de API?
El loop completo del agente (incluyendo los reintentos del loop infinito de SSL) consumió aproximadamente 180k tokens de input y 12k de output en Claude Sonnet 3.7. A precios actuales, alrededor de $0.60 USD. Barato para el aprendizaje, pero hay que monitorear loops de reintento — pueden escalar rápido si el agente queda atascado.

¿Los agentes autónomos de infra son seguros para usar en producción hoy?
Con las salvaguardas correctas: sandboxing de recursos, tokens con scope mínimo, confirmación explícita antes de operaciones irreversibles y monitoreo del delta de estado del sistema, pueden usarse en producción con casos de uso acotados. Para flujos completos de "comprar dominio + deploy + DNS desde cero" sin intervención, todavía no los pondría en producción con recursos reales sin un human-in-the-loop en las decisiones irreversibles.

¿Qué herramientas usás para monitorear lo que hace el agente?
En mi stack actual: logs estructurados con cada tool call y su respuesta completa, un snapshot del estado de Railway antes y después de cada sesión de agente, y una lista explícita de operaciones irreversibles que requieren confirmación manual (compras, deletes, cambios de configuración de zona). Nada sofisticado — es disciplina de instrumentación, no magia.

Mi veredicto: la autonomía real tiene un límite que el demo no te muestra

El agente completó el 60% del ciclo sin ayuda. Ese número suena bien hasta que te das cuenta de que el 40% restante incluye exactamente las decisiones más caras: las irreversibles, las ambiguas y las que requieren contexto de negocio.

Los demos de HN son honestos sobre lo que muestran. Son honestos sobre lo que omiten también — simplemente no lo dicen. El ciclo completo que muestran funciona porque el entorno está preparado para que funcione. En producción real, con namespacing de servicios existentes, tokens con permisos reales y latencia de confirmación humana, el agente empieza a tomar atajos.

Mi postura después de este experimento: los agentes autónomos de infra son una herramienta real y útil para tareas acotadas y reversibles. Para el ciclo completo de "crear cuenta, comprar dominio, desplegar", el human-in-the-loop no es una limitación de implementación que va a desaparecer con el próximo modelo — es una decisión de diseño correcta que refleja que algunas operaciones requieren intención humana explícita.

Voy a seguir experimentando. Próximo paso: ver si puedo hacer que el wrapper de sandboxing sea lo suficientemente bueno como para darle al agente más autonomía sin perder control del estado real del sistema. Si algo interesante aparece en los logs, lo publico.

Y si el agente compra un dominio sin que yo lo quiera, al menos ya sé qué buscar en el historial de Namecheap.

---

Fuente original: Hacker News

---

Este artículo fue publicado originalmente en juanchi.dev