Prompt injection is an execution-control failure in enterprise LLM systems

At a glance

What this is: This article explains prompt injection as an OWASP LLM01 risk where untrusted input is interpreted as instruction during LLM execution, changing model behavior without exploiting a software vulnerability.

Why it matters: It matters to IAM and security teams because LLMs often operate with internal tools, downstream systems, and sensitive data, so instruction boundaries and runtime authorisation now sit alongside traditional access control.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read LEVO's analysis of prompt injection in enterprise LLM systems

Context

Prompt injection is the failure mode that appears when a language model cannot reliably distinguish trusted instructions from untrusted runtime content. In practice, that means a user prompt, document, email, API response, or tool output can be treated as operational instruction, which is why the problem reaches into enterprise LLM governance rather than remaining a model-only issue.

The primary security gap is not whether the model can answer questions, but whether the surrounding system can enforce instruction boundaries, runtime visibility, and downstream authorisation. For IAM and NHI programmes, that makes prompt injection relevant wherever an LLM can influence tools, secrets, or identity-bearing workflows, and the starting assumption in the article is typical for modern LLM deployments.

Key questions

Q: What breaks when prompt injection defenses are not in place for LLMs?

A: When prompt injection defenses are weak, attacker-controlled text can override the model's intended instructions, especially when the text arrives through retrieved content or external documents. The result is not always obvious compromise. It can be silent instruction hijacking, unsafe output, leaked context, or model behaviour that downstream systems trust too much.

Q: Why does prompt injection create risk even when credentials are valid?

A: Prompt injection works because the agent uses its own authorised access. The attacker does not need to steal a key if they can steer the agent into using that key for an unintended action. Valid credentials confirm identity, but they do not prove the intent behind each runtime decision.

Q: How should security teams test enterprise LLMs for prompt injection risk?

A: Test the model inside the real application path, not in isolation. Include hidden instructions, malicious retrieved content, multi-turn escalation, and language variations, then measure whether the model reveals policy text, ignores constraints, or produces unsafe tool instructions. A model that passes simple prompts may still fail once context, memory, and retrieval are involved.

Q: Should organisations treat LLM tool use like privileged access?

A: Yes. Any model that can call APIs, trigger workflows, or retrieve sensitive data is exercising delegated authority, so the tool path should be governed like privileged access. That means task-scoped permissions, short-lived credentials, approval boundaries where needed, and monitoring that detects abnormal action patterns.

Technical breakdown

Why prompt injection is an execution-control problem

Prompt injection works because LLMs ingest system prompts, developer prompts, user input, and external content inside one conversational execution context. The model does not natively understand security trust boundaries, so adversarial text can be processed with the same authority as legitimate instructions. This is why OWASP places the issue in LLM01. The core failure is not malformed input, but instruction conflation during inference. Once the model treats attacker-controlled text as a valid instruction source, policy can be overridden without any compromise of the underlying infrastructure.

Practical implication: teams need runtime controls that separate instruction sources, not just better prompt wording.

Indirect prompt injection and tool misuse

Indirect prompt injection is especially dangerous in enterprise workflows because the malicious instruction is hidden inside content the model is already expected to process, such as a document, email, webpage, or API response. When the model is connected to tools or functions, that instruction can influence the next action, including API calls, workflow triggers, or data retrieval. The result is a shift from unsafe text generation to unsafe execution. This is where LLM behaviour starts overlapping with identity and authorisation, because the model may act through credentials, tokens, or service integrations already present in the runtime path.

Practical implication: constrain tool scopes and treat LLM tool calls like privileged actions.

Why static testing and perimeter controls miss the attack

Traditional controls struggle because prompt injection is contextual, dynamic, and linguistically normal. WAFs, access controls, and static scanning can confirm that a request is allowed, but they cannot determine whether the content will be interpreted as malicious instruction once it enters the model context. Logging also falls short because it records requests and responses, not the model’s interpretation chain. In effect, the attack happens inside the decision layer, where deterministic assumptions break down and the same input can be harmless in one session and harmful in another.

Practical implication: add runtime inspection and behavioural monitoring to the LLM control stack.

Threat narrative

Attacker objective: The attacker wants to convert trusted LLM execution into an execution path that reveals data, violates policy, or acts on behalf of the system in ways the operator did not intend.

1. Entry occurs when an attacker places crafted instructions in user input, a document, an email, or another external data source the LLM is expected to process.
2. Escalation happens when the model interprets that content as authoritative instruction and uses it to override intended policy or trigger tool use.
3. Impact follows when the model exposes sensitive context, performs unauthorised actions, or manipulates downstream systems through valid integrations.

NHI Mgmt Group analysis

