F5 Workforce AI Security lleva la gobernanza de la IA a la ruta de red
F5 Workforce AI Security añadirá controles sin agentes para el uso de IA por parte de los empleados y las acciones de los agentes, pese a que la mayor parte de la gobernanza en el entorno laboral sigue centrándose en los prompts de chat. Anunciado el 9 de septiembre de 2026, el producto tiene prevista su disponibilidad general en octubre. Representa el intento más claro de F5 de gobernar tanto lo que los trabajadores envían a la IA como lo que esta hace con su autoridad.
El conflicto ya no se limita a empleados que pegan texto confidencial en un chatbot no aprobado. Los agentes de programación y los asistentes de IA pueden llamar herramientas, acceder a sistemas internos, modificar registros y actuar mediante las credenciales de los usuarios. F5 quiere que los equipos de seguridad inspeccionen esas interacciones en la ruta de red antes de que se ejecute una solicitud o acción insegura.
Este enfoque sitúa a F5 frente a proveedores de seguridad consolidados como Check Point y Netskope, que también presentan los controles de red como la respuesta a la shadow AI. La prueba más difícil concierne a la visibilidad y el contexto. Un producto de red debe reconocer identidades, intenciones y llamadas a herramientas sin convertirse en otra fuente de fricción, vigilancia o falsas alarmas.
F5 Workforce AI Security amplía el control a las acciones de los agentes
El cambio significativo es la decisión de F5 de tratar las acciones de los agentes como actividad de red gobernada, no simplemente como comportamiento de las aplicaciones.
Según el anuncio del producto, F5 Workforce AI Security descubrirá servicios de IA utilizados a través de navegadores y herramientas de desarrollo. Los administradores podrán aplicar políticas basadas en el servicio, el tipo de licencia, los archivos cargados y las reglas de datos.
El producto también está diseñado para atribuir las interacciones a usuarios y agentes. Registrará contexto como la intención, el riesgo evaluado y la decisión de política aplicada a cada interacción. Estos registros están destinados a respaldar la aplicación de políticas, las investigaciones y las auditorías de cumplimiento.
La función más relevante se refiere a las llamadas a herramientas. F5 afirma que el producto inspeccionará las llamadas a través de servidores Model Context Protocol y herramientas de agentes compatibles antes de su ejecución. MCP es un protocolo que permite a las aplicaciones de IA conectarse con herramientas, sistemas y datos mediante una interfaz común.
Una política podría permitir, bloquear o modificar una acción según la identidad, el riesgo de permisos o la exposición de datos sensibles. Esto va más allá de detectar la visita de un empleado a un sitio web de IA. Sitúa un punto de control entre la solicitud de un agente y el sistema que realizaría la acción solicitada.
F5 afirma que los controles abarcarán navegadores, interfaces de línea de comandos, agentes de programación, clientes MCP, entornos de ejecución de agentes y herramientas desarrolladas internamente que utilizan APIs públicas de modelos. La empresa planea integrar la aplicación de políticas con los entornos existentes de secure access service edge, conocidos habitualmente como SASE.
El despliegue propuesto no requiere otro cliente de endpoint. En su lugar, F5 sitúa la aplicación de políticas donde las interacciones de red pertinentes atraviesan su infraestructura. El descubrimiento pasivo puede analizar tráfico replicado fuera de la ruta de producción, mientras que las políticas activas operan en línea cuando se requiere intervención.
Esta distinción importa para los equipos de seguridad que ya gestionan entornos de endpoint saturados. Instalar otra extensión de navegador o agente local puede generar trabajo de compatibilidad, retrasos en el despliegue y una cobertura desigual. Una capa basada en red promete un despliegue más amplio mediante infraestructura que la organización ya controla.
Sin embargo, la palabra “sin agentes” no significa que el despliegue sea gratuito de esfuerzo. Las organizaciones siguen necesitando visibilidad del tráfico, integración de identidades, diseño de políticas, protocolos compatibles y puntos de aplicación correctamente ubicados. Los dispositivos remotos, las sesiones cifradas, las conexiones privadas y los modelos que se ejecutan localmente pueden complicar esa cobertura.
El anuncio también separa los hechos actuales de las capacidades futuras. F5 describe el producto como una oferta próxima y su lista de funciones utiliza lenguaje prospectivo. Los compradores aún no pueden considerar el lanzamiento de octubre como prueba independiente de cobertura, calidad de detección o fiabilidad en producción.
Esa brecha define la tensión central del artículo. La ubicación en la red proporciona a F5 un punto de control atractivo, pero su valor depende de la precisión con la que interprete interacciones de IA que cambian rápidamente.
Por qué la IA para empleados se convirtió en un problema de identidad
La seguridad de la IA para empleados ahora concierne a la autoridad delegada, porque un agente puede actuar mediante el acceso de una persona en lugar de limitarse a responder a la pregunta de esa persona.
Los controles tradicionales de shadow AI preguntan a qué aplicaciones acceden los empleados y qué información cargan. Esas preguntas siguen siendo importantes. Ya no son suficientes cuando un asistente puede abrir repositorios, consultar bases de datos, actualizar tickets o activar flujos de trabajo.
F5 describe esta condición como IA operando con autoridad prestada. Un agente puede utilizar permisos concedidos originalmente a un empleado, incluso cuando el agente carece de una identidad diferenciada y gobernable. Los equipos de seguridad deben determinar entonces si la acción refleja la intención y el rol autorizado del empleado.
La preocupación ya es visible en el trabajo de normalización. Un documento conceptual de NIST de 2026 examina cómo las empresas pueden identificar agentes de software y aplicar prácticas de autorización establecidas. El proyecto también considera cómo las organizaciones deberían vincular las acciones de un agente con personas responsables.
Esa vinculación se vuelve difícil cuando un usuario inicia varios agentes en múltiples sistemas. Cada agente podría heredar credenciales diferentes, llamar herramientas anidadas o delegar trabajo a otro servicio. Un registro de inicio de sesión convencional puede identificar la cuenta sin explicar la cadena de acciones resultante.
F5 quiere enriquecer ese registro con la intención de la interacción. Por ejemplo, la plataforma podría distinguir la generación de código de la síntesis de documentos o de los cambios administrativos. Ese contexto podría ayudar a un equipo de seguridad a separar una solicitud ordinaria de un uso inesperado de herramientas privilegiadas.
La clasificación de intenciones sigue siendo una inferencia, no una garantía. La misma solicitud puede producir acciones diferentes según el modelo, la descripción de la herramienta, el contexto recuperado y el estado del sistema. Un prompt de apariencia inofensiva también puede conducir a un agente hacia una operación sensible varios pasos después.
La guía de OWASP sobre MCP describe riesgos que incluyen el envenenamiento de herramientas, la inyección indirecta de prompts y los permisos excesivos. El envenenamiento de herramientas oculta instrucciones maliciosas en descripciones, definiciones de parámetros o contenido devuelto. Un agente puede seguir esas instrucciones incluso cuando el usuario nunca solicitó el comportamiento perjudicial.
Los permisos excesivos crean otro problema. Un servidor MCP podría solicitar acceso amplio cuando bastaría un permiso limitado de solo lectura. Un agente comprometido puede entonces convertirse en un delegado confundido, utilizando autoridad legítima para un propósito no previsto.
Estos riesgos explican por qué importan los controles previos a la ejecución. Bloquear un secreto filtrado después de que una herramienta ya haya modificado un registro de producción ofrece una protección limitada. La decisión debe producirse antes de que el sistema acepte la acción.
F5 cita su investigación State of Application Strategy de 2026 para mostrar con qué rapidez está surgiendo ese requisito. La encuesta de F5 informa de que el 66 por ciento de las organizaciones permite que la IA ajuste automáticamente políticas o configuraciones.
Esa cifra procede de la propia investigación de F5 y debe leerse en ese contexto. No muestra cuántas organizaciones conceden autonomía amplia ni cuán maduros son sus controles. Sí indica que los cambios iniciados por máquinas han ido más allá de experimentos aislados.
Para los compradores empresariales, el objetivo de seguridad pasa por tanto del bloqueo de aplicaciones a la gobernanza de acciones delegadas. Los equipos de seguridad necesitan registros que conecten al usuario, al agente, la herramienta solicitada, el permiso concedido, la decisión de política y la acción resultante.
Esto también es relevante para los equipos que construyen una base de conocimiento con capacidad de búsqueda. Los sistemas de IA pueden recuperar contexto interno útil y, al mismo tiempo, requerir límites estrictos en torno a las credenciales, los archivos confidenciales y las herramientas operativas.
La presión recae simultáneamente sobre los equipos de identidad, seguridad e infraestructura. Ninguno puede resolver el problema por sí solo cuando los agentes combinan permisos humanos, razonamiento de modelos, acceso a red y herramientas externas.
La ruta de red es la principal ventaja de F5 y su mayor apuesta
F5 apuesta a que la red sigue siendo el punto de aplicación más consistente incluso cuando la actividad de IA se extiende entre aplicaciones, modelos, agentes y herramientas.
Esta tesis se deriva de la posición existente de F5 en entrega de aplicaciones, seguridad de APIs y gestión de tráfico. En lugar de proteger un único chatbot o proveedor de modelos, la empresa quiere aplicar políticas donde los prompts, las respuestas y las solicitudes de herramientas se desplazan entre sistemas.
La estrategia empezó a tomar una forma más clara en 2025. F5 completó la adquisición de CalypsoAI e introdujo AI Guardrails para protección en tiempo de ejecución y AI Red Team para pruebas de seguridad. Estos productos abordan amenazas orientadas a los modelos, incluidos los intentos de inyección de prompts y jailbreak.
En junio de 2026, F5 lanzó su AI Security Platform más amplia y adquirió SurePath AI. SurePath aportó descubrimiento basado en red, clasificación de intenciones, detección de shadow AI y visibilidad de las llamadas a herramientas de agentes. F5 posicionó esas capacidades como la capa de descubrimiento para un ciclo continuo de seguridad.
El lanzamiento de la plataforma describió cuatro funciones conectadas: gobernanza, descubrimiento, pruebas de seguridad y protección en tiempo de ejecución. El descubrimiento identifica servicios y comportamientos de IA activos. Las pruebas detectan debilidades, mientras que las barreras de protección aplican políticas frente a esos riesgos.
En agosto, F5 añadió un AI Gateway que combina enrutamiento de modelos, controles MCP y barreras de protección en tiempo de ejecución. El gateway gobierna sistemas que las organizaciones colocan intencionadamente detrás de él. Workforce AI Security amplía la estrategia hacia la actividad de empleados que puede comenzar fuera de las rutas de desarrollo aprobadas.
En conjunto, estos componentes crean una división lógica del trabajo. El descubrimiento de Workforce identifica el uso autorizado y no autorizado. El gateway gobierna el tráfico aprobado de modelos y herramientas. Las pruebas de red team evalúan los sistemas, mientras que las barreras de protección aplican protecciones en tiempo de ejecución.
El principal argumento de F5 es la consistencia arquitectónica. Los controles funcionan independientemente de un proveedor de modelos o de una aplicación de empleados concreta. Una organización podría cambiar de modelos sin reconstruir cada política dentro de la consola administrativa de otro proveedor.
Esa independencia puede ser importante en entornos con múltiples modelos. Diferentes departamentos pueden utilizar asistentes comerciales, modelos privados, servicios de programación y agentes especializados. Cada servicio expone registros y controles administrativos distintos, mientras que algunos ofrecen una integración empresarial limitada.
Una capa de red puede normalizar al menos parte de esa actividad fragmentada. Puede asociar el tráfico con identidades empresariales, mantener registros centralizados y aplicar un proceso común de toma de decisiones. Los equipos de operaciones de seguridad pueden entonces exportar eventos a los sistemas existentes de monitorización y respuesta a incidentes.
Sin embargo, la normalización puede eliminar un contexto útil de la aplicación. El control nativo de un proveedor podría comprender un espacio de trabajo, un documento o una transacción con mayor precisión que un intermediario que observa el tráfico. F5 debe demostrar que sus clasificaciones conservan suficiente detalle para tomar decisiones significativas.
El tráfico cifrado presenta otra tensión de diseño. Las aplicaciones modernas protegen las sesiones precisamente para evitar que los intermediarios lean el contenido. La inspección puede requerir certificados gestionados, redirección del tráfico, integraciones compatibles u otras formas de descifrado controlado.
La actividad local crea otro punto ciego. Un agente que se ejecuta en el dispositivo de un desarrollador podría llamar a un modelo o herramienta local sin atravesar una ruta empresarial observable. Las conexiones directas, los puntos de acceso personales y los dispositivos no gestionados también pueden sortear la infraestructura prevista.
El enfoque de F5 es más sólido allí donde las organizaciones ya enrutan la actividad relevante a través de redes controladas o servicios SASE. Resulta menos claramente completo cuando el trabajo se desplaza entre entornos de ejecución locales, conexiones no gestionadas y protocolos propietarios cifrados.
Por tanto, la red es a la vez la ventaja de F5 y su apuesta. La empresa tiene experiencia operando en la ruta del tráfico, pero la seguridad de la IA exige una comprensión semántica que va más allá de los controles habituales de paquetes y aplicaciones.
Check Point y Netskope compiten por el mismo punto de control
F5 entra en una competencia activa entre proveedores de seguridad de red para convertirse en la capa de políticas entre los usuarios empresariales, los servicios de IA y los agentes autónomos.
Check Point ya comercializa controles de IA para la fuerza laboral que identifican aplicaciones, inspeccionan prompts, aplican protecciones de datos y distinguen los servicios aprobados. Su reciente AI Network Firewall amplía el mismo concepto al uso de IA por parte de los empleados, los agentes y las aplicaciones de IA.
Check Point también promueve un despliegue sin agentes mediante la infraestructura de firewall existente. Su AI Network Firewall afirma que puede detectar y gobernar el tráfico de IA sin una extensión de navegador, un cliente de endpoint ni una instalación independiente. Esto se solapa directamente con el posicionamiento centrado en la red de F5.
Netskope aborda la oportunidad desde los controles de security service edge y acceso a la nube. Su plataforma cubre IA en la sombra, IA empresarial gestionada, IA privada y actividad de agentes. Hace hincapié en la protección de datos, el conocimiento de las aplicaciones y la inspección en línea del tráfico en la nube.
Un informe de Netskope describe el cambio del mercado como una transición desde el descubrimiento de aplicaciones no autorizadas hacia la gobernanza de transacciones autónomas. También identifica la inyección de prompts, la ejecución de código malicioso y las infracciones posteriores de políticas como preocupaciones crecientes.
Estos competidores presionan a F5 en dos frentes. En primer lugar, las empresas pueden preferir ampliar una plataforma existente de security service edge o firewall. En segundo lugar, los proveedores establecidos pueden integrar controles de IA en acuerdos de seguridad y flujos operativos más amplios.
La respuesta de F5 es una conexión más explícita entre descubrimiento, pruebas, salvaguardas en tiempo de ejecución, políticas de gateway y actividad de la fuerza laboral. Busca que una única plataforma cubra tanto los sistemas de IA que consumen los empleados como las aplicaciones de IA que desarrollan las empresas.
Esa amplitud puede ser útil, pero también plantea interrogantes de integración. Una plataforma amplia debe compartir identidades, políticas, hallazgos y registros de auditoría entre componentes. Los nombres de productos reunidos en una consola no crean automáticamente un sistema de aplicación coherente.
Las adquisiciones de SurePath y CalypsoAI proporcionan tecnología especializada para el descubrimiento y la seguridad de modelos. F5 todavía debe demostrar con qué fluidez operan esas tecnologías junto con sus productos de gateway y entrega de aplicaciones. La calidad de la integración importará más que el tamaño de la cartera.
Otra diferencia competitiva se refiere a la gobernanza a nivel de acción. Detectar que un empleado utiliza un servicio de IA ya es una capacidad básica. La cuestión de mayor valor es si un producto puede identificar y controlar la operación concreta que un agente quiere que ejecute una herramienta.
MCP vuelve esa oportunidad más concreta porque estandariza partes de la conexión entre agentes y herramientas. Un gateway puede inspeccionar herramientas nombradas, parámetros, identidades y reglas de políticas. Sin embargo, MCP es solo una vía hacia los sistemas empresariales.
Los agentes también llaman a API convencionales, ejecutan comandos, acceden a navegadores o interactúan con conectores propietarios. Un producto que gobierna MCP de forma exhaustiva aún puede pasar por alto actividad significativa en otros lugares. Los compradores deberían examinar la cobertura de los flujos de trabajo reales, no solo las listas de verificación de protocolos.
Por tanto, la competencia girará en torno a la profundidad, más que a las afirmaciones básicas de visibilidad. Los equipos de seguridad compararán los clientes compatibles, la fidelidad de identidad, la clasificación de datos, la cobertura de herramientas, la latencia de las políticas, el esfuerzo de despliegue y las opciones de exportación.
También evaluarán cómo maneja cada producto las excepciones. Los desarrolladores a menudo necesitan capacidades que las políticas generales de la empresa prohibirían. Un sistema funcional debe admitir permisos limitados y rutas de aprobación documentadas sin animar a los usuarios a eludir los controles.
La presencia de F5 en la entrega de aplicaciones puede abrirle puertas entre clientes existentes. Check Point y Netskope cuentan con sus propias ventajas de infraestructura. Ningún proveedor ha establecido mediante evidencia pública que una arquitectura de red capture todas las interacciones significativas de IA de la fuerza laboral.
Esto convierte la adquisición en una cuestión de adecuación. El producto más sólido será el que gobierne las rutas de tráfico y los flujos de trabajo de agentes reales de una organización, no el que use el lenguaje de categoría más amplio.
La gobernanza sin agentes sigue teniendo preguntas sin respuesta
F5 ha anunciado una ambiciosa capa de control, pero aún no ha publicado la evidencia de producción necesaria para validar sus afirmaciones centrales.
La primera incertidumbre es la cobertura. F5 enumera navegadores, herramientas de línea de comandos, agentes de programación, clientes MCP y software personalizado que utiliza API públicas de modelos. No ha proporcionado públicamente una matriz de compatibilidad detallada que muestre qué productos, versiones, protocolos y patrones de despliegue reciben una inspección completa.
La segunda incertidumbre es la calidad de la clasificación. Las políticas basadas en intención dependen de interpretar con precisión una interacción antes de aplicarlas. Los falsos negativos permiten comportamientos riesgosos, mientras que los falsos positivos interrumpen el trabajo legítimo y reducen la confianza en el sistema.
La clasificación se vuelve más difícil en flujos de trabajo prolongados de agentes. Una solicitud puede comenzar como investigación rutinaria y más tarde invocar una herramienta privilegiada. El sistema debe conservar suficiente contexto para evaluar cada paso sin tratar el prompt inicial como la intención completa.
La tercera incertidumbre se refiere a la modificación. F5 afirma que las políticas pueden permitir, bloquear o modificar acciones de agentes. Modificar una solicitud puede ser más seguro que rechazar un flujo de trabajo completo, pero también puede alterar el significado o producir comportamientos posteriores inesperados.
Por ejemplo, eliminar un campo sensible de una llamada a una herramienta podría proteger los datos y, al mismo tiempo, dejar la transacción incompleta. Redirigir una solicitud hacia un modelo aprobado podría alterar el contexto disponible o la calidad de la respuesta. Los administradores necesitan registros claros de cada intervención.
El cuarto problema es la latencia. El descubrimiento pasivo puede ejecutarse fuera de la ruta de producción, pero la aplicación previa a la ejecución debe tomar una decisión a tiempo. Los asistentes de programación y los agentes interactivos se vuelven frustrantes cuando cada llamada a una herramienta introduce una demora perceptible.
F5 no ha publicado mediciones independientes de la latencia en las decisiones de políticas, el rendimiento o el desempeño bajo cargas de trabajo complejas de agentes. Los compradores deberían esperar pruebas de producción en lugar de asumir que la ubicación en la red no conlleva costes operativos.
La privacidad es otra preocupación. Una auditabilidad detallada puede requerir el registro de prompts, respuestas, información de archivos, identidades de usuarios, parámetros de herramientas y resultados de políticas. Esos registros pueden contener material confidencial o regulado incluso cuando se bloquea la acción original.
Los equipos de seguridad deben definir períodos de retención, restricciones de acceso, reglas de redacción, almacenamiento regional y procedimientos de incidentes para los propios datos de monitorización. Un sistema de visibilidad puede crear un repositorio secundario sensible si esos controles siguen siendo imprecisos.
El despliegue sin agentes también desplaza la responsabilidad, en lugar de eliminarla. Los equipos de red deben enrutar correctamente el tráfico. Los equipos de identidad deben mantener asignaciones fiables. Los equipos de seguridad deben crear políticas, mientras que los responsables de aplicaciones comprueban si estas preservan el comportamiento previsto.
Las organizaciones deberían cuestionar cualquier sugerencia de visibilidad instantánea y completa. La cobertura dependerá de la arquitectura, el acceso gestionado, el cifrado y la integración. La pregunta relevante es qué omite el producto según el diseño real del cliente.
Las estadísticas y descripciones de funciones proporcionadas por F5 también requieren un tratamiento cuidadoso. La cifra comunicada del 66 por ciento de adopción respalda la urgencia de controles automatizados, pero no valida el producto de F5. La disponibilidad de funciones no demuestra precisión de detección ni reducción de tasas de incidentes.
La disponibilidad general marcará el inicio de una evaluación significativa, no su final. Los despliegues de referencia, las pruebas de terceros, las limitaciones documentadas y la evidencia de clientes determinarán si la plataforma cumple sus afirmaciones.
Un piloto sensato debería incluir aplicaciones de chat autorizadas, cuentas personales, herramientas de programación, API internas y varios servidores MCP. Debería probar la actividad ordinaria junto con inyección de prompts, permisos excesivos, cargas de datos sensibles y solicitudes ambiguas de herramientas.
Los equipos deberían medir por separado la cobertura y las decisiones erróneas. Un producto puede detectar muchos servicios y, aun así, interpretar mal sus interacciones. También puede clasificar correctamente los prompts mientras no detecta tráfico local o directo.
El resultado debería ser un límite trazado, en lugar de un veredicto binario. Los compradores necesitan saber dónde ofrece F5 un control fiable, dónde otra herramienta aporta contexto y dónde siguen siendo necesarias salvaguardas procedimentales.
Tres señales mostrarán si la estrategia de F5 funciona
El lanzamiento de octubre, la evidencia a nivel de acción y la respuesta competitiva revelarán si F5 ha construido una capa de gobernanza real o una atractiva narrativa de plataforma.
La primera señal es el lanzamiento de disponibilidad general de octubre de 2026. F5 debe proporcionar documentación concreta de despliegue, listas de servicios compatibles, ejemplos de políticas, integraciones de identidad y distinciones claras entre la observación pasiva y la aplicación en línea.
Una matriz de compatibilidad detallada reforzaría el argumento de que el producto cubre más que demostraciones controladas. La falta de documentación o unos flujos de trabajo compatibles limitados debilitarían la afirmación de visibilidad en toda la empresa.
La segunda señal es la evidencia de acciones reales de agentes. Los clientes deberían buscar resultados medidos en llamadas a herramientas MCP, agentes de programación, asistentes de navegador, clientes de línea de comandos y API propietarias. La evidencia útil incluirá tasas de detección, decisiones erróneas, latencia y condiciones de elusión.
Los casos de estudio deberían explicar qué observó F5 y qué controles detuvieron una acción. Las afirmaciones generales sobre visibilidad tendrán menos peso que los ejemplos que conecten identidades, permisos de herramientas, datos sensibles y resultados finales de políticas.
Las evaluaciones independientes serían especialmente valiosas. El diseño de F5 parece técnicamente plausible, pero las demostraciones de la empresa no pueden reproducir todos los protocolos cifrados, entornos de ejecución locales o cadenas de agentes inusuales que existen dentro de las grandes empresas.
La tercera señal es cómo responden Check Point, Netskope y otros proveedores de seguridad. Los competidores pueden ampliar los controles a nivel de acción, profundizar la compatibilidad con MCP o combinar telemetría de navegador y red. Una igualación rápida convertiría el anuncio de F5 en una referencia para toda la categoría.
Una respuesta más lenta sugeriría que F5 ha reunido una combinación diferenciada mediante SurePath, CalypsoAI y su plataforma de red existente. Las migraciones de clientes o los despliegues consolidados aportarían evidencia más sólida que las comparaciones de funciones por sí solas.
Las empresas también deberían vigilar si los proveedores convergen en torno a estándares de identidad para agentes. Las identidades de agente coherentes y la autorización con alcance definido harían que las políticas de red fueran más fiables. Los enfoques fragmentados obligarían a las plataformas de seguridad a inferir más contexto a partir del tráfico.
F5 Workforce AI Security responde a un cambio real: del uso de la IA en conversaciones a su uso para ejecutar acciones. Su posición en la red ofrece a la empresa una vía creíble hacia una aplicación centralizada de políticas, especialmente para las organizaciones que ya utilizan infraestructura de F5.
La cuestión sin resolver es si esa vía captura suficiente contexto en los flujos de trabajo modernos basados en agentes. Los equipos de seguridad deberían probar el producto frente a permisos reales, herramientas privadas y casos de fallo antes de considerar que “sin agentes” equivale a una cobertura integral.
A medida que se acerca octubre, los compradores pueden prepararse inventariando el tráfico de IA, mapeando los permisos de los agentes e identificando las acciones que requieren aprobación antes de su ejecución. ¿Qué tres flujos de trabajo causarían el mayor daño si un agente utilizara incorrectamente una autoridad prestada? Empiece por ahí y después evalúe si F5 Workforce AI Security puede detectar, explicar y detener cada uno sin obstaculizar el trabajo habitual.
