An AI agent can present a valid enterprise credential, operate within an approved role and still take a dangerous action. That is the control gap Radware believes the industry must address: identity establishes who or what is making a claim, but runtime evidence determines whether the agent should be trusted to act.
An Authenticated Agent Can Still Be Dangerous
Consider a finance agent authorized to retrieve invoices and prepare payment recommendations. It authenticates with a valid enterprise token and uses APIs included in its approved role. During a task, however, it processes a supplier document containing a hidden indirect prompt injection. The instruction changes the agent's plan, causes it to invoke an unexpected tool and sends it toward a payment-data API through an unusual sequence of requests.
From a conventional identity perspective, very little appears wrong. The credential is valid. The account is active. The individual API calls may be permitted. Yet the agent's intent and execution path have moved outside the business purpose for which access was granted.
This is why AI identity risk cannot be solved by authentication and entitlement management alone. The dangerous agent may not be an intruder. It may be an approved identity whose reasoning has been manipulated, whose context has been poisoned, whose credentials have been misused or whose behaviour has drifted.
The Industry Is Confusing Identity with Trust
Most AI identity programs begin with the right governance activities: discover agents, create an inventory, assign owners, issue credentials, apply least privilege and review the lifecycle. These controls establish what should exist and what each agent should be allowed to do.
The mistake is assuming that a governed identity remains trustworthy whenever it presents a valid credential. Authentication proves possession of an authentication factor. Authorization establishes permitted actions. Neither proves that the agent's current goal, context, tool path or behaviour remains aligned with the purpose that was approved.
Treating an agent as another service account makes the problem worse. A scheduled process generally follows a stable execution path. An AI agent interprets objectives and selects among multiple tools, data sources, APIs and downstream actions. Two runs initiated with the same credential can produce materially different behaviour and risk.
An agent inventory is therefore essential but insufficient. It records the declared agent. It does not automatically tell an application which actor is arriving, whether the actor matches the declaration, or whether the action being attempted should still be trusted.
AI Identity Has Three Layers
A useful technical model separates declared identity, observed identity, and runtime trust.
Declared identity is the governance record: the agent's owner, purpose, model and orchestration framework, credentials, approved APIs, accessible data, available tools, delegation rights, environment and lifecycle state.
Observed identity is the actor visible at runtime. It is established or classified using the signals available at the application, API, agent platform, tool and traffic layers. These signals may include credentials, source and platform information, request characteristics, API sequences, tool calls, model interactions and behavioural patterns.
Runtime trust is the contextual decision about whether that observed actor should perform this action now. Trust is not a permanent label. A known agent may be trusted to retrieve public information but not to change an account. An approved agent may require additional scrutiny when it calls a new tool, reaches an undocumented API, changes its request sequence or behaves inconsistently with its declared purpose.
The Missing Control Is Runtime Agent Trust
This leads to Radware's central point of view: AI identity governance requires a runtime trust decision point.
Identity governance provides the control record. Runtime Agent Trust evaluates live evidence and converts policy into action. The decision process should connect five elements: the claimed actor, the authority it inherited, the context of the request, the behaviour being observed and the potential impact of the action.
The result should not be limited to a binary allow-or-block decision. Depending on risk, the control can allow, monitor, rate-limit, restrict a tool, require human approval, isolate a workflow or block the action. The outcome should then update the agent's trust posture and remain available for audit and investigation.
Governance Must Reach Tools and Delegation
Every enterprise agent still needs a named human owner, a defined business purpose, agent-specific credentials, scoped permissions, an expiration date and a review process. These are foundational controls, not optional administration.
For AI agents, however, tool access is the practical expression of privilege. A tool may let an agent query a database, send an email, execute code, modify a record, initiate a payment, create a ticket, change a configuration or delegate work. Each high-impact tool requires explicit policy, action limits, logging and a method to revoke access quickly.
Delegation also requires lineage. If Agent A acts for a user, delegates to Agent B and Agent B invokes Tool C using Credential D, the organization should be able to reconstruct the requester, both agents, the authority passed between them, the data accessed, the policy decisions and the final outcome. Otherwise, ownership exists on paper while accountability disappears at runtime.
Where Radware Makes Agent Trust Enforceable
Radware is positioned at the runtime surfaces where autonomous identity becomes observable action: applications, APIs, automated traffic, prompts, tools and agent workflows.
IAM, IGA, PAM, and agent registries remain responsible for identity records, entitlements, credentials, ownership, and lifecycle. Radware complements those systems by evaluating what the agent is doing with that authority and enforcing a decision where the action reaches an application, API, model or tool.
This is an architectural advantage, not simply a collection of adjacent products. Radware has deep experience analysing application and API behaviour, distinguishing legitimate automation from abuse, identifying intent and applying real-time protections. Runtime Agent Trust extends that discipline to autonomous actors that may be authenticated while behaving unsafely.
The Radware point of view:
Identity establishes which agent is making a claim.
Runtime evidence determines whether the claim should be trusted.
Application, API, model, and tool controls turn that decision into action.
Radware’s Bot and Agent Management provides visibility and control for AI agents and crawlers reaching applications. Behaviour-based detection identifies and classifies automated traffic by source, type and intent, including automation that does not reliably declare itself. Organizations can then apply granular actions such as allow, block or rate-limit based on business policy.
Radware API Security supplies the live API context. It discovers APIs, including shadow and undocumented endpoints, maps production behaviour and API sequences, and protects against anomalous activity and business-logic abuse. For an AI identity, this helps determine not merely whether its token may call an API, but whether the endpoints, sequence, volume and data path match the agent's expected purpose.
Radware Agentic AI Protection provides visibility across agents, tools, relationships and interactions. It monitors actions and intent, applies behavioural guardrails, controls tool access and helps address threats such as goal hijacking, indirect prompt injection, anomalous behaviour and unsafe tool use.
Radware LLM Firewall protects the prompt and response channel that shapes agent decisions. It inspects model inputs and outputs for prompt injection, sensitive-data leakage, unsafe content and policy violations. This closes a critical gap because an agent can remain correctly authenticated while untrusted content manipulates its reasoning.
These capabilities form one runtime trust loop: recognize and classify the actor, understand its application and API context, observe its model and tool interactions, evaluate behaviour and intent and enforce a proportional response. Radware does not need to become the identity system of record to make AI identity governance effective. Its role is to make the governance decision enforceable where the agent acts.
A Practical Adoption Model
Organizations do not need to wait for a perfect standard. They can begin with high-impact agents: those with write access, customer or regulated data, internal API access, privileged tools, financial authority, third-party dependencies or the ability to delegate. External AI agents and crawlers reaching public applications should be included, even when the organization has not deployed its own agents.
First, discover internal agents, accessible tools and inbound agent traffic. Second, assign each enterprise agent a named owner and declared purpose. Third, map credentials, APIs, data, tools, downstream agents and delegation paths. Fourth, define expected behaviour and the conditions that change trust. Fifth, enforce graduated outcomes and preserve complete execution lineage.
The controls should be tested against realistic failure modes: valid credentials used from an unexpected context, indirect prompt injection, abnormal API sequences, access to an unauthorized tool, excessive data retrieval and recursive agent delegation. A kill switch should be tested before an incident, not invented during one.
This model supports adoption rather than obstructing it. Business teams receive a defined path for deploying agents. Identity teams retain ownership and lifecycle discipline. Application-security teams gain runtime evidence and enforcement. CISOs can demonstrate not only which agents were approved, but how their actions were evaluated and controlled.
The Five-Question Agent Trust Test
A security leader evaluating AI identity readiness should demand clear answers to five questions:
- Can we identify and classify the agent accessing an application or API, including agents that do not declare themselves reliably?
- Can we connect the observed actor to its owner, purpose, credentials, tools, data access, and delegation chain?
- Can we detect when an authenticated agent's behaviour or apparent intent diverges from what was approved?
- Can we enforce a proportional response immediately, from allow and rate-limit to approval, isolation, or block?
- Can we reconstruct the complete identity, decision, and execution path after an incident?
If any answer is no, the AI identity program has a runtime trust gap.
The Bottom Line
AI agents turn automation into an identity problem. Autonomy then turns identity into a continuous runtime trust problem.
The industry is right to emphasize inventory, ownership, least privilege, and lifecycle management. It is wrong to assume those controls remain sufficient once an agent begins to reason, select tools, call APIs, and delegate work. A valid identity is the beginning of a trust decision, not the end of one.
Radware's role is the runtime trust decision point. Radware Bot and Agent Management, Agentic AI Protection, API Security and LLM Firewall connect agent identity to the application, API, model, tool and behavioural evidence needed to determine whether an action should proceed.
The defining question for the agent economy is not simply, 'Does this agent have access?' It is, 'Can we identify the agent, determine whether its current behaviour still matches its purpose, and change the decision the moment it no longer deserves our trust?