How do you detect prompt injection with static analysis?

Trace the dataflow from a request-data source (an HTTP request field, a websocket message, a form input) forward to see whether it reaches an LLM SDK call's system-role message or is concatenated directly into a system prompt string, without being scoped as a separate user-role message. A tool only qualifies as a real finding if the sink resolves through an actual import to a known LLM SDK — matching on the word 'prompt' or 'system' alone produces too many false positives to be useful, since those words also appear in unrelated code.

Is a keyword search for 'ignore previous instructions' enough to catch prompt injection?

No — that catches known injection phrases already present in text, which is useful for scanning untrusted content (like an MCP tool description) but doesn't catch the underlying code vulnerability, which is user input reaching a trusted prompt position with no isolation. An attacker doesn't need to use a well-known phrase; they need the code path to exist. Detecting the vulnerable pattern in code requires tracing data flow, not matching known attack strings.

What's the fix for prompt injection?

Keep system prompts static and pass user-controlled input as a user-role message instead of concatenating it into the system prompt. If untrusted input must inform system-level behavior, treat it as data to be validated or templated with strict boundaries, not as free text merged into the instruction the model treats as most authoritative.

How to Detect Prompt Injection in Code

Q: What is prompt injection?

Prompt injection is when untrusted input — user text, a fetched web page, a document, a tool result — reaches an LLM call in a position the model treats as an instruction, such as a system prompt or a position with elevated trust, instead of being clearly scoped as data. The model can't reliably distinguish 'text describing what the user wants' from 'text telling me what to do,' so whoever controls that input effectively controls part of the model's behavior. It is OWASP's LLM01:2026 category.

Short answer: trace data from a request source (HTTP body, form field, websocket message) forward through your code to see whether it lands in an LLM call's system-role message or gets concatenated into a system prompt string. If it resolves through a real import to a known LLM SDK and reaches that position unscoped, that's the vulnerability — independent of whether any specific attack phrase is present.

Why keyword matching doesn't work here

Scanning source code for phrases like "ignore previous instructions" catches text that's already sitting in a file — useful for checking untrusted content like an MCP tool description or a document you're about to feed to a RAG pipeline. It does not catch the underlying code vulnerability, because an attacker doesn't need to plant a famous phrase in your codebase — they need the code path to exist so that whatever they type at runtime lands somewhere the model treats as authoritative. The vulnerability is structural, not lexical.

What a traced finding looks like

A dataflow-based finding shows the actual path from an untrusted source, through however many function calls, to the exact LLM SDK call site it reaches:

HIGH  Prompt injection via user input
PROVEN  LLM01:2026 Prompt Injection

source  src/chat.ts:8   request data `req.body.input`
flow    src/chat.ts:13  passed as `systemPrompt`
sink    src/chat.ts:10  openai.chat.completions.create — system role (OpenAI)

fix     Keep system prompts static; pass user input as a user-role message.

Each line is checkable against the source file — that's what separates a traced finding from a keyword hit. Three things have to be true for this to count as a real (not heuristic) finding:

The sink is import-resolved. The call has to trace through an actual import to a known LLM SDK (OpenAI, Anthropic, the Vercel AI SDK, LangChain, Bedrock, etc.) — not just a function named something like chat() or complete().
The source is untrusted. Request bodies, query params, form inputs, websocket messages — not a hardcoded string or a value that only ever comes from your own config.
The position matters. Landing in a system-role message or being concatenated into a system-prompt string carries more trust than landing in a user-role message, which is the whole point — the model treats the two positions differently.

Trace it yourself

1. SourceFind where request-controlled data enters your code — an Express handler's req.body, a Next.js route's parsed form data, a webhook payload.

2. FlowFollow it through variable assignments, function parameters, and string concatenation — does it get merged into a prompt-building string anywhere along the way?

3. SinkCheck where it lands in the eventual LLM SDK call — a system-role message or a top-level system prompt is the dangerous position; a user-role message is the correct one.

Doing this by hand across a real codebase is slow and easy to miss — a value can pass through several functions before it reaches the sink. SecureAI-Scan automates exactly this trace via AST analysis (ts-morph for TypeScript/JavaScript, tree-sitter for Python), only flagging calls that resolve through real imports:

npx secureai-scan@0.9.0 scan .

Check an MCP tool description or config instead? That's a related but different check — invisible Unicode and injection phrasing in untrusted text, not code dataflow.

How to detect MCP tool poisoning →

Frequently asked questions

What is prompt injection?

Untrusted input reaching an LLM call in a position the model treats as an instruction — a system prompt or similarly elevated-trust position — instead of being clearly scoped as data. It's OWASP's LLM01:2026 category.

Does a "clean" scan mean the code is safe?

It means no traced dataflow from an untrusted source to a resolved LLM sink was found by the specific checks that ran. Static analysis is a filter, not proof of runtime safety — it can't see behavior that only emerges from how a model actually responds to a given input.

What's the fix?

Keep system prompts static; pass user-controlled input as a user-role message rather than concatenating it into the system prompt.

How to detect prompt injection in code

Why keyword matching doesn't work here

What a traced finding looks like

Trace it yourself

Frequently asked questions

What is prompt injection?

Does a "clean" scan mean the code is safe?

What's the fix?