F5 Workforce AI Security lleva el control de agentes a la ruta de red
F5 Workforce AI Security estará disponible de forma general en octubre de 2026, ampliando la plataforma de seguridad de F5 desde las aplicaciones de IA hasta la actividad de empleados y agentes. El producto aborda un conflicto creciente dentro de las empresas. Los trabajadores quieren herramientas de IA capaces de actuar, mientras que los equipos de seguridad necesitan controles antes de que esas acciones alcancen sistemas sensibles.
F5 anunció la oferta el 9 de septiembre como una capa sin agentes para descubrir el uso de IA y aplicar políticas en las interacciones de la fuerza laboral. Según el anuncio sobre Workforce de la compañía, dichas interacciones incluyen navegadores, herramientas de desarrollo, agentes de programación, interfaces de línea de comandos y clientes de Model Context Protocol.
El cambio importante no es otro panel para contar visitas a ChatGPT. F5 quiere inspeccionar lo que un agente de IA pretende hacer, asociar la solicitud con una identidad e intervenir antes de su ejecución.
Este enfoque contrapone la aplicación de políticas basada en la red a los controles ligados a endpoints, navegadores o aplicaciones de IA individuales. También plantea preguntas difíciles sobre la cobertura del tráfico, las sesiones cifradas, la privacidad de los empleados y la fiabilidad de la clasificación automatizada de intenciones.
Palo Alto Networks, Microsoft, Zscaler, Netskope y otros proveedores de seguridad ya ofrecen controles para el uso de IA por parte de la fuerza laboral. La apuesta de F5 es más acotada y ambiciosa. Sostiene que la ruta de red puede convertirse en un punto de aplicación coherente a medida que la actividad de IA va más allá de los prompts y entra en el trabajo impulsado por herramientas.
F5 Workforce AI Security amplía el control más allá de los prompts
F5 está tratando la llamada a una herramienta de un agente como un evento de seguridad, no simplemente como una conversación con IA.
Los controles tradicionales de IA para la fuerza laboral suelen comenzar con el descubrimiento de aplicaciones. Los equipos de seguridad identifican qué servicios de IA generativa utilizan los empleados y luego restringen cargas, prompts o aplicaciones no aprobadas.
Estos controles siguen siendo importantes. Un empleado puede exponer código fuente, registros de clientes, credenciales o documentos legales al introducirlos en un modelo público. La guía de Microsoft sobre controles de datos sensibles recomienda analizar prompts, resultados, operaciones de memoria, contexto recuperado y resultados de herramientas.
Los agentes amplían el problema porque pueden actuar después de recibir una respuesta. Un agente de programación puede editar un repositorio, invocar una herramienta de despliegue o ejecutar comandos. Un asistente podría recuperar documentos, actualizar un registro de cliente o enviar un mensaje.
Estas acciones suelen heredar los permisos del usuario humano. F5 describe esta condición como autoridad prestada. El agente no necesita una cuenta completamente independiente para generar riesgos si opera mediante credenciales ya concedidas a un empleado.
F5 Workforce AI Security está diseñado para identificar tanto al humano como al agente implicados en una interacción. Luego puede clasificar la intención de la solicitud, evaluar el riesgo de acceso y aplicar una política antes de que se ejecute una llamada a herramienta compatible.
La compañía afirma que las políticas pueden permitir, bloquear o modificar acciones. También pueden tener en cuenta la exposición de datos sensibles y la identidad asociada con una solicitud.
Model Context Protocol, o MCP, es un protocolo abierto que conecta aplicaciones de IA con herramientas y fuentes de datos. F5 afirma que su producto puede inspeccionar y clasificar llamadas a herramientas en servidores MCP y herramientas de agentes compatibles.
Esta distinción lleva la seguridad de la fuerza laboral más allá del control de qué chatbot abre un empleado. Un agente permitido aún podría intentar una acción que quede fuera de la tarea inmediata del usuario o de la política de la empresa.
F5 también planea controles sobre la elección de servicio, el tipo de licencia, las cargas de archivos y la política de datos. Una organización podría permitir una cuenta empresarial aprobada mientras limita una versión de consumo del mismo servicio.
El producto se integra en la plataforma más amplia F5 AI Security Platform. F5 presentó esa plataforma en junio de 2026 para el descubrimiento, la gobernanza, las pruebas y la protección en tiempo de ejecución de IA.
En agosto, la compañía añadió capacidades de AI Gateway, incluido un MCP Gateway. Workforce AI Security ahora extiende la plataforma hacia la actividad de los empleados y los agentes que actúan con permisos de empleados.
La secuencia es importante. Las pruebas de red teaming pueden revelar debilidades antes del despliegue, mientras que las barreras de protección en tiempo de ejecución protegen aplicaciones de IA activas. Los controles de la fuerza laboral abordan el riesgo independiente que surge cuando los empleados adoptan herramientas externas o delegan tareas en agentes.
Por tanto, F5 quiere una estructura de políticas única para el desarrollo, el despliegue y el uso de IA. Que los clientes experimenten esa unidad dependerá de la calidad de la integración y de la cobertura del tráfico, no solo del mapa de productos.
Está previsto que el producto tenga disponibilidad general en octubre. Hasta que comiencen los despliegues, su precisión en la aplicación de políticas y su carga operativa siguen siendo afirmaciones de la compañía, no resultados validados de forma independiente.
Por qué las acciones de los agentes crean un problema de seguridad distinto
Un agente de IA puede convertir un prompt imprudente en una operación con consecuencias sobre sistemas reales.
Un empleado que pega texto confidencial en un chatbot crea un problema de gobernanza de datos. Un agente que utiliza credenciales para cambiar una configuración de producción también crea un problema de autorización.
Esta distinción explica por qué F5 está haciendo hincapié en las acciones, no solo en los prompts. El perímetro de seguridad cambia cada vez que un sistema de IA puede llamar herramientas, modificar datos o comunicarse externamente.
El informe State of Application Strategy Report 2026 de F5 concluyó que el 66 por ciento de las organizaciones encuestadas permite que la IA ajuste políticas o configuraciones automáticamente. F5 citó esta cifra en su anuncio, por lo que debe tratarse como investigación patrocinada por la compañía.
Incluso con esa salvedad, el problema subyacente es claro. Las empresas están trasladando la IA de interfaces de asesoramiento a flujos de trabajo con acceso de escritura.
El agente puede recibir un permiso amplio porque el empleado ya lo posee. Sin embargo, la autoridad de un usuario no demuestra que cada acción generada por el agente refleje la intención informada del usuario.
Esto crea una brecha entre autenticación y autorización. La autenticación establece quién inició una sesión. La autorización debe decidir si una acción específica es adecuada en su contexto actual.
Los equipos de seguridad también afrontan la inyección indirecta de prompts. Un atacante puede introducir instrucciones maliciosas en contenido que un agente leerá después, como un correo electrónico, sitio web, documento o repositorio de código.
El agente puede interpretar ese contenido hostil como una instrucción y realizar una acción no prevista. La investigación de seguridad de agentes de NIST describe el robo de datos y la ejecución de código malicioso como posibles consecuencias.
Una capa de políticas de red puede añadir otro punto de control antes de que la acción resultante llegue a una herramienta. No elimina el razonamiento comprometido dentro del agente, pero puede restringir el resultado.
F5 afirma que sus controles utilizan contexto como identidad, intención, riesgo y datos sensibles. Esa combinación es necesaria porque ni una simple lista de bloqueo de aplicaciones ni una lista estática de permisos capturan toda la situación.
Pensemos en un desarrollador que utiliza un agente de programación aprobado. Leer un archivo público de dependencias podría ser rutinario. Cargar código propietario en un modelo externo puede infringir la política.
Abrir una incidencia interna podría ser aceptable. Modificar un despliegue de producción puede requerir una aprobación independiente o una identidad de servicio con permisos más restringidos.
Por tanto, la decisión de seguridad depende de quién actúa, qué datos intervienen, qué herramienta es el objetivo y qué operación se solicita. También puede depender del entorno y del momento.
Ese es el atractivo práctico de la aplicación de políticas basada en la intención. Promete más contexto que una regla que bloquea un servicio completo o permite cada interacción.
Sin embargo, la “intención” también es una entrada difícil. Un clasificador debe convertir solicitudes ambiguas en lenguaje natural y llamadas técnicas a herramientas en categorías de política fiables.
Un bloqueo erróneo puede interrumpir trabajo legítimo. Una aprobación errónea puede exponer datos o permitir una operación perjudicial. Los entornos de alto riesgo necesitarán controles deterministas en torno a las acciones más consecuentes.
El trabajo de NIST sobre identidad de agentes hace hincapié en la identificación, la autorización, la auditoría y el no repudio. También plantea cómo las organizaciones pueden mitigar la inyección de prompts.
Estos requisitos van más allá de la inspección del tráfico. Las empresas necesitan identidades claras para los agentes, permisos restringidos, registros duraderos y responsables de cada flujo de trabajo automatizado.
F5 Workforce AI Security puede convertirse en una capa de aplicación de políticas dentro de ese sistema. No debería convertirse en la única fuente de confianza.
La competencia principal es entre la aplicación de políticas en red y el control específico de herramientas
F5 apuesta a que la red ofrece un punto de control más duradero que cualquier integración con un modelo, navegador o endpoint individual.
Los servicios de IA cambian con rapidez. Los empleados pueden pasar de un chatbot conocido a una extensión de navegador, asistente de programación, cliente de línea de comandos o modelo alojado de forma privada.
Un control de seguridad específico de una aplicación debe reconocer cada servicio y comprender su interfaz. Un producto de endpoint necesita despliegue, mantenimiento y permisos en cada dispositivo gestionado.
F5 propone aplicar controles donde los prompts, las respuestas y las acciones de los agentes atraviesan la infraestructura empresarial. La compañía afirma que este enfoque es independiente de un proveedor de modelos o aplicaciones específico.
Su producto puede descubrir servicios de IA en navegadores y herramientas de desarrollo. F5 también afirma que admite herramientas desarrolladas internamente que acceden a API de modelos públicos.
La oferta no requiere otro cliente de endpoint, según F5. Esta formulación es importante. Significa que los clientes pueden evitar añadir un nuevo cliente, no que el producto no requiera trabajo de despliegue.
Los clientes aún necesitan ubicación en la red, integración de identidades, configuración de políticas, registro y conexiones con su entorno de seguridad existente. La cobertura también depende de qué tráfico puede observar la organización.
La página de producto de F5 describe el descubrimiento pasivo mediante tráfico de red replicado. Indica que el análisis fuera de banda no introduce latencia porque la inspección ocurre fuera de la ruta de producción.
La misma página describe controles adaptativos que bloquean, redirigen o modifican la actividad. El anuncio también afirma que las políticas operan en la ruta de interacción.
Estas funciones representan modos operativos diferentes. El descubrimiento pasivo puede observar sin retrasar el tráfico. La aplicación activa debe influir en la solicitud antes de la ejecución.
Las empresas deberían preguntar qué componentes funcionan de forma pasiva y cuáles se sitúan en línea. También deberían confirmar qué sucede cuando los servicios de inspección fallan o no pueden clasificar una solicitud.
Los competidores ya ocupan partes de este mercado. Palo Alto Networks ofrece controles de acceso a IA para descubrir aplicaciones de IA generativa y evitar la filtración de datos sensibles mediante prompts y cargas.
Microsoft Purview puede descubrir actividad de IA, aplicar políticas de prevención de pérdida de datos y mostrar eventos de IA generativa en registros de auditoría. Zscaler afirma que AI Guard for Users inspecciona los prompts y las respuestas de los empleados ante servicios públicos de IA.
Netskope combina descubrimiento de aplicaciones, controles de datos e infraestructura de security service edge. Estos proveedores ya venden a equipos empresariales de seguridad de red y datos.
Por lo tanto, F5 debe demostrar que controlar las acciones de los agentes aporta una ventaja operativa significativa. Simplemente detectar la IA en la sombra no creará una diferenciación suficiente.
Su plataforma más amplia podría ayudar. Los datos de descubrimiento pueden alimentar las pruebas de F5 AI Red Team y las políticas de ejecución de F5 AI Guardrails, según las capacidades del producto de la compañía.
En teoría, ese ciclo de retroalimentación resulta atractivo. El comportamiento observado de la fuerza laboral puede identificar casos de uso riesgosos que los equipos de seguridad pueden probar y gobernar de manera más deliberada.
Sin embargo, los clientes rara vez estandarizan todas las funciones de seguridad en una sola plataforma. Muchos operarán F5 junto con proveedores de identidad, herramientas de endpoints, intermediarios de acceso a la nube, productos de seguridad de datos y controles nativos de los modelos.
La interoperabilidad importará más que una única consola. Los equipos de seguridad necesitan que los eventos y las decisiones de política circulen sin fricciones entre sus sistemas existentes.
El enfoque de red también presenta puntos ciegos naturales. Las conexiones directas de dispositivos, las redes no gestionadas, el cifrado de extremo a extremo, los modelos locales y las herramientas no compatibles pueden limitar el contexto observable.
F5 no ha establecido públicamente que todas esas rutas estén cubiertas. Los compradores deberían mapear los flujos de trabajo reales de los empleados antes de aceptar una afirmación de visibilidad completa.
La versión más sólida del argumento de F5 no es que la red lo vea todo. Es que un punto de control de red puede proporcionar una aplicación coherente de las políticas en muchas herramientas que, de otro modo, estarían fragmentadas.
Esa propuesta es comprobable. Los clientes pueden comparar la actividad detectada con la telemetría de endpoints, los registros de SaaS, los registros de identidad y las implementaciones conocidas de agentes.
Si los registros coinciden, la aplicación de políticas en red se convierte en una capa común útil. Si persisten brechas sustanciales, la plataforma requerirá controles complementarios.
La visibilidad amplia conlleva compensaciones en privacidad y precisión
Inspeccionar la actividad de IA puede reducir el riesgo de seguridad, pero también crear un registro sensible de las ideas, los errores y los hábitos de trabajo de los empleados.
F5 afirma que su plataforma puede registrar las interacciones de IA y clasificar la intención empresarial. Sus materiales de producto citan ejemplos como la elaboración de resúmenes y la generación de código.
Esa información puede ayudar a los equipos de seguridad a identificar patrones riesgosos. También puede exponer conversaciones confidenciales, estrategias en borrador, asuntos de personal, preguntas de investigación y señales del rendimiento individual.
Un prompt rara vez es solo otro evento de red. Puede contener el razonamiento del usuario, sus incertidumbres o contexto detallado de trabajo interno.
Las respuestas pueden ser igual de sensibles. Un sistema de IA puede combinar la información proporcionada por el usuario con datos corporativos recuperados, memoria privada o contenido de herramientas conectadas.
Por ello, las organizaciones necesitan controles para el propio sistema de seguridad. El acceso a los registros de prompts y respuestas debe regirse por roles estrictos, límites de retención y requisitos de auditoría.
Los equipos jurídicos, de privacidad, seguridad y relaciones laborales deberían definir una monitorización aceptable antes de un despliegue amplio. Las normas regionales de privacidad y trabajo también pueden afectar la forma en que se introduce la monitorización.
F5 afirma que los registros de auditoría pueden capturar el recorrido de una solicitud de IA, su respuesta y la intención del usuario. Las empresas deberían determinar qué campos se conservan y si el contenido sensible puede minimizarse.
También deberían preguntar si la redacción ocurre antes del registro o solo antes de que los datos lleguen a un modelo externo. El orden modifica la exposición creada por la plataforma de seguridad.
La precisión de la clasificación plantea otra compensación. Una solicitud etiquetada como «resumen» podría contener registros regulados. Una acción de programación podría, en realidad, modificar infraestructura mediante un script generado.
La intención expresada en lenguaje natural puede complementar los hechos técnicos explícitos, pero no debería sustituirlos. El destino, el tipo de operación, la identidad, la sensibilidad del recurso y el alcance de los permisos ofrecen señales más sólidas.
Las acciones de alto impacto merecen políticas de denegación por defecto o requisitos de aprobación directa. Las acciones de bajo riesgo pueden tolerar clasificaciones más flexibles y orientación.
El sistema también debe distinguir a los usuarios de los agentes que actúan en nombre de esos usuarios. Los tokens compartidos o las sesiones de navegador heredadas pueden dificultar la atribución.
NIST ha advertido que los agentes suelen obtener acceso a nuevas herramientas y datos mediante credenciales humanas. Sus directrices de identidad de agosto de 2026 también destacan la fatiga de consentimiento causada por solicitudes de aprobación repetidas.
Demasiados avisos pueden entrenar a los usuarios para aprobar acciones de forma refleja. Muy pocos avisos pueden permitir que un agente cruce límites importantes sin una revisión significativa.
El motor de políticas de F5 debe ayudar a los clientes a elegir dónde debe existir fricción. La respuesta variará según la acción, el recurso y la función empresarial.
Un asistente de ventas que redacta un correo electrónico implica un riesgo distinto al de un agente de programación que modifica infraestructura de producción. Un resumen local tiene implicaciones diferentes a una carga externa.
Los equipos también necesitan un proceso para impugnar decisiones de política incorrectas. Sin motivos transparentes, los desarrolladores pueden eludir los controles o volver a herramientas no gestionadas.
Aquí es donde una base de conocimientos de IA consultable puede respaldar la gobernanza. Los empleados necesitan registros claros de las herramientas aprobadas, las reglas de datos y las vías de escalamiento.
La documentación por sí sola no puede aplicar políticas. Sin embargo, la aplicación de políticas sin una orientación comprensible suele empujar la adopción hacia canales menos visibles.
El posicionamiento sin agentes de F5 reduce una fuente de fricción de despliegue. No elimina el trabajo organizativo necesario para clasificar datos, asignar responsabilidades y definir acciones permitidas.
La versión de octubre deberá mostrar cómo se comportan esos controles bajo presión habitual. Una evaluación útil debería incluir falsos positivos, acciones no detectadas, latencia de políticas y carga de trabajo administrativa.
Los equipos de seguridad también deberían probar prompts adversariales, no solo flujos de trabajo normales. Un producto de control de agentes debe gestionar intentos de disfrazar la intención o dividir trabajo riesgoso entre varias llamadas.
Ninguna barrera de protección fija puede garantizar una protección permanente frente a atacantes adaptativos. La aplicación de políticas en red debería formar parte de pruebas, monitorización y actualizaciones de políticas continuas.
Tres señales mostrarán si la apuesta de F5 funciona
El valor del producto estará determinado por una cobertura medida, controles aplicables sobre los agentes e integraciones que resistan la complejidad real de las empresas.
La primera señal es la evidencia de despliegue posterior a octubre de 2026. F5 debería publicar detalles precisos sobre navegadores compatibles, herramientas de línea de comandos, marcos de agentes, clientes MCP y configuraciones de red.
Una larga lista de compatibilidad no será suficiente. Los clientes necesitan saber qué flujos de trabajo admiten solo descubrimiento y cuáles permiten la aplicación de políticas antes de la ejecución.
Deberían comparar el inventario de F5 con la telemetría de endpoints, los registros de identidad, los registros de API y las encuestas a empleados. Las diferencias sin explicación revelarán puntos ciegos.
Esta evidencia reforzará el caso de F5 si un despliegue basado en red identifica actividad en muchas herramientas con una baja sobrecarga operativa. Las grandes brechas de cobertura lo debilitarán.
La segunda señal es la prueba de que los controles sobre las acciones de los agentes funcionan en condiciones adversariales. Esto implica probar más que solicitudes evidentes para eliminar archivos o exportar registros.
Las evaluaciones deberían incluir inyección indirecta de prompts, solicitudes ambiguas, llamadas a herramientas anidadas, credenciales reutilizadas y acciones distribuidas en varios pasos.
Los clientes deberían medir tanto las acciones dañinas detenidas como las acciones legítimas interrumpidas. Un producto que bloquea todo solo es seguro en el sentido más limitado.
F5 ya ofrece capacidades de red team de IA, por lo que los compradores deberían preguntar si las políticas de Workforce AI Security pueden probarse frente a escenarios de ataque reproducibles. Los resultados deberían informar cambios de política.
La validación independiente tendría más peso que los scripts de demostración. La documentación técnica debería explicar los límites de clasificación y el comportamiento ante fallos sin revelar lógica sensible de detección.
La tercera señal es la respuesta competitiva. Palo Alto Networks, Microsoft, Zscaler, Netskope y los proveedores de identidad cuentan con puntos de control adyacentes y relaciones consolidadas con los clientes.
Si esas empresas amplían la aplicación de políticas sobre llamadas a herramientas y las funciones de identidad de los agentes, la diferenciación de F5 se reducirá. También confirmaría que la seguridad de IA para la fuerza laboral está evolucionando más allá de la gobernanza de chatbots.
Si, en cambio, los clientes consolidan sus controles en torno a permisos nativos de los modelos o controles centrados en la identidad, la inspección de red podría seguir siendo una capa de apoyo. F5 competiría entonces en integración y comodidad operativa.
El resultado más probable es una seguridad por capas. Los proveedores de modelos restringirán el uso de herramientas, los sistemas de identidad limitarán la autoridad y los productos de endpoints observarán la actividad de los dispositivos.
Los controles de red pueden evaluar flujos de datos y operaciones entre proveedores. Las barreras de protección en tiempo de ejecución pueden supervisar las aplicaciones que las propias empresas desarrollan.
La pregunta central no es qué capa gana. Es si la política se mantiene coherente cuando una acción pasa entre esas capas.
Para los compradores empresariales, el paso inmediato consiste en inventariar los flujos de trabajo reales de IA antes de elegir un producto de control. Incluyan servicios aprobados, herramientas en la sombra, agentes de programación, modelos privados y conexiones MCP.
Después, identifiquen qué flujos de trabajo pueden leer datos sensibles, comunicarse externamente o cambiar el estado de un sistema. Esas capacidades merecen las identidades y comprobaciones de políticas más sólidas.
F5 Workforce AI Security llega en un momento oportuno porque la adopción de agentes está dejando al descubierto los límites de las listas de bloqueo de aplicaciones. Su estrategia de red ofrece un punto de control común plausible.
La estrategia sigue sin demostrarse a escala. F5 debe mostrar que puede observar suficiente contexto, clasificar las acciones con precisión y aplicar políticas sin hacer intolerable el uso productivo de la IA.
Los responsables de seguridad deberían utilizar el lanzamiento de octubre como el inicio de una evaluación, no como su final. ¿Qué acciones de los agentes puede realmente ver, explicar y detener la plataforma en su entorno?
