Radware introduced Agent Trust Management on 29 September 2026, positioning it as a way for businesses to identify AI agents, capture declared intent, assess trust continuously and control which application actions an agent may perform. The company says the product is available now as part of Radware Cloud Application Protection services.
This is an AI security story because the control surface is changing. Many application-security tools were built around human users, bots, APIs and fraud scripts. AI agents add a different pattern. They may arrive on behalf of a user, navigate a site, research options, log in, book travel, complete checkout or interact with sensitive account workflows. Blocking every agent may harm useful automation. Trusting every identified agent creates obvious data, fraud and business-process risk.
What Radware announced
Radware says Agent Trust Management combines prompt-aware, session-level visibility, real-time agent identification, continuous trust assessment and permission-based governance. The product uses request headers, client-side behavior and direct agent responses to identify both standards-compliant and non-compliant agents. For agents that support Web Bot Auth, Radware says it can use cryptographic verification.
The most notable part is declared intent. Radware says the system actively captures what an agent says it is trying to do, then evaluates whether later behavior remains consistent with that intent. The company is careful that identity alone does not establish trust. A legitimate or identifiable agent can still be misdirected, compromised or used for a harmful task.
The product can then apply permissions to specific workflows. Radware gives examples such as allowing browsing while restricting login, account creation or checkout. Its distributed press release says the capability is available now through Radware Cloud Application Protection services.
Why this matters
Agent traffic turns application security into a task-integrity problem. A traditional bot-control decision often asks whether a request comes from automation and whether that automation is abusive. Agentic traffic asks a more granular question: does this agent, in this session, for this stated purpose, deserve access to this workflow?
That difference matters for commerce, finance, travel and any site with authenticated account actions. An agent researching a product is a lower-risk actor than an agent changing stored payment details, using loyalty points, booking a non-refundable trip or submitting regulated personal information. The same agent identity may be acceptable for one task and unacceptable for another.
Maetra's prompt injection controls for AI agents makes the same point from the operator side. The dangerous moment is often the gap between an instruction, the context the agent sees and the tool or application action that follows.
What buyers should test
Security teams should ask how intent is captured, how often it is refreshed and what evidence remains after a denied or permitted action. Declared intent can be useful context, but it is not proof of benign behavior. The control needs to compare intent with navigation, data access, tool use, risk signals and business-policy boundaries.
They should also test how policy maps to workflows. A practical deployment needs more than allow and block. It should distinguish browse, search, compare, login, create account, checkout, transfer, cancel, submit and change settings. Some actions may be safe for authenticated agents. Others may need step-up controls, human confirmation or a refusal.
Finally, buyers should inspect failure handling. If an agent cannot identify itself, refuses an intent conversation or changes task mid-session, the safer default should be explicit and logged.
What remains uncertain
Radware's sources do not independently prove detection accuracy, false-positive rates, evasion resistance or customer outcomes. The company also frames some market statistics from its own threat analysis, which should be treated as vendor context unless verified separately.
The current evidence does support a narrower conclusion: Radware has made agent intent and workflow-level permissions a first-class application-security control. That is a useful product signal even before independent performance evidence exists.
Maetra analysis
The security lesson is that agent identity is necessary but insufficient. Enterprises will need to know who or what the agent claims to be, what user or organization it represents, what task it says it is doing, which resources it touches, which action it attempts and whether that action matches the authorized scope.
For teams operating their own agents, the same structure applies internally. Bind agents to a task, inspect the prompt and tool call, check policy at the point of action, and retain evidence of the final effect. For teams exposing applications to third-party agents, intent-aware permissions may become as important as bot detection and API authorization.
Radware's launch is not proof that the market has solved agent trust. It is evidence that the market is moving from asking whether traffic is automated to asking whether a specific automated action should be trusted.
Sources
Primary source: Radware Agent Trust Management blog.
Corroboration: Radware Agent Trust Management release on GlobeNewswire.