Cloudflare Blog desde operaciones

Destacado

Cloudflare añade soporte WebMCP y cobertura total de API a su navegador para agentes de IA

Cloudflare actualizó Kitesurf, su navegador basado en Workers para agentes de IA, sumando soporte WebMCP para que los sitios expongan funciones invocables en lugar de exigir simulación de clics, además de mayor cobertura de estándares web (más de 730.000 subtests WPT) y acceso completo a la Browser Run API vía CDP, Playwright, Puppeteer o MCP. Esto hace la navegación automatizada por agentes más fiable y económica.

Qué cambia en operaciones — Para una empresa B2B de 10 a 200 personas que construye o compra agentes que necesitan extraer datos de sitios web, completar formularios o monitorear páginas de competidores, esto importa porque WebMCP permite que un agente invoque una función expuesta por el sitio (como searchFlights()) en lugar de adivinar píxeles y elementos del DOM, reduciendo las tasas de fallo en flujos de scraping frágiles. Kitesurf ahora también funciona con herramientas estándar (Playwright, Puppeteer, MCP), de modo que un equipo de operaciones o ingeniería que ya use esos frameworks para automatización interna puede sustituir el backend del navegador por Kitesurf sin reescribir scripts, y es gratuito durante la beta de Cloudflare sujeto a límites por cuenta — vale la pena probarlo antes de comprometerse con un proveedor de navegador headless de pago para flujos de agentes.

Cloudflare permite bloquear el entrenamiento de IA sin perder visibilidad en buscadores de IA

Para una empresa B2B de 10 a 200 empleados, esto es una palanca directa sobre la generación de leads a través de la búsqueda con IA. Los compradores investigan cada vez más a los proveedores mediante ChatGPT, Perplexity y AI Overviews en lugar de hacer clic en enlaces azules, por lo que ser recuperable y citable en esas respuestas importa para el pipeline. Hasta ahora, bloquear rastreadores de IA para proteger contenido propietario (páginas de precios, casos de estudio, documentación técnica) también arriesgaba desaparecer por completo de las respuestas generadas por IA. Con esta señal, un operador puede indicarle a los rastreadores: indexen y citen nuestro contenido, pero no lo usen para entrenar. Los equipos de marketing y RevOps deberían actualizar robots.txt para declarar esta política explícitamente en lugar de depender del comportamiento predeterminado de los rastreadores, y auditar qué bots de IA (de OpenAI, Anthropic, Google, Perplexity) realmente la respetan, ya que el cumplimiento es voluntario.

Cloudflare convierte a Python en lenguaje de primera clase para agentes de IA en su red edge

La mayoría de las empresas B2B de 10 a 200 personas no tocará esto directamente, pero los equipos y agencias que construyen sus bots de soporte con IA a medida, búsqueda RAG interna o asistentes basados en MCP sí lo notarán: Hyperdrive ahora permite que un Python Worker consulte directamente la base de datos PostgreSQL o MySQL existente de la empresa, y el soporte nativo de langchain/openai significa que un proveedor de automatización puede levantar un agente de IA de cara al cliente o un asistente de conocimiento interno sin mantener un servidor aparte ni escribir adaptadores en JavaScript. Para un operador que evalúa construir o comprar una herramienta de soporte u operaciones con IA, esto reduce el costo de ingeniería de una solución a medida corriendo en la red de Cloudflare, algo que conviene señalar al contratista o desarrollador interno que mantiene el stack de automatización.

Cloudflare permite encerrar a los agentes de IA dentro de un solo Worker

Si tu equipo opera agentes o pipelines de CI que despliegan, depuran o monitorean código en Cloudflare Workers, ahora puedes darle a un agente un token de API acotado que solo alcance una aplicación —por ejemplo, el webhook de tickets de soporte— en vez de todos los Workers de la cuenta. Un script de despliegue mal configurado o un token de agente comprometido ya no puede colarse en el Worker de facturación o en el de la base de datos de clientes. Para una empresa de 10 a 200 personas con varios flujos automatizados sobre infraestructura compartida, esto convierte el control de acceso en una barrera técnica en lugar de depender de la confianza o la revisión manual.

