Detect LLM prompt flaws before deployment with static analysis

LLM security conversations rarely mention the code that defines prompts before any user input arrives. Yet the strings developers embed in their applications often contain the seeds of exploits that runtime tools cannot prevent. Static analysis offers a way to catch these issues early, during code review, using the same principles long trusted for SQL injection and API misuse.

The overlooked attack surface in prompt design

Production systems that rely on LLM APIs often ship system prompts, role definitions, and template strings alongside the rest of the codebase. These artifacts are written by developers, reviewed by humans, and merged without automated scrutiny. Unlike SQL queries or REST calls, prompt strings exist outside the usual security gates—parameterized queries, SAST scanners, and CI/CD checks.

A 2024 study from PromptSonar found that 68% of applications using LLM APIs included at least one prompt vulnerable to injection, privilege escalation, or prompt leakage. The common thread: developers copied examples from documentation, reused internal prompts across projects, or embedded user-controlled variables without sanitization. None of these flaws appear in runtime logs because they originate in the source code itself.

“The security review process for LLM prompts in most engineering teams was a human reading the prompt and hoping it looked fine.”

This approach treats prompt security as a matter of opinion rather than engineering discipline. Static analysis changes that equation by translating security rules into code reviews that run automatically before any prompt reaches an LLM.

Why runtime filters miss static risks

Tools like Google Model Armor and Azure Prompt Shields inspect incoming requests after they leave the application. They block jailbreaks, injection attempts, and policy violations in real time, but they cannot detect flaws baked into the prompt strings themselves. Consider the following scenarios:

• A system prompt grants unrestricted file access to the model. No user interaction is required; the vulnerability ships with the code.
• A template literal concatenates a user variable directly into a prompt without escaping. The code passes static analysis, but runtime filters may miss the pattern if the variable arrives empty.
• A configuration file loads a prompt at startup. Runtime tools never inspect the configuration layer.

Each of these risks originates in source code, where static analysis can catch them early. Runtime filters complement static checks but cannot replace them.

Building a static analysis pipeline for prompts

A robust static analysis workflow for prompt security requires three components: language-aware extraction, normalization, and rule evaluation. The goal is to identify every string literal that could reach an LLM API, regardless of how it is constructed.

Step 1: Extract prompt candidates from source code

PromptSonar uses Tree-sitter, a parser that builds concrete syntax trees for over 40 languages. The tool identifies prompt candidates in two ways:

• Framework pattern matching: Known LLM SDK calls are matched against the AST. Examples include openai.chat.completions.create() in TypeScript, anthropic.messages.create() in Python, and langchain PromptTemplate.fromTemplate() in JavaScript.
• Heuristic detection: String literals longer than 50 characters and appearing in AI-related contexts are flagged even without a matching SDK call. This catches custom HTTP clients and less common libraries.

The current release supports TypeScript, JavaScript, Python, Go, Rust, Java, and C#.

Step 2: Normalize prompts before evaluation

Extracted strings often vary in format—some are hardcoded, others use template literals or variables. Before applying security rules, the pipeline normalizes each candidate:

• Resolves template expressions into concrete strings where possible
• Removes escape sequences and formatting artifacts
• Hashes identical prompts to avoid redundant checks

This step ensures that security rules operate on the semantic content of the prompt, not its syntactic representation.

Step 3: Apply security rules to detect vulnerabilities

Once normalized, prompts are evaluated against a set of rules that mirror common LLM attack vectors. Examples include:

• Privilege escalation: Prompts that instruct the model to ignore system constraints or grant admin-like permissions
• Prompt leakage: Strings that ask the model to reveal its internal instructions or training data
• Injection risks: Templates that embed user variables without sanitization
• Overprivileged roles: System prompts that assign the model broad file system or network access

Each violation is reported with the file path, line number, and a suggested fix, enabling developers to address issues during code review.

Integrating prompt security into CI/CD

Static analysis for prompts works best when it operates at the same layer as other vulnerability scanners. Teams can integrate it into existing workflows in three ways:

• Pre-commit hooks: Run the scanner before each commit to catch issues early.
• Pull request checks: Gate merges on a clean scan, similar to SAST tools for SQL or XSS.
• Scheduled audits: Run comprehensive scans weekly to catch regressions in template libraries or configuration files.

The overhead is minimal—most scans complete in under 30 seconds for a medium-sized codebase—yet the coverage is comprehensive. Unlike runtime filters, static analysis does not add latency to user requests or create external dependencies.

A layered defense for LLM security

Static analysis for prompt security does not compete with runtime filters; it complements them. The two layers address different parts of the attack surface:

• Static analysis catches flaws in the codebase before deployment
• Runtime filters block attacks in production after deployment

Together, they provide defense in depth. Teams that rely solely on runtime screening are effectively leaving the windows unlocked while guarding the front door. Adding static analysis ensures that every layer of the application—from source code to user request—receives the same level of scrutiny.

Looking ahead, expect prompt security to evolve beyond simple rule sets. Machine learning models may soon classify prompts by risk level automatically, and IDE plugins could highlight high-risk patterns in real time. Until then, the most reliable method remains the one that has worked for decades: analyze the code before it ships.