Traditional AppSec often assumes predictable inputs, static trust boundaries, and controlled execution paths. Agents can change behavior mid-session, call multiple tools, and amplify a small permission mistake into broader access or data exposure. If teams only test prompts or code, they miss runtime abuse, authorization drift, and cross-system impact.
Why agent risk does not behave like ordinary application risk
Agentic systems do not just process input and return output. They can decide when to invoke tools, chain actions across systems, reuse context across steps, and continue operating after the original user request has ended. That breaks the normal AppSec assumption that a request maps cleanly to one execution path with one trust boundary. For this reason, teams need agent-specific guidance such as the OWASP Top 10 for Agentic Applications 2026, not just generic secure coding checklists.
Once an agent can select tools, the real risk shifts from prompt quality to permission design, orchestration logic, and what the system allows after the model makes a decision. A narrow input flaw can become a broader failure if the agent is allowed to read sensitive data, trigger downstream workflows, or combine actions across services. That is why simple tests for injection or unsafe code are not enough. In practice, many security teams discover agent exposure only after an apparently minor permission choice has already been exercised across multiple systems.
How the control model changes when the system can act
Normal AppSec usually treats the application as the actor. With agents, the model must separate the user, the model, the orchestration layer, and each tool or API the agent can reach. The question is not only whether a prompt is safe, but whether the agent is allowed to do anything harmful even when the prompt is entirely legitimate. That includes overbroad tool scopes, weak approval gates, hidden privilege inheritance, and context leakage between tasks. For broader AI governance context, the NIST AI Risk Management Framework is useful because it frames the need to govern AI behaviour, not just software defects.
A practical agent review therefore has to ask different questions from ordinary AppSec. For example:
- Can the agent change state without fresh authorisation?
- Do tools inherit more access than the user intended?
- Can one task’s context influence the next task in a way that exposes data?
- Is there a reliable approval point before external side effects occur?
These checks matter because agent failures often arise in the space between components, not inside one codebase. A prompt filter may be correct and the code may be secure, yet the overall system can still leak data or execute unsafe actions if orchestration, memory, or tool permissions are too broad. Where agents interact with multiple services, the safer design is to constrain what the agent can attempt, not to assume the model will always remain within intent. This guidance breaks down when the organisation cannot enforce bounded tool access or cannot observe cross-system actions well enough to reconstruct what the agent actually did.
Where the standard answer stops working: edge cases and trade-offs
Tighter agent controls often increase workflow friction, so organisations have to balance autonomy against blast radius. Some teams want a single policy for all applications, but that usually fails because agent systems have different failure modes from standard web or mobile apps. In practice, the disputed area is not whether the agent is “secure code” but whether it should be allowed to make decisions that can outlive the current request. That distinction is still an area of active guidance rather than full industry consensus.
One common edge case is read-only versus write-capable agents. Read-only systems can still leak sensitive information, but write-capable systems can create downstream impact through email, tickets, code changes, cloud actions, or data updates. Another edge case is delegated access: if a user authorises an agent to act on their behalf, the real risk depends on how narrowly that delegation is scoped and whether it can be revoked cleanly. Teams also underestimate how quickly a “temporary” integration becomes a durable privilege path once it is reused across many sessions.
For that reason, the right question is not “Is the prompt secure?” but “What action would be unacceptable if the model made the wrong choice?” The answer determines where to place approval, logging, and containment. If the organisation cannot define that boundary clearly, the agent has already outgrown normal AppSec assumptions.
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, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 — Agentic Access Control | Directly addresses excessive tool authority and unsafe agent actions. |
| Recommendation — Constrain agent tool access to the minimum actions each workflow truly needs. | ||
| NIST AI RMF | GOVERN — Govern | Fits AI governance where behaviour, boundaries, and accountability must be managed. |
| MAP — Map | Supports identifying agent use cases, dependencies, and impacts across systems. | |
| MANAGE — Manage | Covers treating agent runtime risks as ongoing operational controls, not one-time testing. | |
| Recommendation — Define governance for agent autonomy, approval points, and accountability before deployment. Map the agent’s actions, dependencies, and downstream effects before granting production access. Manage agent risk as a runtime control problem with continuous oversight and escalation paths. | ||
| MITRE ATLAS | ATLAS — Adversarial AI Threat Matrix | Relevant where adversaries abuse agent behaviour, tool use, or orchestration. |
| Recommendation — Use ATLAS to hunt for adversarial behaviours that exploit agent tool use and control gaps. | ||
| CSA MAESTRO | TM — Threat Modeling | Applies to modelling agent workflows, trust boundaries, and tool-mediated abuse paths. |
| Recommendation — Threat-model agent workflows around tool abuse, boundary crossings, and delegated authority. | ||
| CIS Controls v8 | 6 — Access Control Management | Maps to limiting permissions so agent mistakes cannot become broad access or exposure. |
| Recommendation — Review and limit permissions so agent actions cannot exceed intended access scope. | ||
Practitioner Guidance
What to prioritise: Treat tool scope and action authority as the first control problem, not prompt filtering. If the agent can only read data, the residual risk is exposure; if it can write, send, or trigger workflows, the risk becomes operational and often cross-system.
What to verify: Confirm that each tool invocation is attributable, bounded, and reviewable. Security teams should be able to show who authorised the agent, what it was allowed to reach, and whether the action was reversible or contained.
Decision rule: If a failure would matter even when the code is correct and the prompt is benign, it is not a normal AppSec problem. It is an agent governance problem and needs explicit runtime controls, not just secure development checks.
Practitioner takeaway: The main mistake is to secure the agent’s text interface while leaving its action surface effectively trusted; once the system can act, the control objective shifts from preventing bad input to preventing harmful execution.
Related resources from NHI Mgmt Group
- What breaks when teams treat agent security as only a model problem?
- What breaks when organisations treat AI overruns as a finance problem instead of a security problem?
- What breaks when organisations treat employee security risk as a one-time onboarding issue?
- What breaks when organisations rely on siloed security tools to manage AI agent risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