Prompt injection is an identity-adjacent control failure, not just an LLM quality issue. Once a model can trigger tools, query systems, or surface sensitive context, its runtime behaviour starts to resemble an identity-bearing workload. That means access scope, trust boundaries, and action authorisation matter as much as prompt engineering. For IAM teams, the practical conclusion is that LLM governance has to include runtime authorisation decisions, not only content filters.

Instruction boundary collapse is the named concept practitioners should track. The article shows that the dangerous condition is not a broken model, but a system that cannot reliably separate instructions from data at runtime. That collapse turns normal enterprise content into a control channel for attackers. In OWASP terms, the risk is execution-layer ambiguity, and in governance terms it is a trust boundary that no longer holds. Practitioners should treat any LLM workflow that mixes untrusted input with privileged actions as a boundary-design problem.

Runtime visibility is now a governance requirement for AI systems that act. Static policy documents cannot tell you when an LLM has been induced to use tools, reveal context, or pass along manipulated output. The control gap is observability of instruction flow, action selection, and downstream execution. That aligns with NIST AI RMF governance and monitor functions, and it also intersects with OWASP Agentic AI Top 10 thinking when the model can chain decisions. The practitioner takeaway is clear: if the system can act, it must be monitored at the moment it acts.

NHI governance becomes relevant the moment models operate with secrets, tokens, or service accounts. Prompt injection is often discussed as a content-security problem, but the real blast radius comes from the identities and credentials the model can touch. If a model can invoke an API key, a service token, or a workload credential, then compromised instruction flow can become compromised access flow. That makes NHI controls, least privilege, and short-lived credentials part of the LLM security baseline, not an optional integration detail.

OWASP LLM01 is useful because it names a structural class of failure, not a bug class. That distinction matters for programme design. If teams treat prompt injection as a prompt-tuning issue, they will overinvest in pre-deployment checks and underinvest in runtime enforcement, tool scoping, and logging with semantic context. The better response is to align governance around the execution path, because that is where the threat actually lives.

What this signals

Prompt injection is becoming more operationally important as LLMs move from chat interfaces into workflows that can reach identity-bearing systems, secrets stores, and internal APIs. The control gap is not merely content moderation. It is runtime governance over what the model can see, what it can decide, and what it can execute before the action completes.

Instruction boundary collapse: this is the programme risk that will force better separation between untrusted content and privileged action paths. Teams that already manage NHI, secrets, and delegated access should recognise the same pattern in LLM tooling: if a model can act, it needs scoped authority, traceable decisions, and revocation boundaries. That is where identity security and AI security now intersect.

For practitioners

• Separate instruction sources in the LLM architecture Isolate system instructions, developer instructions, and untrusted content so the model cannot treat them as equal-authority input during runtime execution.
• Restrict tool permissions to task-scoped access Limit every model-invoked API, function, and workflow to the minimum action set and shortest credential lifetime needed for the task.
• Log instruction flow and tool calls together Capture prompts, retrieved content, model outputs, and downstream tool invocations in one trace so security teams can reconstruct how a decision was made.
• Add runtime policy checks before execution completes Evaluate whether an action is authorised at the moment the model attempts it, rather than assuming pre-deployment testing or perimeter controls are sufficient.

Key takeaways

• Prompt injection is a runtime control failure that turns ordinary content into executable instruction inside LLM systems.
• The practical risk rises sharply when models can use tools, secrets, or downstream APIs with delegated authority.
• Security teams should shift from prompt hygiene alone to runtime visibility, scoped permissions, and execution-time policy enforcement.

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.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Execution Control: The set of technical and governance measures that decide when code is allowed to run, in what environment, and with what permissions. It is stronger than static validation because it governs runtime behaviour, sandbox constraints, logging, and explicit approval before an action reaches production-like execution.
• Runtime Visibility: The ability to observe what an AI client actually accessed, which tools it used, and how it behaved during a session. It is more useful than entitlement snapshots for agent governance because it captures executed reality, not just approved access.

What's in the full article

LEVO's full article covers the operational detail this post intentionally leaves for the source:

• The article breaks down direct and indirect prompt injection patterns in more depth, including how malicious instructions travel through documents, emails, APIs, and tool responses.
• It explains why runtime controls are needed over static prompt design, which is useful if you are designing detection and enforcement for production LLM workflows.
• It outlines Levo's approach to runtime AI security, including visibility, threat detection, protection, monitoring, and red teaming.
• It compares prompt injection with hallucination and misuse, which helps teams separate adversarial behaviour from ordinary model error.

👉 LEVO's full article covers runtime controls, tool misuse, and the operational consequences of prompt injection.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners building stronger identity controls. It helps security teams align delegated access with modern runtime systems and operational risk.