Prompt injection becomes a vulnerability when agents can act

At a glance

What this is: This analysis argues that prompt injection stops being a theoretical limitation and becomes a security issue when AI systems can take actions, use tools, or reach external resources.

Why it matters: It matters because IAM and security teams must govern agent permissions, trust boundaries, and action validation rather than treating all AI prompt abuse as harmless output manipulation.

Context

Prompt injection is the failure mode that appears when an LLM or AI agent cannot reliably distinguish instructions from untrusted content. The security question is not whether the pattern exists, but whether the surrounding system lets that pattern influence permissions, tools, or external actions.

The article argues that the real governance problem starts when a model is embedded in an agentic AI system that can browse, read files, send messages, or trigger workflows. In that setting, prompt injection is no longer just a model quirk because the output can change state outside the chat window.

That distinction matters for identity governance because the risk now depends on what the agent is allowed to do, what data it can reach, and whether a human reviews the action before it lands. A self-contained assistant and an autonomous workflow have very different blast radii.

Key questions

Q: How should security teams handle prompt injection in AI systems?

A: Treat prompt injection as an authorisation problem, not only a content problem. Validate user input, monitor for override patterns, and block any prompt that tries to change model policy, exfiltrate data, or trigger sensitive actions. The safest design is one where untrusted prompts cannot directly reach code execution, production data, or privileged tools without policy checks.

Q: Why does prompt injection become more dangerous once an AI system can use tools and credentials?

A: Tool use changes prompt injection from a text problem into an authority problem. A model that can only talk can cause bad output or leak instructions. An agent with read, write, or device-control permissions can exfiltrate data, publish content, or trigger physical actions. The same sentence now rides on borrowed authority, so impact depends on the capability exposed.

Q: What are the signs that an AI agent is being steered by repository content?

A: Watch for unexpected file reads, the same prompt leading to different target files, and requests that follow comments or documentation more than task scope. Those signals often indicate semantic manipulation, where the agent is treating untrusted content as instruction rather than as data.

Q: What should organisations do when AI tools can take actions on behalf of users?

A: Treat agent actions as governed identity events and require logging of tool calls, delegation chains, and execution context. Without that layer, investigations cannot tell whether an action came from the human operator, the agent, or a downstream delegated workflow.

Technical breakdown

Why prompt injection is a boundary problem, not only an LLM problem

Prompt injection exploits the way LLMs process mixed content, where instructions and data can be hard to separate reliably. In a single-user chatbot, that weakness mostly affects the current session. In an agentic system, the same weakness becomes operational because the model can turn untrusted text into tool calls, file actions, or outbound communication. The technical issue is therefore not the text alone, but the path from text to action. Once that path exists, the security boundary is no longer the prompt field. It is the control point between model output and real-world execution. See the Prompt Injection Guide.

Practical implication: Treat prompt injection as an action-control problem whenever the model can do more than answer questions.

Why allowlists and parser fixes matter in agent workflows

The article points to cases where vendors patched command allowlists, input handling, or refusal behavior after injection research. That matters because an attack often succeeds by combining prompt manipulation with a second weakness, such as permissive tool execution or flawed command parsing. In agentic systems, small parsing bugs can become escalation paths if the agent is authorised to run commands automatically. The deeper lesson is that mitigation has to be layered: the model may still be steerable, but downstream execution should not assume the prompt was benign. A fix at the parser or policy layer changes the impact even when the model remains imperfect. Read Red Teaming AI Agents for Identity Abuse.

Practical implication: Place approval and parsing controls between model output and any command, tool, or workflow execution.

Why runtime monitoring beats static prompt review

Static review of prompts, manifests, or skill registries cannot show how an agent behaves when exposed to live attacker content. Prompt injection is a runtime attack because the harmful decision happens after the untrusted input is encountered. That makes behavioural monitoring essential: defenders need to watch for unexpected tool use, unusual destination endpoints, and actions that do not match the task. The important architectural point is that trust cannot be assigned once at build time and assumed forever. If the agent is making live decisions, the trust decision must also exist at runtime, not only in design documentation. See the Browser and Computer-Use Agent Security Guide.

Practical implication: Monitor agent behaviour continuously and alert when runtime actions diverge from the approved task scope.

