They must account for delegated authority, remote actions, and destination permissions, not just code or model behaviour. An agent can be unchanged internally while its security meaning changes as soon as its available operations or identity path changes.
Why Agent Reviews Need a Different Assumption Set
Security reviews for AI agents start from a different question than ordinary software assurance: what can this system do on behalf of someone, and to whom or what can it reach? That shifts the review from static code quality or model output quality toward delegated authority, request origin, execution scope, and the destinations an agent can touch.
That means the same model or codebase can be acceptable in one deployment and risky in another. If the agent can open tickets, send messages, move money, invoke APIs, or write to production systems, the meaningful security property is not only how it behaves in isolation but how its granted authority changes the blast radius of a mistake or compromise.
For that reason, reviews must examine the control plane around the agent as much as the agent itself. An agent with tight prompts but broad entitlements is materially different from an agent with modest reasoning ability but tightly scoped action rights, especially when actions are remote, persistent, or hard to reverse.
What Changes in the Review Scope
Ordinary software assurance often emphasises input handling, business logic, dependency risk, and secure coding. Agent reviews add questions about whether the system can impersonate a user, carry standing credentials, chain actions across tools, or continue acting after the original request should have expired. The review must therefore treat identity, delegation, and authorisation as first-class properties of the design.
That is where action boundaries matter most. A secure agent review asks whether each action is independently authorised, whether the destination service accepts the agent’s identity as intended, and whether the agent can reach systems that the human requester could not reasonably access directly.
This also changes how you assess change. A model update might be low risk if its permissions stay unchanged, while a routing or integration change may be high risk even if the model weights are untouched. The security meaning changes when the agent’s reachable tools, scopes, or downstream privileges change.
AI Agent Authorisation Guide is a useful reference point for thinking about least privilege, task-scoped access, and per-action decisions in that review model. For deployment teams, Zero Trust for AI Agents reinforces the practical idea that the agent, the request, and the resource each need explicit verification.
What Usually Fails First in Practice
The most common failure is to review the agent as if it were just another application component. That misses the fact that agents may act across systems, use tokens on a user’s behalf, and make decisions whose consequences are external to the application boundary. A benign-seeming prompt flow can become a high-impact control failure if the agent can reach sensitive APIs, alter records, or initiate privileged workflows.
Another common mistake is over-trusting internal controls because the agent is “just internal.” Internal status does not reduce the need to review destination permissions, especially when the agent can read from one system and write to another. The risk is not only misuse by an attacker, but also unintended cross-system action caused by bad instructions, prompt injection, or overly broad orchestration.
That is why agent reviews should look at failure modes that ordinary software assurance often treats as secondary: excessive agency, confused-deputy behaviour, delegated access that outlives the task, and poor attribution of who authorised the action. When those conditions exist, a security issue may not look like a code defect at all, it may look like a legitimate action taken under the wrong authority.
AI Agent Observability, Audit and Incident Response Guide fits this review because attribution, logging, and revocation are part of the control story. Shadow AI and AI Agent Discovery Guide is relevant where the review must first determine whether the organisation even knows which agents are active and what they can access.
Risk and Threat Considerations
Agent reviews carry a distinct exposure because compromise or misuse can turn delegated authority into rapid downstream impact. A system that is safe to run locally may become dangerous once it can authenticate to production services, use persistent tokens, or perform actions that humans would normally gate manually.
Failure mechanism: The weakness is usually not “the model is wrong” but “the agent was allowed to act with authority that exceeded the trust placed in the request, the task, or the operator.” That creates a path for prompt injection, stolen credentials, or simple operator error to become a real-world action against connected systems.
Impact: The likely result is unauthorised access, destructive or irreversible operations, data exposure, or lateral movement through trusted integrations. In agentic environments, one mis-scoped permission can amplify a small error into a multi-system incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST AI RMF and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent reviews must assess delegated authority and misuse of agent privilege. |
| ASI02 — Tool Misuse | The question centers on remote actions and tool reach beyond model behavior. | |
| ASI09 — Human-Agent Trust Exploitation | Reviews must consider trust placed in agent outputs and requests. | |
| Recommendation — Review agent permissions per action and remove excess privilege. Constrain tool access to approved actions and destinations. Require independent checks before allowing high-impact agent actions. | ||
| NIST AI RMF | Govern | Agent assurance depends on governance, accountability, and role clarity. |
| Recommendation — Define accountability, oversight, and escalation for agent deployments. | ||
| OWASP ASVS | V8 — Authorization | Agent security reviews hinge on what actions the system is allowed to perform. |
| Recommendation — Verify that each sensitive action is explicitly authorized. | ||
Practitioner Guidance
What to verify: Confirm who the agent acts for, which identity it uses, which actions are independently authorised, and whether those permissions are narrower than the destinations it can reach. If any of those answers are unclear, the review is not complete.
Common mistake: Do not accept “the model is sandboxed” as a sufficient control statement if the agent still has broad API access, write permissions, or long-lived tokens. Sandbox boundaries do not compensate for excessive delegated authority.
What good looks like: A mature review produces an explicit map of agent identity, action scope, destination permissions, and revocation path, plus evidence that high-impact actions are either blocked, time-bound, or separately approved.
Practitioner takeaway: The key difference is not that agents are “smarter” than ordinary software, but that they can carry authority into places ordinary code could not safely reach, so the review must judge authority and destination risk as carefully as correctness.