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

At a glance

What this is: Prompt injection is an LLM runtime control failure in which untrusted input can override intended instructions, change outputs, and trigger downstream actions.

Why it matters: IAM and AI security teams need to treat LLM instructions, tool use, and context handling as an execution boundary, not just a content-safety problem.

Context

Prompt injection is a control problem, not a model bug. In enterprise LLM deployments, user input, documents, APIs, and tool responses can all arrive in the same runtime context, so the system has to decide what is instruction and what is data. When that boundary is weak, the model can behave correctly from its own perspective while still violating organisational intent.

That matters to identity and governance programmes because LLMs increasingly act on behalf of users, read internal context, and invoke tools. The security question is no longer only who can log in, but what an LLM is authorised to infer, relay, or execute during a session. For NHIs and agentic AI, the trust boundary shifts from authentication to runtime control.

OWASP’s LLM01 label aligns with this article’s central claim: prompt injection is a broad enterprise control gap, not a niche prompt-engineering issue. The typical environment still assumes that validation, perimeter access, and logging can contain the risk, but those controls do not reliably separate trusted instructions from adversarial ones once execution starts.

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 do LLMs with tool access create more security risk than chat-only models?

A: Tool access turns an LLM from a text generator into a non-human actor that can trigger actions in other systems. If prompt injection influences that behaviour, the model can make valid but unauthorised API calls, modify records, or reveal data. The risk rises because execution now extends beyond the model boundary.

Q: What are the signs that prompt injection controls are failing?

A: Warning signs include unexpected model behavior, responses that ignore system instructions, retrieval of irrelevant or sensitive data, and actions taken outside the intended workflow. If teams cannot trace which prompts, documents, or integrations influenced an output, they effectively lack visibility into the attack surface. That gap makes it hard to detect malicious instruction flow before it affects production systems.

Q: Should organisations treat prompt injection as an AI governance issue or an access control issue?

A: They should treat it as both. Prompt injection is an AI governance problem because it changes model behaviour, but it is also an access control problem because the model acts on delegated authority. Organisations need runtime policy, scoped tool permissions, and reviewable execution paths, not only prompt guidelines.

Technical breakdown

Why prompt injection is an execution-control problem

Large language models are designed to follow instructions, which means runtime context becomes the control plane. Prompt injection works when attacker-controlled content is interpreted at the same authority level as system or developer instructions. The failure is not in parsing text but in enforcing a trust boundary between instructions and data while the model is running. That is why the model can appear to behave normally while still being steered into unintended actions.

Practical implication: security teams need runtime controls that govern instruction flow, not only input filtering before deployment.

Why tool-using LLMs expand the attack surface

Once an LLM can call APIs, query systems, or trigger workflows, prompt injection becomes more than a content integrity issue. The injected instruction can influence not just what the model says, but what it does. That blurs the line between reasoning and execution, especially when the tool output becomes new context for later decisions. In enterprise terms, the model becomes an NHI-like actor that can consume and emit privileged actions without stable identity controls around each step.

Practical implication: treat tool invocation as a privileged action path and constrain which inputs can influence it.

Why traditional controls miss runtime context

Perimeter controls, static analysis, and standard logging were built for systems with predictable inputs and deterministic execution. Prompt injection breaks those assumptions because the same text can be harmless in one context and malicious in another. Logs may show the request and the response, but not the semantic decision that turned untrusted content into action. That leaves security teams blind to instruction provenance, which is the real issue in LLM execution.

Practical implication: add runtime telemetry that records context, decision flow, and downstream effects for each model interaction.

Threat narrative

Attacker objective: The attacker wants to steer LLM behaviour so the system reveals context, performs unauthorised actions, or corrupts downstream workflow decisions.

