How should security teams review LLM and agent code for prompt injection risks in production workflows?

Prompt Injection Becomes a Review Problem When Code Can Cross Trust Boundaries

Prompt injection is not just a model-quality issue. It becomes a production security problem when application code lets untrusted text influence system instructions, tool selection, retrieval context, or agent actions. That means reviewers need to trace data flow from user input through prompts and orchestration logic, then ask where the model could be tricked into treating attacker-controlled content as trusted guidance. The most important failure is often boundary collapse, not syntax.

For teams reviewing agentic workflows, the right reference point is how the system handles untrusted input, instruction hierarchy, and tool authority. OWASP’s OWASP Top 10 for Agentic Applications 2026 is useful here because it treats instruction abuse, tool misuse, and trust boundary failures as application risks rather than abstract AI concerns. In practice, many teams discover prompt injection only after an agent has already been allowed to read, reinterpret, or act on text that should never have influenced privileged behaviour.

How Security Reviews Should Trace Prompt Injection Exposure in Production

A useful review starts with the prompt path, not with the model. Security teams should map every place where external content can enter the workflow: user messages, uploaded files, web pages, emails, retrieved documents, API responses, logs, and memory. Then they should identify where that content is concatenated into system prompts, passed into planning steps, or used to decide whether tools may run. If attacker-controlled text can alter instructions, the system has an injection surface even if the model itself is unchanged.

The practical review question is whether the application preserves a hard separation between data and instructions. That means reviewers should look for explicit instruction hierarchies, context labelling, allowlists for tools, and approval gates for actions that create side effects. It also means checking whether the code assumes the model will reliably ignore malicious text embedded in a document, page, or message. That assumption is weak unless the architecture constrains what the model can see, what it can choose, and what it can execute.

• Review ingress points first: anything retrieved, pasted, uploaded, or forwarded into the prompt may be attacker controlled.
• Check whether system instructions are isolated from user and retrieval content, rather than mixed into a single prompt blob.
• Verify that tool calls require explicit policy checks, not model self-approval.
• Confirm that high-impact actions such as sending messages, modifying records, or launching workflows need human approval or a strict policy gate.
• Test with malicious strings that try to override role, policy, or tool instructions, then observe whether the workflow resists them.

NIST’s NIST AI Risk Management Framework is relevant when teams need a governance lens for mapping these controls to risk management, but the review itself should stay close to implementation reality. Where the workflow relies on retrieval, memory, or external content, the review should also ask whether those sources are trustworthy enough to shape agent behaviour at all. The guidance breaks down when teams treat the prompt as the only security boundary and ignore the code paths that assemble, route, and execute model outputs.

Where Prompt Injection Reviews Break Down in Real Production Systems

Tighter prompt filtering often increases operational friction, so teams need to balance blocking obvious injection patterns against preserving legitimate use of rich input and retrieval. The real tradeoff is that overly permissive context handling improves convenience while expanding the set of places where malicious instructions can hide.

One common edge case is indirect prompt injection through retrieved content. A model may never receive a direct malicious user prompt, but it can still ingest hostile instructions embedded in a page, ticket, or document that the application later treats as context. Another is multi-step agents: a single prompt may look safe, but the agent’s next step can combine model output with tool access and create a harmful sequence. This is where static code review alone is insufficient; teams need to inspect orchestration logic, tool permissions, and the conditions under which the model can escalate from suggestion to action.

There is also a governance difference between low-impact assistance and workflows that can change state. Teams can sometimes tolerate higher exposure in drafting or summarisation features, but once the agent can send, delete, approve, purchase, or modify, the review standard should be stricter. OWASP’s OWASP Agentic AI Top 10 is especially useful for framing these agent-side failure modes, while MITRE ATLAS adversarial AI threat matrix helps teams think about adversarial misuse patterns and abuse paths. This guidance fails when reviewers focus only on prompt text and ignore the downstream authority granted to the model or agent.

Risk and Threat Considerations

Prompt injection creates a material risk when attacker-controlled content can influence privileged reasoning, tool selection, or action execution. The exposure is highest in agentic workflows because the model is not only generating text, it is also participating in decisions that can reach external systems, data stores, or business processes.

Failure mechanism: The compromise pattern is trust confusion. Untrusted text is assembled into a context window or retrieved corpus, the model interprets it as instruction-like input, and the orchestration layer then acts on the model’s output without a strong policy gate. That can lead to data leakage, unauthorised tool use, or execution of harmful actions.

Impact: The result can be confidentiality loss, integrity failure, or unsafe automation. In agentic systems, the blast radius can include downstream systems the model was never supposed to control, especially when tools inherit broad permissions or when approvals are treated as a formality.

Practitioner Guidance

What to verify: Reviewers should verify that every place untrusted content enters the workflow is explicitly labelled and constrained, and that no single prompt string silently combines user input, retrieved content, and system policy. If the code cannot show where instruction authority changes hands, the review is incomplete.

Decision rule: If a model output can trigger a state change, external call, or privileged tool action, treat prompt injection as a control design issue rather than a content-filtering issue. If the workflow is read-only, the acceptable control set is lighter, but the trust boundary still needs to be explicit.

What practitioners underestimate: Teams often underestimate how quickly “helpful” retrieval and memory features turn into implicit instruction channels. The important judgement is not whether the model can be manipulated in theory, but whether a malicious string can survive the code path long enough to influence a real action.

Practitioner takeaway: The safest review posture is to assume the model will see hostile instructions, then prove that the workflow still prevents those instructions from becoming authority.

Related resources from NHI Mgmt Group

• How should security teams scan LLM application code for prompt injection risks in pull requests?
• How should security teams prevent prompt injection in AI agent workflows?
• How should security teams handle prompt injection in production LLM applications?
• What breaks when security teams review source code but ignore compiled artifacts in agent workflows?