They should treat them as both. AI agents with tool access can be manipulated through prompt injection, tool poisoning, or compromised MCP servers, which means the core risk is unauthorized action, not just bad code. Teams need identity controls, tool authorization, and runtime monitoring together, because the agent itself becomes a decision-making identity with access to real systems.
Why This Matters for Security Teams
The AppSec versus identity question matters because AI agents do not behave like ordinary application features. Once an agent can invoke tools, call APIs, or act through MCP-connected services, the security problem shifts from code quality alone to whether an entity is authorized to act, when, and under what constraints. That is why current guidance increasingly treats agentic systems as a blended risk surface, with both application flaws and identity failures creating the same outcome: unauthorized execution.
Teams that frame the issue only as AppSec tend to overfocus on prompt hygiene and static code review, while teams that frame it only as identity tend to miss model-level abuse paths such as prompt injection, tool poisoning, and indirect instruction following. The most useful starting point is to map the agent’s trust boundaries, then decide which controls govern the model, which govern the tools, and which govern the credentials. The OWASP Top 10 for Agentic Applications 2026 is helpful here because it frames agentic risk around agent behavior, tool use, and runtime abuse rather than treating the agent as a normal web application.
In practice, many security teams encounter this as an incident response problem only after an agent has already used valid access to reach systems it was never meant to influence.
How It Works in Practice
A practical decision model starts with the question: what creates the harmful action? If the issue is malformed input causing a crash, malformed output, or insecure dependency handling, AppSec remains central. If the issue is an agent being tricked into using a tool, escalating scope, reusing a secret, or obeying a malicious MCP server, identity and authorization controls become just as important as secure coding. The distinction is not binary. It is a control-mapping exercise across model, orchestration layer, tool layer, and downstream systems.
For agentic systems, the control stack typically includes:
- strong tool authentication and per-action authorization, so the agent does not inherit broad standing access
- secret isolation, so API keys and tokens are not exposed to the model context unless absolutely necessary
- session-scoped permissions, so access is time-bound and task-bound rather than persistent
- allowlisted tool calls and structured command validation, to reduce tool abuse and injection paths
- runtime logging and anomaly detection, so suspicious agent actions can be traced and contained
This is where identity thinking becomes essential. An agent with execution authority behaves like a delegated digital actor, so the team must define who or what it represents, what it can invoke, and how revocation works. The NIST AI Risk Management Framework is useful for structuring governance, while the MITRE ATLAS adversarial AI threat matrix helps teams reason about manipulation tactics that target model behavior and tool use. For teams using MCP, the server itself must be treated as part of the trust chain, not as a neutral transport. These controls tend to break down in highly dynamic environments with broad delegated access, because the agent can move faster than policy enforcement and reuse credentials across tools.
Common Variations and Edge Cases
Tighter authorization often increases integration overhead, requiring organisations to balance agent autonomy against the cost of more granular policy and monitoring. That tradeoff becomes sharper in environments where agents must complete multi-step workflows across SaaS, internal APIs, and infrastructure platforms.
There is no universal standard for this yet, but best practice is evolving toward layered governance. In low-risk internal use cases, some teams may accept AppSec-led controls with lightweight identity checks. In higher-risk environments such as customer data processing, administrative actions, or production change execution, identity and privilege management should lead, with AppSec controls providing guardrails around input handling, tool validation, and secure deployment. The CSA MAESTRO agentic AI threat modeling framework is relevant when teams need to model agent autonomy, delegation, and containment together.
Emerging guidance from the Anthropic first AI-orchestrated cyber espionage campaign report reinforces a practical point: once agents can chain tools and credentials, the real failure mode is often unauthorized action at machine speed. That is why identity and AppSec should not compete for ownership. They should share the threat model, with one team owning secure software behavior and the other owning delegated authority, revocation, and privilege boundaries. For teams needing operational context, CISA cyber threat advisories remain a useful source for tracking active abuse patterns and defensive priorities.
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 NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Agentic apps need controls for prompt injection and tool abuse. |
| NIST AI RMF | GOVERN | AI governance is needed to assign accountability for agent behavior. |
| MITRE ATLAS | T0001 | Adversarial AI tactics explain how prompts and tools can be manipulated. |
| CSA MAESTRO | MAESTRO models agent delegation, autonomy, and containment risks. | |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access control are central to agent authorization. |
Use a threat model that covers agent autonomy, trust boundaries, and recovery controls.
Related resources from NHI Mgmt Group
- How should security teams decide whether an AI agent gets human or non-human identity?
- How do identity teams decide whether an AI agent needs a separate governance model?
- How do identity teams decide whether an AI agent needs more than standard policy enforcement?
- How do teams decide whether to treat an AI system as a governed identity?
