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

Why This Matters for Security Teams

Prompt injection is not just a model-quality problem. In production, it becomes a control failure when untrusted text can influence system prompts, tool routing, retrieval content, or downstream actions. That matters because LLMs and agents do not merely “read” content, they may execute instructions, call APIs, and shape workflows based on that content. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point security teams toward boundary control, context control, and runtime governance rather than content filtering alone.

The practical review question is simple: where can hostile input cross from user space into model intent, tool authority, or privileged automation? NHIMG research on AI Agents: The New Attack Surface report shows why this is urgent, with 80% of organisations reporting agents have already taken actions beyond intended scope and 23% saying sensitive credentials were revealed. In practice, many security teams discover prompt injection only after an agent has already chained through tools and moved beyond the original workflow.

How It Works in Practice

Security review should start by mapping instruction paths, not just code paths. The highest-risk patterns are places where external content can be concatenated into prompts, inserted into memory, used as retrieval context, or passed to an agent that also has tool access. Reviewers should trace each trust boundary and ask whether the model can distinguish user data from system guidance. The answer is often “not reliably,” which is why prompt structure, isolation, and runtime controls matter more than wording alone.

A useful review workflow is to inspect three layers:

• Prompt assembly: identify all sources that can alter system prompts, developer messages, hidden instructions, or agent state.
• Tool execution: confirm the agent cannot invoke sensitive tools without policy checks, allowlists, or human approval.
• Output handling: ensure the model cannot exfiltrate secrets, tokens, or internal instructions into logs, tickets, or responses.

For production workflows, best practice is evolving toward policy-as-code and runtime decisioning. That means sanitising or tagging untrusted content, separating retrieval data from instructions, and placing approval gates before irreversible actions. The CSA MAESTRO agentic AI threat modeling framework and NHIMG analysis in Analysis of Claude Code Security both reinforce that agent security depends on controlling what the system can act on, not just what it can see. Teams should also test for indirect injection through documents, tickets, emails, and web content that an agent may ingest automatically.

These controls tend to break down when agents are allowed broad tool access across loosely governed workflows, because one poisoned input can steer multiple downstream actions before any human review occurs.

Common Variations and Edge Cases

Tighter prompt and tool controls often increase engineering overhead, requiring organisations to balance workflow speed against the need for stronger trust boundaries. That tradeoff is especially visible in agentic systems that rely on retrieval-augmented generation, autonomous task completion, or code-generation assistants.

There is no universal standard for this yet, but current guidance suggests treating the following cases as higher risk: agents that can write files, trigger deployments, send messages, approve requests, or query internal systems. In these environments, a prompt injection may not stop at a bad answer. It can become a privileged action if the agent is allowed to continue operating after the malicious instruction lands.

Reviewers should also be careful with “safe” wrappers that only scan for malicious phrases. Prompt injection is often contextual, using seemingly harmless content to redirect intent. The better pattern is defense in depth: bounded prompts, explicit allowlists, context separation, step-up approval for sensitive actions, and logging that preserves the full prompt and tool chain for audit. NHIMG’s Gemini AI Breach illustrates how cross-boundary content can create real exposure when a seemingly ordinary integration is allowed to influence agent behaviour. This is why prompt injection reviews should be repeated whenever the workflow, data sources, or tool permissions change.

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?