Radware presento Agent Trust Management el 29 de septiembre de 2026 como una forma para que las empresas identifiquen agentes de IA, capturen intencion declarada, evaluen confianza de manera continua y controlen que acciones de aplicacion puede realizar un agente. La empresa dice que el producto esta disponible ahora como parte de Radware Cloud Application Protection services.
Esta es una noticia de seguridad de IA porque la superficie de control esta cambiando. Muchas herramientas de seguridad de aplicaciones se construyeron alrededor de usuarios humanos, bots, APIs y scripts de fraude. Los agentes de IA agregan otro patron. Pueden llegar en nombre de un usuario, navegar un sitio, investigar opciones, iniciar sesion, reservar viajes, completar checkout o interactuar con flujos sensibles de cuenta. Bloquear todo agente puede danar automatizacion util. Confiar en todo agente identificado crea riesgos claros para datos, fraude y procesos de negocio.
Que anuncio Radware
Radware dice que Agent Trust Management combina visibilidad de sesion sensible a prompts, identificacion de agentes en tiempo real, evaluacion continua de confianza y gobernanza basada en permisos. El producto usa headers de solicitud, comportamiento del cliente y respuestas directas del agente para identificar agentes conformes y no conformes con estandares. Para agentes compatibles con Web Bot Auth, Radware dice que puede usar verificacion criptografica.
La parte mas notable es la intencion declarada. Radware dice que el sistema captura activamente lo que el agente dice que intenta hacer y luego evalua si el comportamiento posterior sigue siendo coherente con esa intencion. La empresa aclara que la identidad por si sola no establece confianza. Un agente legitimo o identificable aun puede estar mal dirigido, comprometido o usarse para una tarea danina.
El producto puede aplicar permisos a flujos especificos. Radware da ejemplos como permitir navegacion mientras restringe login, creacion de cuenta o checkout. Su comunicado distribuido dice que la capacidad esta disponible ahora a traves de Radware Cloud Application Protection services.
Por que importa
El trafico de agentes convierte la seguridad de aplicaciones en un problema de integridad de tarea. Una decision tradicional de control de bots suele preguntar si una solicitud viene de automatizacion y si esa automatizacion es abusiva. El trafico agentico pregunta algo mas granular: merece este agente, en esta sesion y para este proposito declarado, acceso a este workflow?
Esa diferencia importa para comercio, finanzas, viajes y cualquier sitio con acciones autenticadas de cuenta. Un agente que investiga un producto es de menor riesgo que un agente que cambia datos de pago guardados, usa puntos de fidelidad, reserva un viaje no reembolsable o envia informacion personal regulada. La misma identidad de agente puede ser aceptable para una tarea e inaceptable para otra.
Los controles de prompt injection de Maetra para agentes de IA hacen el mismo punto desde el lado del operador. El momento peligroso suele estar entre una instruccion, el contexto que ve el agente y la accion de herramienta o aplicacion que sigue.
Que deben probar los compradores
Los equipos de seguridad deben preguntar como se captura la intencion, con que frecuencia se actualiza y que evidencia queda despues de una accion denegada o permitida. La intencion declarada puede ser contexto util, pero no es prueba de comportamiento benigno. El control necesita comparar intencion con navegacion, acceso a datos, uso de herramientas, senales de riesgo y limites de politica de negocio.
Tambien deben probar como la politica se mapea a flujos. Un despliegue practico necesita mas que allow y block. Debe distinguir navegar, buscar, comparar, iniciar sesion, crear cuenta, checkout, transferir, cancelar, enviar y cambiar configuracion. Algunas acciones pueden ser seguras para agentes autenticados. Otras pueden necesitar controles adicionales, confirmacion humana o rechazo.
Por ultimo, los compradores deben inspeccionar manejo de fallos. Si un agente no puede identificarse, rechaza una conversacion de intencion o cambia de tarea a mitad de sesion, el default mas seguro debe ser explicito y registrado.
Que sigue incierto
Las fuentes de Radware no prueban de forma independiente precision de deteccion, falsos positivos, resistencia a evasion ni resultados de clientes. La empresa tambien enmarca algunas estadisticas de mercado desde su propio analisis de amenazas, que deben tratarse como contexto del proveedor salvo verificacion separada.
La evidencia actual sostiene una conclusion mas estrecha: Radware convirtio la intencion de agentes y los permisos a nivel de workflow en un control principal de seguridad de aplicaciones. Es una senal de producto util incluso antes de que exista evidencia independiente de rendimiento.
Analisis de Maetra
La leccion de seguridad es que la identidad del agente es necesaria pero insuficiente. Las empresas necesitaran saber quien o que dice ser el agente, que usuario u organizacion representa, que tarea declara, que recursos toca, que accion intenta y si esa accion coincide con el alcance autorizado.
Para equipos que operan sus propios agentes, la misma estructura aplica internamente. Vinculen agentes a una tarea, inspeccionen prompt y tool call, revisen politica en el punto de accion y retengan evidencia del efecto final. Para equipos que exponen aplicaciones a agentes de terceros, los permisos sensibles a intencion pueden volverse tan importantes como la deteccion de bots y la autorizacion API.
El lanzamiento de Radware no prueba que el mercado resolvio la confianza en agentes. Muestra que el mercado pasa de preguntar si el trafico esta automatizado a preguntar si una accion automatizada especifica debe ser confiable.
Fuentes
Fuente primaria: blog Radware Agent Trust Management.
Corroboracion: comunicado Radware Agent Trust Management en GlobeNewswire.