How to Detect Prompt Injection in LangChain Retrieval Tools and Enforce Policy at Runtime

Detection techniques and their limits

Each technique fits a different point in the pipeline, and none is sufficient alone. The tradeoffs below should drive where you place each one and what you let it decide.

One data point shows why obvious signatures are not enough. A study cited by OWASP examined 196,682 resumes from a hiring platform and found that more than 90% of the hidden prompts contained no explicit instruction. Phrase matching would not have flagged most of them. The guidance does not supply accuracy or false-positive rates for any method, so measure these against your own content, including encoded and multilingual samples.

• Pattern and heuristic checks: Cheap and fast, and they suit chunk and tool-output screening and encoding alerts. Encoded and multilingual payloads evade them, and a clean result does not show the text is safe. Use them for alerting and as a supplementary layer.
• Classifier-based detection: OWASP recommends running retrieved context and tool output through a classifier before the primary model, and names open models such as Llama Guard, ShieldGemma, IBM Granite Guardian and Prompt Guard. It misses injections it fails to detect and content arriving through other channels. Added latency and false positives need measuring.
• Provenance and source-trust checks: Weight or restrict content by origin, so an external web page or inbound email is treated as less trusted than a curated knowledge base. This limits exposure but does not inspect content, and trusted sources can still be poisoned.
• Tool-call validation: Decide on the proposed operation, target, arguments and caller authority, not on keywords in the prompt. It is deterministic and strong against actions that were never authorized, but it cannot see a harmful answer that uses only permitted calls.
• Output inspection: An independent system reviews responses for signs of a successful injection. OWASP prefers this to system prompt instructions. It acts late, after the model has already processed the content.

Placing the checks in the execution path

Put each check where it can change the outcome. Screen retrieved chunks and tool output before they are assembled into the prompt, so the primary model never reads flagged content. Evaluate each proposed tool call before it runs. Inspect the model's response before it reaches the user or a downstream system.

Keep authorization out of the model. OWASP says privilege separation and authorization bounds checks must not be delegated to the LLM, including through the system prompt. Implement them in deterministic code that sees the proposed call and the caller's authority. Fail closed for unknown tools and for calls with no approval requirement defined.

Reduce what injection can reach. OWASP calls privilege minimization the most effective control. Scope each tool to the least access it needs, and prefer time-bounded, audience-specific grants so injected text cannot widen permissions. For web and retrieval tools, extract the structured fields you need rather than passing raw HTML to the model. Separate instruction context from tool-output context, and consider spotlighting, which NIST lists among input processing methods for helping a model distinguish trusted from untrusted data.

Re-run security testing after material changes to prompts, tools, memory, retrieval, policies or model providers, since each change moves the attack surface.

Evidence to retain for each decision

An auditor or regulator will ask what the system was allowed to do, what it did, and why a given decision was made. Answer that at the interaction and tool-call level. For each decision, retain the timestamp, the user and agent identity, the pipeline stage inspected, the detection method and its result, the policy that applied, the action taken, and the approver and outcome if the decision was escalated.

Also keep identifiers that tie a decision to its cause. NIST and OWASP both point toward correlating actions that do not match the original task with specific tool-retrieval events, so record the document or tool-result identifier and its source, not just the verdict.

OWASP advises logging security-relevant metadata and decisions while excluding credentials, secrets and unnecessary sensitive prompt or response content. For client-facing work this matters: store references, hashes and classifications in place of full retrieved text where you can, and set retention to match your obligations. Evidence should be produced by the enforcement point itself, so it reflects what was enforced rather than a reconstruction made later.

Before choosing a detection method, ask which stages it inspects, whether it runs before the model sees the content, what each decision records, and what false-positive and false-negative rates were measured, including against encoded content.

Where Trussed fits

Trussed is runtime control and evidence infrastructure for regulated enterprises. It enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate for human approval, scoped to individual interactions and tool calls. Enforcement is applied at runtime, not reviewed after the fact, and it generates continuous audit-ready evidence. It can be self-managed in the customer cloud, with configurable retention and data residency.

The approach in this guide does not depend on any one product. The requirement is that detection results lead to enforced decisions in the path of each retrieval and tool call, and that those decisions leave durable evidence.