Direct prompt injection exposes the AI runtime governance gap

At a glance

What this is: Direct prompt injection is a runtime attack on LLMs and AI agents that uses malicious input to override intended instructions and drive unauthorized actions.

Why it matters: It matters because AI agents increasingly hold delegated access to enterprise systems, so identity, access, and governance controls must extend to runtime execution, not just authentication and API permissions.

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, sharing sensitive data, and revealing access credentials.

👉 Read LEVO's analysis of direct prompt injection and AI runtime governance

Context

Direct prompt injection is an AI runtime governance problem, not a conventional software vulnerability. The attacker does not need to break authentication or compromise infrastructure; they only need to feed malicious instructions into the model's interpretation layer and persuade the agent to act on them. For identity teams, the important shift is that delegated access alone is not the control boundary when an AI agent can be steered at runtime.

This creates a governance gap across IAM, PAM, and AI security programmes. A system may be correctly authenticated and still behave unsafely if the model treats attacker-supplied text as valid instruction. That is why runtime visibility, execution controls, and policy enforcement inside the AI interaction path matter alongside standard access controls.

Key questions

Q: How should security teams reduce prompt injection risk in AI agents?

A: Security teams should reduce prompt injection risk by constraining what enters the context window, limiting tool permissions, and separating untrusted retrieval content from privileged instructions. The practical goal is not perfect detection. It is to ensure that a successful injection cannot trigger wide data access, uncontrolled writes, or irreversible actions through a delegated identity.

Q: Why do prompt injection attacks create governance risk for AI agents?

A: Prompt injection creates governance risk because the model often sits in the control path between text input and tool execution. If attackers can change what the model treats as authoritative, they can influence access decisions, data exposure, or downstream actions without compromising a traditional account. That makes prompt provenance and instruction hierarchy part of AI identity governance.

Q: What are the signs that an AI agent may be vulnerable to prompt injection?

A: Look for mismatches between the prompt a system received and the actions it attempted, especially unexpected data retrieval, unusual API calls, or tool use that does not match the user's request. Those are strong indicators that input steering is affecting execution.

Q: What is the difference between prompt injection and indirect prompt injection?

A: Prompt injection targets the model directly through the user prompt. Indirect prompt injection hides malicious instructions inside data the model later reads from a trusted source, such as a form submission or knowledge base. Indirect attacks are more dangerous in agentic systems because the malicious content can travel through normal workflows before it is executed.

Technical breakdown

How direct prompt injection manipulates AI instruction parsing

Direct prompt injection works because LLMs and AI agents process prompts as structured instructions, then infer what action to take from the surrounding context. If attacker-supplied text is not cleanly separated from trusted instructions, the model may treat hostile content as part of the task. The failure is semantic, not syntactic: the input can look normal while carrying a command to ignore policy, reveal data, or change tool use. This is why prompt injection targets the inference layer rather than code execution or network pathways.

Practical implication: isolate trusted system instructions from untrusted user content and add runtime policy checks before any tool call.

Why delegated access turns prompt injection into privilege misuse

AI agents often operate with delegated permissions, meaning they can query data, call APIs, or trigger workflows on behalf of a user or application. Prompt injection does not need to steal those permissions. It only needs to redirect how the agent spends them. That creates a privilege misuse problem: the agent remains authorised, but the action is no longer aligned to the intended business purpose. In identity terms, this is closer to abused delegation than broken authentication.

Practical implication: treat agent permissions as blast-radius controls and limit each agent to the narrowest workflow scope possible.

Why traditional security controls miss inference-layer attacks

Network controls, IAM, API gateways, and application security tools are built to validate transport, identity, and code behaviour. They do not understand whether a prompt is attempting to subvert an AI agent's reasoning. An API gateway may see a valid request from an approved system, while the model's decision process has already been manipulated upstream. That disconnect leaves a gap between request legitimacy and execution legitimacy. Security tools that only inspect perimeter signals cannot see the model's internal interpretation path.

Practical implication: add AI runtime monitoring and execution governance so suspicious model behaviour is visible before actions are committed.

Threat narrative

Attacker objective: The attacker wants to steer an AI agent into revealing restricted data or executing actions that the user never authorised.

1. Entry occurs when an attacker submits crafted text through a normal user prompt, chat field, document, or application input that the AI agent will process.
2. Escalation happens when the model interprets the malicious instruction as valid context and uses its delegated permissions to query data or invoke tools outside the intended task.
3. Impact follows when the agent retrieves sensitive data, performs unauthorized workflow actions, or exposes credentials through enterprise systems and APIs.

NHI Mgmt Group analysis

Direct prompt injection is an execution integrity problem, not a prompt hygiene problem. The attack succeeds when organisations assume model output is the only thing to control, while the real issue is whether the agent's action path can be steered by hostile input. That makes runtime governance the decisive control plane, especially where AI agents can touch enterprise systems, APIs, and sensitive data. For practitioners, the boundary to protect is not just access, but authorised execution.