1. Entry occurs when an attacker places crafted instructions into user input, documents, emails, web pages, or API responses that the LLM will process at runtime.
2. Credential_harvested or control is abused when the model treats that content as authoritative, overriding intended instructions and using trusted context to continue execution.
3. Escalation happens when the model is induced to call tools, expose internal context, or manipulate downstream systems through valid but unintended actions.
4. Impact is the disclosure of sensitive information, unauthorized automation, or policy violations that occur without a conventional software exploit.

Breaches seen in the wild

• 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.
• Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.

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 really a runtime authorisation failure, not a prompt-quality issue. Security teams often frame the problem as bad instructions or weak sanitisation, but the deeper failure is that the system cannot reliably distinguish trusted commands from untrusted content while it is executing. That shifts the governance question from content review to control of instruction authority. Practitioners should treat this as an execution boundary problem.

LLM systems now behave like privileged intermediaries, which makes identity and access governance unavoidable. When a model reads internal context and then invokes tools, it is effectively operating as a non-human actor with delegated authority. That creates an identity governance challenge for NHIs and agentic AI: access decisions must move closer to runtime, where the model actually acts. Practitioners should align LLM controls with the same scrutiny used for high-risk service accounts.

Execution-control gap: the missing control is not detection alone but a governed separation between instructions, data, and action. OWASP’s LLM01 framing is useful because it names the structural weakness that attackers exploit. The practical lesson is that visibility, tool restriction, and context isolation must be designed together rather than added as separate point controls. Practitioners should map this gap explicitly into their AI and identity governance model.

Prompt injection exposes a broader trust-model problem in enterprise AI adoption. Organisations are already asking LLMs to summarise, decide, and act across internal systems, yet most controls still assume the model is only generating text. That assumption breaks once outputs become executable work. Practitioners should reevaluate whether each integration grants the model more authority than the trust model can actually justify.

From our research library:

• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Prompt injection exposes a governance blind spot that most AI programmes still underestimate. The real control question is not whether the model can be convinced to say something odd, but whether it can be made to act outside its intended authority. Programmes that separate prompt safety from execution governance will keep missing the failure mode.

Runtime visibility is becoming a baseline requirement for enterprise AI oversight. Without context-aware telemetry, teams cannot prove whether a model followed policy or absorbed malicious instructions hidden in retrieved content. That is why LLM security belongs alongside identity governance, not as a standalone content-filtering exercise.

Instruction authority gap: organisations should define which inputs can influence model behaviour, which actions a model may trigger, and where human approval is mandatory. That framing is especially important as agentic systems start to inherit more of the trust problems once reserved for service accounts and scripted workflows.

For practitioners

• Define runtime instruction boundaries Separate system instructions, user content, and external data at the orchestration layer so the model never treats them as equal authority.
• Restrict tool permissions by task scope Limit each LLM workflow to the smallest set of functions it needs, and block tool calls that are not explicitly required for that session.
• Capture context-aware telemetry Record prompts, retrieved content, tool invocations, and downstream effects together so investigators can reconstruct how a model reached a decision.
• Test for indirect prompt injection Exercise document, email, web, and API ingestion paths because malicious instructions often arrive through sources the user never intended to trust.
• Treat LLM outputs as governed actions Require human or policy review before model output can trigger data changes, external messages, or access to sensitive internal systems.

Key takeaways

• Prompt injection is a control-plane problem in enterprise LLMs, because untrusted content can be treated as instruction during execution.
• The risk is broader than bad outputs, since injected instructions can drive tool use, context exposure, and downstream workflow manipulation.
• Identity and AI governance teams need runtime boundaries, scoped actions, and contextual telemetry if they want to control LLM behaviour reliably.

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.
• 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.
• Tool Invocation: Tool invocation is an action where an AI agent calls an external system such as a database, API, or file service. Each invocation should be treated as an auditable identity action because it is the point where the agent can move data, trigger changes, or widen its reach across the environment.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, agentic AI identity, machine identity security, and secrets management through the industry's only accredited NHI security programme. It helps practitioners connect identity control models to emerging AI and workload authority patterns.