Cloudflare protege Quick Tunnels con email y sin cuenta

El problema clásico de los túneles temporales: cualquiera con el link entra

Cloudflare lanzó Quick Tunnels en 2021 con una promesa simple: un solo comando y tu localhost ya tiene una URL pública en trycloudflare.com. Sin cuenta, sin dominio, sin coste. El problema siempre fue el mismo: cualquiera con el enlace podía abrirlo. Ahora, con cloudflared 2026.9.3, llega Protected Quick Tunnels: añade --allowed-mail y solo acceden las direcciones de email o dominios que tú elijas. Cloudflare Access envía un PIN de un solo uso al visitante para verificar la identidad; la autorización (¿está esta persona en tu lista?) la decide cloudflared en tu propia máquina. Sin cuenta de Cloudflare en ninguno de los dos lados.

Por qué importa ahora: los agentes de IA adoptaron los Quick Tunnels

Cualquier agente que escribe código necesita mostrar el resultado en algún sitio. Los agentes que viven en un Mac mini en casa necesitan ser alcanzables desde el móvil. Los servidores Model Context Protocol (MCP) que corren en tu portátil necesitan un endpoint público antes de que un asistente alojado pueda llamarlos. Todos necesitan una URL, y un Quick Tunnel la produce con un solo comando que un agente puede ejecutar por sí mismo, sin formularios de registro que lo atasquen. Con --output json, además, cada línea de log se convierte en un objeto JSON que el agente puede parsear sin scrapear texto.

La adopción explotó: el 18 de septiembre de 2026, un enlace a la página de Quick Tunnels trepó al top de Hacker News con más de 800 puntos y 300 comentarios. El hilo parecía un catálogo de workflows de agentes: la IA de uno había encontrado Quick Tunnels por su cuenta para publicar el sitio que acababa de construir; otro los llamó «insanely helpful when doing agentic work on the go». Y alguien lanzó exactamente la pregunta que este anuncio responde: ¿cuánto falta para que el agente de alguien monte un túnel y deje a la vista del mundo tu app más sensible o tu trabajo a medio terminar?

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Cómo funciona `--allowed-mail` en la práctica

Pasar un email al flag es todo lo que hay que hacer:

cloudflared tunnel --url http://localhost:8080 \
  --allowed-mail [email protected]

Alice abre la URL, escribe su email, recibe el PIN en su bandeja y llega a tu app. Cualquier otra persona se queda fuera antes de que un solo request toque tu máquina. Para dejar entrar a más gente, repite el flag o permite un dominio entero:

cloudflared tunnel --url http://localhost:8080 \
  --allowed-mail [email protected] \
  --allowed-mail [email protected] \
  --allowed-mail '*@example.com'

Si omites --allowed-mail, nada cambia: los Quick Tunnels públicos siguen comportándose como siempre. Para cambiar la lista, detén cloudflared y arranca un túnel nuevo: el acceso de todos termina en el momento en que el proceso muere.

Conviértelo en el default de tu agente

Como la protección es un solo flag, los agentes pueden adoptarlo tan fácil como una persona. Añade una línea al archivo de instrucciones que lee tu coding agent, por ejemplo AGENTS.md:

When you start a Quick Tunnel, always add --allowed-mail [email protected].

A partir de ahí, las previews que comparta tu agente solo abrirán para ti. Los agentes no siempre siguen instrucciones, así que conviene verificar qué ejecutaron: cloudflared imprime si el túnel usa autenticación por email y cuántas reglas tiene, sin imprimir las direcciones.

Desde Wrangler, el mismo flujo para developers de Workers

Si construyes sobre Workers, puedes arrancar el mismo tipo de túnel desde la última versión de Wrangler:

npx wrangler tunnel quick-start http://localhost:8080 \
  --allowed-mail [email protected]

Wrangler soporta flags repetidos, valores separados por coma y dominios wildcard, y elimina los valores de --allowed-mail de sus logs de debug.

La arquitectura detrás del diseño: ¿dónde vive la policy si no hay cuenta?

Separar dos preguntas fue el núcleo del diseño. La autenticación prueba quién es el visitante; la autorización decide si ese visitante entra. Cloudflare Access verifica que el visitante controla la dirección de email. Un pequeño authentication broker corriendo sobre Cloudflare Workers convierte esa identidad verificada en un handoff firmado de corta duración. El broker es stateless por diseño: no guarda políticas de túneles, ni sesiones, ni registros de identidad, y nunca ve la guest list del túnel. cloudflared verifica el handoff y toma la decisión de autorización en memoria, contra las reglas que tú escribiste.

El resultado es la propiedad que más importaba: tu guest list nunca sale de tu máquina. Cloudflare aprende que un túnel requiere autenticación por email; no aprende a quién invitaste.