Cloudflare automatiza la remediación de vulnerabilidades con IA en Managed Defense

Para una empresa B2B de 10 a 200 empleados que opera su sitio, API o portal de clientes detrás de Cloudflare, esto significa que la triage de vulnerabilidades —normalmente una tarea lenta y manual que se reparte entre IT y un contratista de seguridad a tiempo parcial— ahora puede automatizarse en parte. Si tu equipo ya paga el nivel de seguridad de Cloudflare, conviene evaluar si esta nueva remediación con IA reduce la necesidad de un proveedor externo de escaneo de vulnerabilidades o de revisión manual de parches, ya que eso libera presupuesto real y tiempo de personal para otras tareas operativas. Las empresas sin personal de seguridad dedicado son las que más ganan, porque la herramienta funciona como un ingeniero de seguridad junior que señala fallos y propone soluciones de forma automática.

Cloudflare simplifica la verificación de bots y agentes de IA

Si el sitio web de tu empresa está detrás de Cloudflare, esto afecta directamente tu visibilidad ante asistentes de búsqueda de IA como ChatGPT o Perplexity cuando los prospectos les piden recomendaciones de proveedores. Un listado de bot verificado significa que puedes permitir con confianza el paso de rastreadores de IA específicos a través de tus reglas de firewall, en lugar de bloquear todo el tráfico de bots por precaución, lo cual antes arriesgaba dejar tus páginas de producto, documentación y precios fuera de las respuestas generadas por IA. También significa que los agentes no verificados que rastrean tu sitio bajo una identidad falsa son más fáciles de identificar y bloquear, reduciendo la carga innecesaria del servidor y el riesgo de abuso automatizado contra formularios de contacto o chat de soporte.

Cloudflare permite fijar las reglas de rastreo de IA una sola vez y sincronizarlas en todas partes

La mayoría de las empresas B2B de 10 a 200 personas operan varias propiedades web —sitio de marketing, documentación, blog, centro de ayuda— a menudo en plataformas distintas, cada una con reglas de bots separadas para controlar el acceso de crawlers de IA. Bot Preference Sync permite que operaciones o marketing definan una política de acceso de IA una sola vez (por ejemplo, permitir que ChatGPT y Perplexity citen contenido pero bloquear bots que raspan para entrenamiento) y que se aplique de forma consistente, sin que IT toque el robots.txt de cada subdominio. Esto afecta directamente la visibilidad en búsquedas de IA: aparecer citado correctamente en AI Overviews o respuestas de chatbots depende de que los crawlers puedan leer las páginas correctas mientras las áreas sensibles permanecen bloqueadas. La salvedad es que la sincronización solo funciona donde la plataforma receptora participa en el sistema de Cloudflare, por lo que aún no sustituye la vigilancia por sitio en todos los lugares donde vive el contenido.

Cloudflare limita el consentimiento OAuth a tareas concretas para reducir el riesgo de acceso de agentes

Si tu equipo de ventas o soporte ha conectado un agente de IA a un CRM, bandeja de entrada o sistema de tickets mediante OAuth, ese agente probablemente tiene permisos amplios y permanentes solo para completar una tarea puntual, como redactar una respuesta o actualizar la etapa de una oportunidad. El consentimiento basado en tareas permite empezar a acotar el acceso del agente a la acción concreta que está ejecutando, de modo que un agente comprometido o defectuoso no pueda leer o modificar silenciosamente todo lo que toca la cuenta conectada. Para una empresa de 10 a 200 personas que ejecuta varias integraciones de IA a la vez, esto marca la diferencia entre que un token filtrado exponga un solo flujo de trabajo o exponga todo un buzón o base de datos de clientes, y conviene auditar los permisos OAuth existentes en cuanto los proveedores que usas adopten este modelo.

Cloudflare cierra con un clic el agujero de seguridad de las apps internas "vibe-coded"