Breaches seen in the wild

• EchoLeak (Microsoft 365 Copilot) 2025: A crafted email could make Microsoft 365 Copilot leak data from its context with no click, a zero-click prompt injection fixed as CVE-2025-32711.
• ForcedLeak (Salesforce Agentforce) 2025: A critical Agentforce flaw let attackers steer an AI agent through a Web-to-Lead form to leak CRM data via an expired allowlisted domain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Prompt injection is a governance failure only when the system lets untrusted text become authority. The article is right to reject a blanket vulnerability label for every chatbot scenario, but that framing collapses once the model can trigger tools or external actions. At that point, the issue is not the prompt itself. It is the governance assumption that model output can be treated as advisory rather than executable. Practitioners should stop classifying all injection cases the same way and start classifying them by action scope.

Access review processes assume privilege persists long enough to be reviewed. That assumption was designed for stable accounts, scheduled recertification, and observable entitlement states. It fails when an AI system can consume untrusted input and act before a review cycle ever sees the behaviour. The implication is not just better review cadence. It is a rethink of where governance lives when the risky decision happens inside the session, not after it.

Prompt injection exposes a trust boundary problem that conventional application security often understates. The article shows why the same model behaviour is tolerable in a self-contained chat and dangerous in an agent that can browse, send, or modify. That difference is not semantic. It is the difference between contained influence and externally visible action. This is why agent identity, tool permissioning, and action validation have to be evaluated together.

The operational risk is not that LLMs are imperfect, but that organisations keep assigning them permissions without matching controls. When vendors treat the issue as an abstract limitation, the burden shifts to practitioners to decide where model output may become action. That is the real governance decision: whether to allow an LLM to sit inside an execution chain without a compensating control at the point of use. Teams should treat that as a programme design question, not a product setting.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: Red Teaming AI Agents for Identity Abuse

What this signals

Prompt-injection governance is becoming a runtime permission problem: if an AI system can turn untrusted content into action, the security model must shift from prompt hygiene to action control. Access reviews, static manifests, and build-time checks do not catch decisions made inside the session, so practitioners need runtime guardrails that watch what the agent actually does.

The broader programme implication is that agent governance now spans identity, tool scope, and execution monitoring in one control plane. AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026. That trend reinforces a simple point: the surrounding system, not just the model, defines the exposure surface.

For practitioners

• Restrict agent permissions to task minimums Give AI systems only the tool, file, and network access needed for the current workflow. Separate read-only assistance from any workflow that can send messages, modify data, or trigger external actions.
• Insert validation before irreversible actions Require a control layer between model output and any externally visible action, including email, file writes, approvals, or API calls. Validation should verify intent, target, and policy fit before execution.
• Mark untrusted content as hostile input Treat web pages, email, uploaded files, and workspace content as untrusted even when they are routine business inputs. Feed them to agents only with explicit separation from system instructions and task context.
• Monitor agents for off-task behaviour Look for tool calls, destinations, or action sequences that do not match the approved task. Behavioural monitoring should detect when an agent starts doing work it was never asked to do.

Key takeaways

• Prompt injection becomes operationally important when an AI system can turn untrusted content into tool use, workflow execution, or data movement.
• The critical control gap is the gap between model output and action, where validation, permissions, and runtime monitoring determine the blast radius.
• Identity teams should treat agent permissions and behavioural monitoring as governance requirements, not optional add-ons to the model layer.

Related NHI Mgmt Group resources: Agentic AI Security Guide · Prompt Injection Guide · Browser and Computer-Use Agent Security Guide · Red Teaming AI Agents for Identity Abuse

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Action Boundary: The action boundary is the point where a user or system turns a request into a business-impacting decision, such as a payment approval or access grant. It is the most important place to add controls when attackers are using legitimate-looking messages to redirect trusted workflows.
• Agent Runtime: The agent runtime is the execution environment where an AI agent reads data, calls tools, and carries out actions. It matters because the runtime is where identity, policy, and filesystem boundaries either hold or fail. If those boundaries are weak, the agent becomes a high-privilege path into the environment.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity security strategy or governance across human and non-human systems, it is worth exploring.