Fastly AI Firewall se lanza con controles de tiempo de ejecución, pero la seguridad en el edge es la verdadera prueba
Fastly lanzó el 21 de septiembre tres controles de IA conectados, entre ellos Fastly AI Firewall, AI Runtime Control y una ampliación de API Security. El lanzamiento conjunto incorpora el enrutamiento de modelos, la inspección de prompts, los límites de gasto y las restricciones para agentes a la ruta de solicitudes edge existente de Fastly.
Este posicionamiento genera la tensión central. Fastly no está vendiendo otro filtro de modelos aislado. Quiere que los clientes conviertan su infraestructura en el punto de control entre aplicaciones, proveedores de IA, usuarios y API empresariales.
Cloudflare y Palo Alto Networks ya compiten por partes de esa posición. Por tanto, Fastly debe demostrar que su arquitectura edge aporta un control útil sin añadir una latencia, un coste, una exposición de privacidad o una complejidad de implementación inaceptables.
El lanzamiento llega en un momento en que el tráfico de máquinas ocupa una proporción mayor de la red de Fastly. Fastly afirma que las solicitudes generadas por máquinas superaron la mitad del tráfico de red durante julio y agosto de 2026. También señala que el tráfico de IA creció 6,5 veces más rápido que el tráfico humano entre enero y mayo.
Estas cifras proceden de las propias observaciones de Fastly sobre su red, no de una medición independiente de internet en general. Aun así, explican por qué un proveedor edge considera la gobernanza de IA una oportunidad de infraestructura y no una categoría de seguridad independiente.
Fastly AI Firewall convierte el edge en un punto de control de IA
El lanzamiento de Fastly combina tres controles que abordan distintas partes de una solicitud de IA en producción.
AI Runtime Control se sitúa entre una aplicación y sus proveedores de modelos. Las aplicaciones envían solicitudes a modelos a través de un endpoint de Fastly, en lugar de llamar directamente a cada proveedor.
Fastly utiliza claves virtuales para proteger las credenciales subyacentes de los proveedores. Los administradores pueden asociar esas claves con modelos, usuarios, presupuestos y límites de tráfico, al tiempo que conservan acceso a proveedores públicos o autoalojados.
Esta arquitectura ofrece a los operadores una vista centralizada del volumen de solicitudes, el consumo de tokens, la selección de proveedores y las respuestas de los modelos. También admite la conmutación por error de proveedores cuando un servicio configurado deja de estar disponible.
Fastly AI Firewall añade inspección de seguridad a ese plano de control. Verifica los prompts antes de reenviarlos y examina las respuestas aptas antes de devolverlas a una aplicación.
La empresa afirma que el firewall busca patrones conocidos de inyección de prompts y jailbreak. La inyección de prompts se produce cuando una entrada no confiable intenta reemplazar o anular las instrucciones que deberían regir un modelo.
Los clientes pueden ejecutar el firewall en modo de registro o de bloqueo. El registro conserva la solicitud mientras registra una detección, mientras que el bloqueo rechaza una solicitud coincidente antes de que llegue al proveedor.
El tercer componente se dirige a los agentes que llaman a API empresariales. La ampliación de API Security de Fastly puede comparar las solicitudes entrantes con un contrato de API publicado, que define las operaciones y los formatos de datos que acepta un servicio.
Las organizaciones pueden observar o bloquear las solicitudes que infrinjan esos contratos. El control se aplica a aplicaciones convencionales, flujos de trabajo asistidos y agentes autónomos.
Esta distinción importa porque un agente puede generar tráfico de red sintácticamente válido mientras intenta realizar una operación no admitida. Una comprobación de disponibilidad tradicional no determina si la acción solicitada corresponde a la autoridad del agente.
Fastly presenta los tres componentes como un único sistema de ruta de solicitudes. Las llamadas a modelos pueden enrutarse y medirse, los prompts pueden inspeccionarse y las acciones de los agentes pueden limitarse en un límite de API.
Según el anuncio de lanzamiento, las tres capacidades estuvieron disponibles cuando Fastly las anunció. El lanzamiento no describía una vista previa futura ni un proyecto de investigación solo por invitación.
Fastly también afirma que los controles se ejecutan en su plataforma global existente. Según la empresa, esa red tenía una capacidad de 622 terabits por segundo a fecha de 30 de junio de 2026.
Fastly señala que gestionaba más de cinco billones de solicitudes al día a fecha de 31 de marzo. Estas cifras describen la escala de la plataforma, pero no establecen el rendimiento de los nuevos productos de IA.
El cambio estratégico sigue siendo claro. Fastly ha ampliado su posición en distribución y seguridad de aplicaciones hacia la ruta de solicitudes a modelos, donde el gasto en IA y las políticas de seguridad pueden aplicarse conjuntamente.
Esto crea una propuesta comercial más amplia que un filtro de prompts independiente. También pide a los clientes que sitúen interacciones sensibles con modelos dentro de otra capa operativa.
Por qué AI Runtime Control se está convirtiendo en una competencia de infraestructura
La IA empresarial crea simultáneamente un problema de enrutamiento, un problema de costes y un problema de autorización.
Una aplicación de IA inicial suele conectarse directamente a un proveedor de modelos con una sola credencial. Los sistemas de producción son más complejos porque los equipos utilizan varios modelos, cuentas, regiones y rutas de conmutación por error.
Los agentes amplían esa complejidad. Pueden seleccionar herramientas, enviar solicitudes, recuperar datos y activar operaciones sin que una persona apruebe cada llamada de red.
Fastly AI Runtime Control intenta estandarizar esas interacciones antes de que lleguen a un proveedor. Una clave virtual identifica al solicitante, mientras Fastly sustituye la credencial real del proveedor más adelante en la ruta de solicitud.
Esto puede reducir la proliferación de claves de proveedores entre aplicaciones y entornos de desarrollo. También proporciona a una organización un lugar uniforme para aplicar políticas de límites de velocidad y presupuestos.
La documentación de runtime de Fastly indica que los límites de velocidad pueden operar sobre solicitudes o tokens por minuto. Las reglas presupuestarias pueden alertar a los administradores o bloquear actividad adicional después de un umbral configurado.
La aplicación basada en tokens tiene una salvedad importante. Fastly afirma que el recuento final de tokens sigue siendo desconocido hasta que termina la respuesta, por lo que los límites de tokens operan con el mejor esfuerzo posible.
Esto significa que el plano de control puede restringir el uso sin garantizar una aplicación perfectamente exacta de los límites de tokens. Una respuesta costosa puede completarse antes de que su recuento final de tokens entre en el registro contable.
La misma documentación señala que los administradores pueden inspeccionar registros de solicitudes y respuestas. Los registros pueden incluir nombres de modelos, claves virtuales, datos de sesión, marcas de tiempo y recuentos de tokens.
Esta visibilidad ofrece valor operativo, pero plantea una cuestión de gobernanza. Los prompts y las finalizaciones pueden contener documentos internos, datos de clientes, credenciales o información personal.
Los equipos de seguridad necesitarán políticas claras de retención, control de acceso y procesamiento regional antes de centralizar estos registros. Un registro unificado solo resulta útil cuando la organización también gobierna quién puede inspeccionarlo.
La decisión de Fastly de combinar la gestión de tráfico con la seguridad refleja un cambio mayor en el mercado. Las pasarelas de IA se están convirtiendo en puntos de aplicación de políticas, en lugar de simples proxies.
Cloudflare, por ejemplo, combina la supervisión de AI Gateway con controles de seguridad de aplicaciones en su red. Sus controles de inyección de prompts asignan a las solicitudes una puntuación que los clientes pueden utilizar en reglas de firewall o limitación de velocidad.
Palo Alto Networks aborda la cuestión desde la seguridad empresarial. Su seguridad de tiempo de ejecución inspecciona interacciones en directo entre modelos, aplicaciones, agentes, plugins, datos y servicios externos.
Estos productos no tienen arquitecturas ni cobertura idénticas. Sin embargo, compiten por la misma ubicación valiosa: el punto en el que una interacción de IA todavía puede observarse y detenerse.
La ventaja de Fastly es su función actual en la entrega y protección del tráfico de aplicaciones. Los clientes que ya usan su red edge pueden preferir ampliar un plano de control establecido antes que implementar otra pasarela independiente.
Su desventaja es igual de directa. Los compradores pueden elegir una plataforma cloud, un proveedor de seguridad o una pasarela especializada que ya se sitúe más cerca de sus modelos, identidades o controles de datos.
Esta competencia presiona tanto a los proveedores de infraestructura como a los compradores empresariales. Los proveedores deben conectar rendimiento, seguridad, observabilidad y gobernanza de costes sin crear sistemas de políticas conflictivos.
Los compradores deben decidir dónde corresponde la autoridad. El edge de red ofrece una visibilidad amplia, mientras que el código de aplicación puede conservar un contexto empresarial más detallado.
Ninguna capa lo ve todo. Una pasarela puede inspeccionar una solicitud, pero la aplicación puede saber si la acción solicitada es adecuada para un cliente o flujo de trabajo concreto.
Fastly apuesta por que el edge puede convertirse en la capa común de aplicación, mientras las aplicaciones conservan su propia lógica de autorización. El valor de AI Runtime Control depende de lo bien que cooperen esas dos capas.
El mecanismo del producto también define sus límites
Fastly AI Firewall reduce la exposición en la ruta de solicitudes, pero no elimina la inyección de prompts ni el comportamiento inseguro de los agentes.
Fastly describe su inspección como determinista. El firewall comprueba las solicitudes frente a firmas conocidas de inyección y jailbreak, en lugar de enviar cada prompt a través de otro modelo generativo.
Esta elección tiene un atractivo práctico. Las comprobaciones deterministas pueden ofrecer un comportamiento predecible y evitar el coste de ejecutar un segundo modelo para cada interacción.
Fastly también encapsula la entrada no confiable con tokens criptográficos de delimitación. Las instrucciones que la acompañan indican al modelo que trate el material encapsulado como datos, no como comandos con autoridad.
Esta técnica aborda una debilidad básica de las aplicaciones de modelos de lenguaje. Las instrucciones del sistema y el texto no confiable llegan finalmente a un modelo como flujos relacionados de tokens, pese a su distinta autoridad prevista.
Por lo tanto, un documento malicioso puede contener instrucciones dirigidas al modelo que lo lee. El ataque se vuelve indirecto cuando la carga entra a través de contenido recuperado, correo electrónico, un sitio web u otra fuente externa.
Fastly comprueba las salidas aptas en busca de indicios de que un ataque afectó al modelo. Los administradores pueden revisar etiquetas de detección, clasificaciones de amenazas y resultados canary junto con otra información de solicitudes.
Estos controles añaden fricción para ataques conocidos, pero los atacantes pueden variar la redacción, la codificación, el idioma o el contexto. Un sistema de firmas debe seguir cambiando a medida que aparecen nuevos métodos de evasión.
OWASP sitúa la inyección de prompts en primer lugar en su lista de 2025 de riesgos principales para aplicaciones de modelos de lenguaje de gran tamaño. Su guía de prevención recomienda defensas en capas en lugar de depender de un único filtro.
Estas defensas incluyen separar las instrucciones de los datos, limitar los privilegios del modelo, validar las salidas, exigir aprobación humana para acciones importantes y supervisar el comportamiento.
La documentación de Fastly revela otro límite. La inspección de respuestas requiere una respuesta completa, por lo que las solicitudes de streaming pasan sin inspección de salida.
El streaming entrega texto generado de forma incremental en lugar de esperar la respuesta completa. Es compatible con interfaces de chat ágiles, pero el firewall no puede evaluar la respuesta terminada antes de que la aplicación empiece a recibirla.
El aislamiento estructural también añade tokens a las solicitudes. Fastly afirma que los proveedores de modelos de los clientes facturan esos tokens adicionales conforme a su uso habitual.
Eso no hace que la protección sea poco práctica. Sí significa que los clientes deben medir si el coste adicional de tokens sigue siendo aceptable a su volumen de producción.
La latencia exige un escrutinio similar. La inspección en línea añade procesamiento a una ruta en la que los usuarios ya esperan la inferencia del modelo, la ejecución de herramientas y la recuperación de datos.
La presencia perimetral de Fastly debería reducir la distancia de red para muchas solicitudes. El anuncio no proporciona referencias de latencia independientes para la secuencia completa del firewall y el plano de control.
Los falsos positivos plantean una disyuntiva distinta. Los debates relacionados con la seguridad, los prompts de depuración y el contenido de investigación pueden incluir legítimamente las mismas frases que aparecen en un ataque.
El modo de registro permite a los equipos observar esas detecciones antes de bloquearlas. También mantiene activas las solicitudes coincidentes durante el periodo de evaluación.
El modo de bloqueo reduce esa exposición, pero arriesga rechazar tráfico válido. Los clientes necesitarán pruebas específicas para cada carga de trabajo, en lugar de considerar que una sola política es adecuada para todas las aplicaciones.
El componente de aplicación de API también depende de contratos precisos. Un esquema desactualizado o incompleto puede bloquear actividad válida de agentes o permitir operaciones cuyo riesgo solo aparece en el contexto empresarial.
El cumplimiento del contrato no es lo mismo que la autorización. Un agente puede llamar a un endpoint permitido con datos válidos mientras persigue un objetivo inapropiado.
Por lo tanto, el producto funciona mejor como una capa dentro de un sistema más amplio. Los permisos de aplicación, los controles de identidad, las restricciones de herramientas, los registros de auditoría y la aprobación humana siguen siendo necesarios.
El lanzamiento es significativo porque integra estos controles en la infraestructura existente. Su importancia no debe confundirse con la afirmación de que la inspección de red resuelve todo el problema de seguridad de los agentes.
Fastly se enfrenta a Cloudflare y a proveedores de seguridad por la misma ruta de solicitudes
La principal batalla competitiva gira en torno al control del tráfico de IA, no a la propiedad del modelo subyacente.
Fastly no necesita que los clientes se estandaricen en un único proveedor de modelos. AI Runtime Control está diseñado para enrutar solicitudes entre modelos públicos y autoalojados a través de un endpoint común.
La independencia de proveedores puede atraer a equipos preocupados por interrupciones, cambios en el rendimiento de los modelos o la dependencia de un solo proveedor. También crea un intermediario central que los clientes deben operar y en el que deben confiar.
Cloudflare sigue una estrategia perimetral relacionada. Su AI Gateway gestiona la observabilidad y el control de modelos, mientras que AI Security for Apps añade detecciones relacionadas con prompts, temas y datos mediante su firewall de aplicaciones web.
El sistema de inyección publicado por Cloudflare utiliza una puntuación graduada del 1 al 99. Fastly destaca firmas deterministas, tokens de límite, etiquetas de detección y un comportamiento de registro o bloqueo seleccionado por el cliente.
La documentación disponible describe distintas superficies de control, pero no respalda una comparación definitiva de precisión. Las pruebas independientes necesitarían conjuntos de datos, configuraciones, modelos y métodos de ataque comunes.
Palo Alto Networks ofrece un enfoque de seguridad más amplio. Su producto de tiempo de ejecución describe protecciones frente a inyecciones, contenido envenenado, enlaces maliciosos, filtración de datos, interacciones con modelos y actividad de agentes.
Esa amplitud puede convenir a organizaciones que ya estandarizan sus operaciones de seguridad en Palo Alto Networks. Fastly puede responder con su cercanía a la entrega de aplicaciones y una arquitectura familiar para sus clientes actuales.
Las empresas especializadas en seguridad de IA crean otra fuente de presión. Pueden centrarse estrictamente en la evaluación de modelos, el red teaming, las barreras de protección o el comportamiento de agentes sin mantener una red general de entrega.
Los especialistas pueden innovar con rapidez dentro de una categoría de amenazas. También pueden obligar a los clientes a añadir otro proveedor, proxy, lenguaje de políticas y almacén de telemetría.
Por tanto, la decisión de compra dependerá de más que una lista de funciones. Los equipos deben comparar la ubicación de despliegue, el manejo de datos, la cobertura de modelos, la expresividad de las políticas, la observabilidad y el comportamiento ante fallos.
El comportamiento ante fallos merece especial atención. Un control en línea debe decidir si el tráfico continúa cuando los servicios de inspección, registro o políticas dejan de estar disponibles.
El comportamiento de apertura ante fallos protege la disponibilidad, pero permite tráfico sin inspección. El comportamiento de cierre ante fallos preserva la aplicación de controles, pero puede convertir una dependencia de seguridad en una interrupción de la aplicación.
Fastly destaca la conmutación por error de proveedores dentro de AI Runtime Control. Los compradores deben verificar por separado cómo maneja la plataforma los fallos en la inspección del firewall, el registro, la evaluación de políticas y la validación de API.
La consolidación de proveedores genera su propia tensión. Usar una sola plataforma para la entrega, la seguridad de aplicaciones, el enrutamiento de IA y los controles de agentes puede reducir la fragmentación operativa.
También puede aumentar la dependencia de una sola ruta de solicitudes. Un error de configuración, un incidente de plataforma o el compromiso de una cuenta podría afectar simultáneamente a varias capas.
Las organizaciones con requisitos estrictos de aislamiento pueden preferir proveedores o puntos de aplicación separados. Otras aceptarán la concentración a cambio de operaciones más simples y telemetría unificada.
Fastly también debe demostrar que los clientes perimetrales existentes quieren que la empresa gestione las interacciones con modelos. Entregar activos web e inspeccionar conversaciones completas de IA genera expectativas distintas de privacidad y cumplimiento.
La ruta más sólida para la adopción a corto plazo probablemente pase por los clientes actuales de Fastly. Ya envían tráfico de aplicaciones a través de la red y conocen su modelo de configuración.
Los nuevos clientes afrontan una comparación más difícil. Fastly debe demostrar suficiente profundidad de seguridad para competir con proveedores especializados y suficiente valor operativo para justificar el redireccionamiento de llamadas a modelos.
Por eso el lanzamiento es más que un anuncio de funciones. Fastly intenta expandirse de proteger aplicaciones a gobernar la actividad de IA que esas aplicaciones generan.
Tres señales mostrarán si la apuesta de Fastly por la seguridad de IA funciona
La evidencia de adopción, las pruebas de seguridad independientes y las respuestas competitivas revelarán si el perímetro se convierte en una capa duradera de control de IA.
La primera señal es la adopción en producción. Con el tiempo, Fastly debería divulgar ejemplos de clientes que expliquen qué modelos, cargas de trabajo y políticas se ejecutan mediante AI Runtime Control.
Los casos de estudio útiles informarían sobre el alcance del despliegue, el esfuerzo de migración, la actividad bloqueada, la gestión de falsos positivos y los resultados operativos. Las afirmaciones generales sobre visibilidad o seguridad aportarían menos evidencia.
Los clientes también deberían describir cómo gobiernan los registros de prompts y finalizaciones. Esa información mostrará si la observabilidad centralizada supera las revisiones de privacidad, cumplimiento y acceso interno.
La segunda señal es una evaluación independiente de Fastly AI Firewall. Las pruebas deberían medir las tasas de detección de inyección directa, inyección indirecta, jailbreaks, prompts codificados, ataques multilingües y contenido de seguridad benigno.
También deberían publicar tasas de falsos positivos, latencia, consumo adicional de tokens y comportamiento durante el streaming. Sin esas mediciones, los compradores pueden comparar la arquitectura, pero no el rendimiento defensivo verificado.
Las pruebas deben tener en cuenta los cambios en los modelos y los métodos de ataque. Un control que funciona bien frente a firmas conocidas aún puede tener dificultades ante ataques adaptativos o específicos de una aplicación.
La tercera señal es cómo respondan Cloudflare, Palo Alto Networks y los proveedores especializados. Un enrutamiento, identidad, prevención de pérdida de datos o autorización de agentes más integrados aumentarían la presión sobre la plataforma combinada de Fastly.
La propia hoja de ruta de Fastly también importará. La documentación actual ya identifica límites prácticos, incluida la aplicación de tokens basada en el mejor esfuerzo y la inspección incompleta de respuestas transmitidas en streaming.
Cerrar esas brechas reforzaría el argumento a favor de un único plano de control. Dejarlas sin cambios preservaría espacio para capas de seguridad a nivel de aplicación o competidoras.
Los equipos empresariales no necesitan esperar a que el mercado se estabilice antes de evaluar el lanzamiento. Pueden comenzar con una carga de trabajo limitada en modo de registro y comparar las detecciones con sus controles actuales.
Un piloto debería incluir prompts benignos representativos, pruebas adversarias, respuestas transmitidas en streaming, fallos de proveedores y escenarios de límites presupuestarios. Los equipos también deberían verificar qué almacena Fastly y quién puede acceder a cada registro.
Las pruebas de agentes necesitan una evaluación adicional. Un agente debería enfrentarse a permisos explícitos de herramientas y contratos de API mientras intenta ejecutar flujos de trabajo tanto válidos como no autorizados.
El resultado debe medirse al nivel de la acción empresarial, no solo al nivel de la solicitud de red. Una solicitud bien formada aún puede producir una acción inaceptable.
Fastly AI Firewall merece atención porque conecta la seguridad con el enrutamiento, el gasto y la aplicación de API para agentes. Esa combinación se ajusta a la forma operativa de la IA en producción más estrechamente que un filtro de prompts aislado.
La pregunta abierta es si Fastly puede convertir su posición en la red en autoridad fiable sobre el comportamiento de la IA. La inspección perimetral ofrece visibilidad y una oportunidad de aplicación, pero el contexto empresarial sigue estando en otra parte.
Para desarrolladores y líderes de seguridad, el siguiente paso es concreto: probar los controles de IA de Fastly con cargas de trabajo reales, documentar cada punto ciego y comparar los resultados con defensas de rutas de solicitudes competidoras. El valor del producto surgirá de un comportamiento medido bajo fallos y ataques, no del tamaño de la red que lo sustenta.