Si tu equipo de operaciones, RevOps o soporte ha estado usando asistentes de codificación con IA para montar rápidamente paneles internos, herramientas de triage de tickets o apps de consulta de datos sobre Cloudflare Workers, esto cierra una exposición real: esas apps a menudo eran accesibles para cualquiera con la URL, sin pantalla de login, porque en un equipo reducido de 10 a 200 personas nadie tiene como tarea propia "añadir autenticación". El envoltorio de Access de un clic permite que un fundador, un responsable de operaciones o la persona que "vibe-codeó" la herramienta un fin de semana exija el login con el SSO de la empresa antes de que cargue la app, sin escribir código de autenticación ni pedir la intervención de un ingeniero de seguridad. En la práctica, esto vale una tarde de trabajo: auditar todas las apps de Workers alojadas internamente que tu equipo haya publicado en el último año, especialmente las construidas con Claude, Cursor u herramientas similares de codificación con IA donde la velocidad primó sobre la revisión de seguridad, y poner cada una detrás de Access. No cuesta extra en la mayoría de los planes de Cloudflare y toma pocos minutos por app. La lección más amplia para equipos reducidos es que las herramientas de codificación con IA bajan la barrera para construir software interno, pero no bajan la barrera para asegurarlo: esa brecha debe cerrarla el proveedor de infraestructura o una checklist interna deliberada, y esta función es un proveedor cerrándola por defecto en lugar de dejar que el creador tenga que acordarse.

El eclipse solar redujo brevemente el tráfico de internet en Islandia, España y Portugal

Para una empresa B2B de 10 a 200 personas, este evento no tiene ninguna implicación operativa que amerite acción. No es un incidente de seguridad, ni un riesgo de capacidad, ni un fallo de infraestructura: es una caída breve y predecible en el comportamiento de navegación de consumidores en una región concreta, ligada a un fenómeno natural. A menos que tu base de clientes esté fuertemente concentrada en Reikiavik, Madrid o Lisboa y tu negocio dependa del tráfico en tiempo real durante una ventana de dos horas el día del eclipse, no hay nada aquí que deba cambiar en tu dotación de soporte, tu monitoreo de disponibilidad o tus flujos de automatización. Vale la pena mencionarlo sobre todo como ejemplo de lo bien que la telemetría de red puede capturar el comportamiento humano a escala, un dato útil si alguna vez necesitas explicarle a un cliente una anomalía de tráfico que de otro modo parecería inexplicable.

Cloudflare añade visibilidad y controles para el tráfico MCP ante el auge de las conexiones agente-herramienta

Si tu equipo ha conectado algún agente de IA —un bot de soporte, un asistente de ventas, una herramienta interna de operaciones— a fuentes de datos o software externo usando MCP, es probable que ese tráfico haya sido invisible para tu área de IT o seguridad hasta ahora. En una empresa B2B de 10 a 200 personas, detectar esto rara vez es tarea de un equipo de seguridad dedicado; suele quedar en manos de quien haya armado la integración el trimestre pasado. La conclusión práctica no es "adoptar Cloudflare": es una excusa para hacerle una pregunta directa a tu líder de operaciones o ingeniería: ¿qué herramientas de nuestro stack están haciendo conexiones MCP, quién las autorizó, y podemos ver qué datos circulan por ellas? Si la respuesta es un encogimiento de hombros, ahí está el vacío que este anuncio deja al descubierto.

Cloudflare activa por defecto la monitorización de Certificate Transparency para todos sus clientes

Para una empresa B2B de 10 a 200 personas, esto es una mejora silenciosa pero útil en tu postura de seguridad, no algo que altere el trabajo diario. Si tus dominios están detrás de Cloudflare, ahora recibes aviso automático y gratuito si alguien emite un certificado para tu dominio, tu portal de soporte o algún subdominio de cara al cliente sin que lo sepas — algo que suele preceder a campañas de phishing dirigidas contra tus clientes o empleados. Lo práctico es confirmar que la función esté activada y que las alertas lleguen a quien gestiona TI/seguridad (a menudo un fundador o responsable de operaciones que hace de todo en empresas de este tamaño), y asegurarse de que caigan en una bandeja que realmente se revisa, no en un correo muerto. No es motivo para cambiar tu stack de automatización ni tus flujos de soporte, pero sí es una reducción legítima y sin coste de un riesgo muy concreto: que un certificado falsificado se use para suplantar tu página de login o tus endpoints de API frente a tus propios clientes.