Prompt injection exposes a trust gap between identity and intent. IAM can verify that an agent has credentials, but it cannot determine whether the agent's next action reflects legitimate user intent or adversarial manipulation. That gap matters in AI programmes that reuse delegated access patterns from traditional service accounts without adding runtime policy enforcement. The named concept here is execution integrity drift, where correct authentication coexists with unsafe action selection. Practitioners should govern both identity and decisioning.

AI agent governance now has to account for semantic abuse of valid access. The article shows why conventional controls built around network traffic, request signing, and infrastructure hardening are necessary but insufficient. Once AI agents can interpret untrusted language and turn it into action, the control objective shifts to preventing unsafe interpretation from becoming unsafe execution. For identity and security teams, that means treating agent runtime behaviour as a first-class governance domain.

Semantic trust boundary collapse is the control failure this article reveals. The model cannot reliably distinguish between instructions that should be obeyed and content that should be treated as hostile, especially when both enter through the same input channel. That failure is particularly relevant for AI agents operating inside enterprise workflows, where the same delegated access can be used for either legitimate automation or attacker-driven misuse. Practitioners should define and enforce a boundary between user text and trusted system instruction.

OWASP guidance becomes materially more useful when it is paired with identity governance. Prompt injection is one of the clearest examples of why agentic AI risk cannot be handled by application security alone. The issue intersects with OWASP Agentic AI guidance, NHI governance, and AI RMF-style accountability because the agent itself behaves like a privileged runtime entity. Security teams should map AI agent controls to explicit ownership, logging, and containment requirements.

What this signals

Execution integrity drift is becoming a core governance concept for AI programmes. As agents gain access to internal systems, the question is no longer whether credentials exist, but whether runtime behaviour remains aligned to the approved task. That shift pushes AI security into the same governance conversation as IAM and PAM, where visibility, containment, and revocation are expected controls rather than optional extras.

The next control gap will be between authorised access and authorised intent. Teams that rely only on authentication, network inspection, or API validation will continue to miss prompt-driven misuse because those controls do not inspect model reasoning. The practical answer is to add runtime monitoring, tool-call policy enforcement, and clear ownership for agent behaviour, alongside references such as the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework.

Where AI agents can touch sensitive data, the programme signal is simple: treat them as privileged runtime entities, not just applications. That means logging what they receive, what they decide, and what they execute. Without that chain of evidence, governance fails at the exact point attackers exploit.

For practitioners

• Separate trusted instructions from untrusted input Use explicit instruction segregation so user content, retrieved content, and system policy cannot be blended into one prompt path. This reduces the chance that malicious text can override governing instructions or steer tool use.
• Limit delegated agent permissions Scope each AI agent to the smallest set of APIs, datasets, and workflows needed for its task. Apply short-lived, task-specific permissions where possible so a manipulated prompt cannot produce broad blast radius.
• Add runtime policy enforcement Evaluate agent actions at execution time, not only at authentication time. Block or require review for data retrieval, administrative actions, and external system calls that do not fit the declared task.
• Monitor prompt and tool-call telemetry together Correlate the input a model receives with the actions it attempts, including MCP Server interaction where relevant. That correlation is what reveals whether a normal-looking prompt produced an abnormal action path.

Key takeaways

• Direct prompt injection works by steering AI runtime behaviour, so the control problem is execution integrity rather than classic vulnerability management.
• Identity verification alone cannot stop a manipulated agent from abusing legitimate delegated access, which is why runtime governance is now essential.
• Teams need policy enforcement, telemetry correlation, and tight permission scoping if AI agents are going to interact safely with enterprise systems.

Key terms

• 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.
• Inference Layer: The inference layer is the part of an AI system where prompts are processed and responses are generated. It matters because attacks can live between input validation and output filtering, where normal guardrails may not inspect the embedded instructions that actually shape behaviour.
• Execution Integrity: Execution integrity is the degree to which an agent’s runtime actions remain valid, authorised, and aligned with the original task. It depends on correct tool schemas, trustworthy intermediate state, and enforcement mechanisms that can block bad actions before they affect external systems.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

What's in the full article

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

• A step-by-step explanation of how direct prompt injection moves from malicious input to unauthorized tool execution.
• A fuller breakdown of why network, IAM, and API gateway controls cannot inspect model intent at runtime.
• Practical examples of runtime visibility and governance controls for AI agent execution paths.
• A vendor-specific view of how MCP Server interaction fits into prompt-injection detection and prevention.

👉 LEVO's full article covers the runtime detection and prevention detail behind prompt injection risk

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management. It helps security practitioners apply identity controls to the runtime systems their programmes increasingly depend on.