Radware a introduit Agent Trust Management le 29 septembre 2026 comme moyen pour les entreprises d identifier les agents IA, de capturer leur intention declaree, d evaluer la confiance en continu et de controler quelles actions applicatives un agent peut effectuer. L entreprise dit que le produit est disponible maintenant dans Radware Cloud Application Protection services.
C est une actualite de securite IA parce que la surface de controle change. Beaucoup d outils de securite applicative ont ete concus pour utilisateurs humains, bots, API et scripts de fraude. Les agents IA ajoutent un autre schema. Ils peuvent arriver pour le compte d un utilisateur, naviguer sur un site, rechercher des options, se connecter, reserver un voyage, terminer un paiement ou interagir avec des workflows de compte sensibles. Bloquer tous les agents peut nuire a une automatisation utile. Faire confiance a tout agent identifie cree des risques evidents pour les donnees, la fraude et les processus metier.
Ce que Radware a annonce
Radware dit qu Agent Trust Management combine visibilite sessionnelle sensible au prompt, identification d agents en temps reel, evaluation continue de confiance et gouvernance par permission. Le produit utilise headers de requete, comportement cote client et reponses directes des agents pour identifier les agents conformes ou non aux standards. Pour les agents compatibles Web Bot Auth, Radware dit pouvoir utiliser une verification cryptographique.
La partie la plus notable est l intention declaree. Radware dit que le systeme capture activement ce que l agent dit vouloir faire, puis evalue si le comportement ulterieur reste coherent avec cette intention. L entreprise precise que l identite seule n etablit pas la confiance. Un agent legitime ou identifiable peut etre mal oriente, compromis ou utilise pour une tache nuisible.
Le produit peut ensuite appliquer des permissions a des workflows specifiques. Radware donne des exemples comme autoriser la navigation tout en restreignant connexion, creation de compte ou paiement. Le communique distribue dit que la capacite est disponible maintenant via Radware Cloud Application Protection services.
Pourquoi cela compte
Le trafic d agents transforme la securite applicative en probleme d integrite de tache. Une decision classique de controle de bots demande souvent si une requete vient d une automatisation et si cette automatisation est abusive. Le trafic agentique pose une question plus granulaire: cet agent, dans cette session, pour cette finalite declaree, merite-t-il l acces a ce workflow?
Cette difference compte pour le commerce, la finance, le voyage et tout site avec actions de compte authentifiees. Un agent qui recherche un produit est moins risque qu un agent qui change des moyens de paiement, utilise des points de fidelite, reserve un voyage non remboursable ou soumet des informations personnelles reglementees. La meme identite d agent peut etre acceptable pour une tache et inacceptable pour une autre.
Les controles Maetra contre l injection de prompt pour agents IA font le meme constat cote operateur. Le moment dangereux est souvent l ecart entre une instruction, le contexte vu par l agent et l action d outil ou d application qui suit.
Ce que les acheteurs devraient tester
Les equipes securite devraient demander comment l intention est capturee, a quelle frequence elle est rafraichie et quelle preuve reste apres une action refusee ou permise. L intention declaree est un contexte utile, mais ce n est pas une preuve de comportement benin. Le controle doit comparer intention, navigation, acces donnees, usage d outil, signaux de risque et limites de politique metier.
Elles devraient aussi tester le mapping entre politique et workflows. Un deploiement pratique exige plus que allow et block. Il doit distinguer parcourir, chercher, comparer, se connecter, creer un compte, payer, transferer, annuler, soumettre et changer les parametres. Certaines actions peuvent etre sures pour des agents authentifies. D autres peuvent exiger controle renforce, confirmation humaine ou refus.
Enfin, les acheteurs devraient examiner la gestion d echec. Si un agent ne peut pas s identifier, refuse la conversation d intention ou change de tache en cours de session, le default le plus sur doit etre explicite et journalise.
Ce qui reste incertain
Les sources de Radware ne prouvent pas independamment l exactitude de detection, les faux positifs, la resistance a l evasion ou les resultats clients. L entreprise presente aussi certaines statistiques marche depuis sa propre analyse de menaces, qui doit rester du contexte fournisseur sauf verification separee.
L evidence actuelle supporte une conclusion plus etroite: Radware fait de l intention des agents et des permissions par workflow un controle de securite applicative de premier plan. C est un signal produit utile meme avant des preuves de performance independantes.
Analyse Maetra
La lecon de securite est que l identite d agent est necessaire mais insuffisante. Les entreprises devront savoir qui ou quoi l agent pretend etre, quel utilisateur ou organisation il represente, quelle tache il declare, quelles ressources il touche, quelle action il tente et si cette action correspond au perimetre autorise.
Pour les equipes qui operent leurs propres agents, la meme structure s applique en interne. Liez les agents a une tache, inspectez prompt et appel d outil, verifiez la politique au point d action et conservez la preuve de l effet final. Pour les equipes exposant des applications a des agents tiers, les permissions sensibles a l intention peuvent devenir aussi importantes que la detection de bots et l autorisation API.
Le lancement de Radware ne prouve pas que le marche a resolu la confiance des agents. Il montre que le marche passe de la question du trafic automatise a la question de savoir si une action automatisee precise doit etre digne de confiance.
Sources
Source primaire: blog Radware Agent Trust Management.
Corroboration: communique Radware Agent Trust Management sur GlobeNewswire.