Both, but the identity side is often missed first. Prompt injection becomes a security breach when it can steer a delegated principal into using permissions it should never exercise in that context. That is why teams need controls over agent identity, delegated authority, and egress, not only model prompts and content filters.
Why prompt injection sits on the application and identity boundary
Prompt injection is not just a content problem. The application layer is where the malicious instruction enters, but the identity question is whether that instruction can influence a principal that already has trust, scope, or standing permissions. Once an assistant, agent, or tool runner can act as a delegated principal, the security question becomes who is authorised to do what, in which context, and with which safeguards.
That boundary matters because the harm usually appears when the injected instruction crosses from text into action. A model can ignore or paraphrase bad input and still be safe; a delegated runtime that can send mail, read files, query systems, or invoke tools changes the risk picture entirely. At that point, prompt injection is best understood as an abuse path that blends application insecurity with identity and access failure.
For readers who want the broader threat model, NHIMG’s Prompt Injection Guide covers direct, indirect, and multimodal attacks, plus layered defences against exfiltration and tool abuse.
What changes when a prompt can steer a delegated principal
The practical distinction is whether the system merely generates unsafe text or can cause unsafe action. If a prompt can redirect an agent that holds tokens, sessions, API access, or operational authority, then the issue is not limited to model output quality. The problem becomes privilege use in the wrong context, which is an identity and authorization failure as much as an AI failure.
This is why agent-facing controls matter. Scope boundaries, tool allowlists, egress restrictions, approval steps for sensitive actions, and separation between user content and executable instruction all reduce the chance that injected text becomes a high-impact action. The safest design assumes that hostile input will reach the model and focuses on preventing it from becoming an authorised side effect.
NHIMG’s Agentic AI Security Guide is the most useful companion when you need a layered view of inputs, memory, tools, orchestration, and identity together.
Where teams are specifically securing agent-driven browser or desktop use, NHIMG’s Browser and Computer-Use Agent Security Guide is helpful because prompt injection often succeeds by abusing the user’s existing sessions and access paths.
How to decide whether to treat the issue as appsec, identity, or both
Use the simplest test: if the unsafe outcome is only a bad response, treat it primarily as an application security and content integrity issue; if the unsafe outcome depends on the system acting with someone’s permissions, treat it as an identity and access issue too. In many real deployments, both are true, because the prompt is the entry point and delegated authority is the impact path.
That means the best remediation view is not “fix the prompt” versus “fix the identity model.” It is to harden both sides of the trust chain. The application should resist instruction smuggling, but the delegated principal should also be tightly scoped, observable, and incapable of taking irreversible actions without additional checks. Where an attacker can turn a prompt into tool use, data access, or outbound communication, identity governance becomes part of the fix.
NHIMG’s OWASP Agentic Applications Top 10 is useful when you need to map prompt injection to adjacent risks such as identity and privilege abuse, tool misuse, and supply-chain-style agent compromise.
Risk and Threat Considerations
Prompt injection becomes materially dangerous when the injected instruction can reach a live trust boundary, such as a tool call, a sessioned browser, a connector, or an API client with standing permission. The attacker is not trying to “confuse the model” in the abstract, but to convert untrusted text into authorised action, data exposure, or privilege misuse.
Failure mechanism: The environment treats model output or retrieved content as sufficiently trusted to trigger actions, and the agent executes those actions with permissions that were never meant to be available to that input context.
Impact: Sensitive data can be exposed, outbound actions can be taken without the right business context, and the blast radius can extend to mail, files, tickets, code, or production systems if the principal is over-scoped.
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 OWASP API Security Top 10 address the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Prompt injection becomes harmful when it can trigger unauthorised actions. |
| Recommendation — Enforce authorization checks before any sensitive action an agent can trigger. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The core risk is misuse of delegated authority by an agent. |
| ASI02 — Tool Misuse | Prompt injection often works by steering tools the agent can invoke. | |
| Recommendation — Constrain agent permissions and require approval for high-impact actions. Restrict tool access to the minimum set needed for the task. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Injected prompts can cause calls to functions the context should not reach. |
| Recommendation — Block function calls unless the caller is authorised for that function. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Delegated principals rely on secrets and sessions that must be controlled. |
| Recommendation — Rotate and protect credentials that let the agent act on behalf of others. | ||
Practitioner Guidance
What to verify: Confirm whether the agent, assistant, or workflow can perform any action that would matter if an attacker controlled its next instruction. If the answer is yes, treat prompt injection as a delegated-authority problem, not just a model-safety problem.
Decision rule: If a prompt can cause a tool invocation, data export, or write action, require context checks, explicit action gating, and narrow permissions before you rely on content filters alone.
Practitioner takeaway: The right control objective is not to make hostile prompts harmless in every case, it is to ensure that any prompt capable of influencing action cannot inherit more authority than the current context deserves.
Related resources from NHI Mgmt Group
- Should organisations treat prompt injection as an AI governance issue or an access control issue?
- When should organisations treat an AI agent as a privileged system?
- When should organisations treat an API design issue as an identity risk?
- Should organisations treat identity controls as part of application security?