Application security assumes a relatively stable workload boundary and a predictable request path. AI agents can select tools, access data, and continue executing in ways that change the path mid-workflow. When teams treat them like static apps, they miss the identity and authorisation layer where real risk appears.
Why This Matters for Security Teams
Handling AI agent security like ordinary application security creates a false sense of control. Traditional AppSec is built around a stable request path, known dependencies, and code-centric risk review. Agents change that model: they can choose tools, chain actions, retrieve data dynamically, and continue executing after the initial prompt. The security problem is not just what the code does, but what the agent is allowed to do at runtime.
That shift is visible in current reporting. NHIMG research on AI Agents: The New Attack Surface found that 80% of organisations report agents have already performed actions beyond intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing credentials. This is why ordinary vulnerability management misses the real failure point. Current guidance from OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both push teams toward runtime control, not just code review.
In practice, many security teams encounter agent overreach only after sensitive data has already been queried, moved, or exposed through tool chaining rather than through intentional design review.
How It Works in Practice
The practical breakage starts with identity and authorisation. Ordinary application security often assumes a service account, a bounded API, and a predictable set of routes. An agent does not stay in one path. It may read a ticket, query a database, call an internal tool, invoke another model, and then decide the next action based on output. That means control must move from static entitlement review to runtime policy evaluation.
For agentic systems, best practice is evolving toward intent-based authorisation, just-in-time credential issuance, and workload identity as the primary trust anchor. Instead of giving an agent long-lived secrets, teams should issue short-lived credentials per task and revoke them automatically when the task completes. Cryptographic workload identity, such as SPIFFE-style identities or OIDC-based workload tokens, proves what the agent is and what execution context it is operating in. Policy engines then decide whether the requested action is allowed right now, with current context, not just at deployment time.
This also changes monitoring. Security teams need to log the tool call, the target system, the scope of data requested, and the policy decision that allowed or denied the action. That is the operational lesson reinforced by NHIMG’s OWASP NHI Top 10 coverage and by implementation guidance from CSA MAESTRO agentic AI threat modeling framework. These controls tend to break down when agents are allowed to keep persistent tokens across sessions because long-lived access defeats the containment model.
Common Variations and Edge Cases
Tighter agent controls often increase operational overhead, requiring organisations to balance safety against developer speed and automation depth. That tradeoff matters most in environments with many tools, many tenants, or highly delegated workflows. There is no universal standard for this yet, but current guidance suggests that the more autonomous the agent, the less acceptable static role-based access becomes.
One edge case is read-only agents. Even if an agent cannot write changes, it can still exfiltrate data, summarize restricted content, or chain tool access into a broader incident. Another is multi-agent orchestration, where one agent’s output becomes another agent’s input. That architecture multiplies the chance that a single mis-scoped identity or token exposes multiple systems. The risk is not only the initial permission set, but the downstream composition of actions.
Teams should also be cautious about treating agent guardrails as a one-time policy layer. The moment an agent can select tools dynamically, policy must be evaluated at request time with full context. For environments that need a deeper baseline on agent-enabled abuse paths, NHIMG’s Analysis of Claude Code Security and the NIST AI Risk Management Framework help frame the governance gap. The model breaks down fastest when a tool-rich agent is allowed persistent credentials in a flat network because lateral movement becomes an architectural property, not an exception.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Static AppSec misses agent tool chaining and runtime abuse paths. |
| CSA MAESTRO | TR-1 | MAESTRO covers threat modeling for autonomous, tool-using agent workflows. |
| NIST AI RMF | GOVERN | AI RMF governance is needed when agents act beyond static app boundaries. |
Map agent tools, actions, and runtime guards to A1 and enforce per-action policy checks.