El equipo partió de cuatro requisitos: mantener Quick Tunnels sin cuenta (un signup derrotaría el propósito de un túnel de un solo comando), no tocar el path de requests de los Quick Tunnels públicos, evitar un lookup central de política en cada request tras el login, y proteger la privacidad de los emails que el developer escribe en su terminal. Probaron dos ideas antes de llegar a la arquitectura final: poner una aplicación de Cloudflare Access delante de cada hostname (imposible a escala: cientos de miles de túneles vivos a la vez, muchos por minutos, cada uno con su propia app y policy) y construir el flujo entero dentro de cloudflared (buena idea para autorización, mala para autenticación: enviar el código es la parte fácil; lo difícil es entregar el email, evitar abuso, manejar sesiones y mantener un sign-in traducido durante años).

Anatomía de un request a un Protected Quick Tunnel

El primer acceso recorre cinco pasos:

cloudflared ve un request sin sesión y redirige al navegador a login.trycloudflare.com con un state aleatorio de un solo uso ligado a ese navegador y válido 10 minutos.
Cloudflare Access envía un PIN de un solo uso al email del visitante y lo verifica.
El broker comprueba la identidad de Access y devuelve una aserción firmada de corta duración, ligada al hostname del túnel y a ese state. El navegador la entrega en un POST, así que nunca aparece en la URL, el historial ni los logs.
cloudflared verifica la aserción, consume el state y compara el email con tus reglas. Si coincide, crea una sesión local y envía al visitante a la página pedida. Si no, recibe una respuesta genérica que no revela nada sobre la lista.
Los requests posteriores usan esa sesión hasta cuatro horas (menos si la sesión de Access expira antes), o hasta que detengas cloudflared. No hay lookup central ni servicio de políticas.

La cookie de sesión guarda un valor aleatorio y un timestamp de expiración, sin datos sobre quién es el visitante. cloudflared elimina las credenciales de autenticación antes de reenviar requests, así que tu app nunca las ve y nunca tiene que implementar un login. Si cualquier check falla, el request nunca llega a tu servicio local. Un túnel protegido nunca cae en modo público.

El contexto: Cloudflare y los agentes de IA como hilo conductor

Protected Quick Tunnels no llega solo. El 3 de junio de 2026, Cloudflare abrió OAuth auto-gestionado a todos los developers tras una migración zero-downtime de su motor Ory Hydra, con el mismo motor que usa OpenAI; los servidores MCP de Cloudflare ya corren sobre OAuth 2.1, según reportó TechTimes. En septiembre de 2026, Cloudflare añadió scopes opcionales en el consent screen, para que un usuario pueda deseleccionar permisos individuales en lugar de aprobar o rechazar todo de golpe; según InfoQ, la empresa reportó más de un millón de autorizaciones acumuladas desde junio en miles de apps OAuth de terceros. Y en agosto, según Ars Technica, Cloudflare open-sourceó Cloudflare OS, su plataforma interna de vibe-coding basada en sandboxes de V8 isolates (100x más rápidas y 10-100x más eficientes en memoria que un contenedor estándar), construida originalmente para que empleados no técnicos crearan apps con agentes de IA.

El patrón es claro: cada pieza de infraestructura de Cloudflare que tocaba un developer account-based se está adaptando a un mundo donde un agente actúa en nombre de un usuario sin pasar por un signup humano.

Qué significa esto para tu startup

Si tu equipo ya usa coding agents (Claude Code, Cursor, Codex, Aider, Continue o cualquier wrapper interno) para iterar sobre features, la pregunta de seguridad dejó de ser teórica. Hasta hoy, el workflow estándar era: el agente levanta un preview en trycloudflare.com y tú lo abres en el móvil para validar. Si esa preview toca datos reales — un panel de admin, un endpoint con tokens de Stripe, una API interna sin auth — cualquiera que vea el link o lo publique por error el propio agente entra antes que tú.

Acciones concretas que puedes tomar hoy:

Pega --allowed-mail [email protected] en tu AGENTS.md, CLAUDE.md o el archivo de instrucciones de tu coding agent. Es una línea y bloquea la exposición accidental por defecto. Verifica qué comando ejecutó el agente con cloudflared antes de abrir el link en un dispositivo con datos sensibles.
Usa *@tu-dominio.com para dar acceso a todo tu equipo sin enumerar direcciones. Y combina con túneles efímeros por sesión: el acceso muere cuando matas el proceso, así que el blast radius queda contenido al demo de esa tarde.
Si construyes sobre Workers, migra a npx wrangler tunnel quick-start y pasa los flags por variables de entorno; Wrangler ya elimina los valores de --allowed-mail de los logs de debug, algo clave si compartes el output en CI o con un LLM-as-judge que evalúa el run.

Para founders que venden infra a developers, la lección es más amplia: el modelo de «link mágico público» se acabó para cualquier preview que toque código real. Productos como Vercel Previews, Railway, Render o Fly ya trabajan con auth por defecto; Quick Tunnels acaba de cerrar la única puerta que faltaba en el flujo agentic.