LLM Security Testing in CI/CD: How to Catch Prompt Injection Regressions Before They Ship

The regression problem nobody talks about

You shipped your LLM feature. It passed your pre-launch review. You tested the happy path, checked the system prompt, confirmed the model refused a few obvious jailbreak attempts. Good enough.

Then two weeks later, you update your system prompt to improve tone. Or your provider silently rolls out a new model version. Or you add a RAG integration that pulls from a new document source.

You do not re-test. Why would you? The feature already shipped.

This is how prompt injection regressions happen. Not at launch. After launch, after a change that seemed unrelated to security. The attack surface shifts and nobody notices until someone finds it.

LLM security testing in CI/CD closes that gap. It makes adversarial testing a repeatable, automated step in your deployment process, not a one-off pre-launch ritual.

Why LLM security belongs in your pipeline

Traditional application security fits naturally into CI/CD. Static analysis runs on every commit. Dependency scanners flag known CVEs. Integration tests catch broken contracts.

LLM-powered features break this model. The behavior of your /chat or /complete endpoint is not fully determined by your code. It depends on the model, the system prompt, the retrieval context, and how those three interact with adversarial input. Any one of those can change without a code commit.

That means your existing test suite does not cover the attack surface. A green build does not tell you whether your chatbot will follow a prompt injection instruction embedded in a user message. It does not tell you whether a DAN-style jailbreak bypasses your content policy after a model update. It does not tell you whether your system prompt leaks when a user asks the right question.

Adding LLM security testing to your pipeline is not about compliance. It is about catching real failures before users or attackers find them.

What to test for: the three attack surfaces that regress

Prompt injection

Prompt injection (OWASP LLM01) is the most common regression vector. Your system prompt defines rules. A prompt injection payload attempts to override those rules by injecting new instructions through user input or retrieved content.

Direct injection arrives through the user turn. Indirect injection arrives through data your application retrieves, such as a document, a database record, or a web page, that contains embedded instructions.

Both regress when you change your system prompt wording, update your retrieval pipeline, or switch models. A model that previously ignored injected instructions may follow them after a version update.

Jailbreaks

Jailbreaks (OWASP LLM02) bypass your safety logic through role-play framing, hypothetical scenarios, or encoded instructions. DAN-style attacks ask the model to pretend it has no restrictions. Role-play attacks establish a fictional context where the safety rules supposedly do not apply.

These regress after model changes. A fine-tuned or updated model often has different sensitivity to specific jailbreak patterns. What your previous model refused, the updated model may comply with.

System prompt leaks

Your system prompt is not secret by default. Direct disclosure attacks ask the model to repeat its instructions. Partial hint attacks extract fragments through indirect questions.

System prompt leaks (OWASP LLM06) regress when you change the prompt itself, add new instructions that reference sensitive configuration, or update to a model with different instruction-following behavior around disclosure.

How to structure LLM security testing in CI/CD

Step 1: Define your endpoint and configure the scanner

Your LLM feature exposes an endpoint. It accepts a JSON body, returns a JSON response, and probably requires an Authorization header. That is all you need to start.

With BastionLLM, you paste the endpoint URL, configure your request headers, and specify the response field path using dot notation so the scanner knows where to find the model output in your response body. It supports REST endpoints with JSON responses and SSE/NDjson streaming responses.

No agent to install. No SDK to integrate. No changes to your application code.

The configuration lives outside your codebase, which means you can update it independently of your deployment process.

Step 2: Set pass/fail thresholds

Every scan returns scored results per attack category. You decide what constitutes a failure for your pipeline.

A reasonable starting threshold: fail the build if any prompt injection payload successfully overrides a system-level instruction, or if any system prompt leak returns direct disclosure. Jailbreak thresholds depend on your application's risk profile. A customer support chatbot has different tolerance than an internal tool with no public exposure.

BastionLLM returns pass/fail verdicts on the free plan and regex plus heuristic verdicts on Pro. The Pro plan runs over 489 test payloads per scan, which gives you enough coverage to catch non-obvious attack variants, not just the obvious ones.

Document your thresholds explicitly. When a scan fails, the engineer reviewing the output needs to know whether the failure is a blocker or a warning.

Step 3: Trigger scans on the right events

Not every commit needs a full LLM security scan. A full scan against 489 payloads takes time. You want to trigger it on events that actually change the attack surface.

Trigger a scan on:

• System prompt changes. Any commit that modifies the prompt file or prompt template should kick off a full scan before the change reaches production.
• Model version updates. When you pin to a new model version or change your provider configuration, run a full scan against the updated endpoint.
• RAG pipeline changes. New retrieval sources, updated chunking logic, or modified context injection patterns all affect indirect prompt injection exposure.
• Integration changes. New tools, plugins, or function call definitions change what the model can do if successfully injected.

For pull requests that do not touch any of these, a lighter scan or no scan is fine. Prioritize coverage where the risk actually changes.

Step 4: Schedule recurring scans for model-level changes

Here is the problem with event-triggered scans alone: your model provider can update the underlying model without notifying you. OpenAI, Anthropic, and most providers reserve the right to update non-pinned model versions. Even pinned versions sometimes change.

Scheduled weekly scans catch these regressions. You did not change anything. The model did. The scan tells you before a user does.

BastionLLM Pro includes weekly automated scans. You configure the endpoint once, set the schedule, and the scan runs without manual intervention. Results are stored in 12-month scan history, so you can compare current results against the baseline from before the model update.

This is the part that no open-source alternative handles well. Garak requires local installation and manual execution. PyRIT requires deep expertise to operate. Neither gives you a scheduled hosted scan against a live endpoint.

Practical pipeline patterns

Here are three patterns that work in practice:

Pattern 1: Pre-merge gate on prompt changes

Add a CI step that triggers a BastionLLM scan when a pull request modifies your prompt files. The step calls the BastionLLM API, waits for results, and fails the pipeline if any prompt injection payload succeeds. Engineers see the raw output in the CI log and fix the prompt before merge.

Pattern 2: Post-deploy smoke test

After deploying to staging, trigger a scan against the staging endpoint. This catches integration-level failures that only appear when the full stack is running. Use the free plan's 25 attacks per scan for a quick smoke test, or Pro's 450-plus attacks for full coverage.

Pattern 3: Weekly regression baseline

Use BastionLLM's scheduled weekly scans to maintain a security baseline. Compare each week's results against the previous scan in the 12-month history. A new failure that appears without a code change points to a model-level regression.

What the raw output tells you

A scored result without raw output is not useful for engineers. You need to see exactly what payload was sent, what the model returned, and why the verdict was a failure.

BastionLLM returns raw model outputs alongside verdicts. If a prompt injection payload succeeded, you see the model's actual response to that payload. You can reproduce the failure locally by sending the same payload to your endpoint. You can then modify your system prompt or input validation logic and re-run the scan to confirm the fix.

This is the loop that matters: find the failure, reproduce it, fix it, verify the fix. Raw output makes that loop possible without involving a separate red team or waiting for a specialist review.

PDF and JSON export on Pro lets you attach scan results to pull requests, incident reports, or compliance documentation.

Where the current tooling falls short

Most LLM security tools were not designed with CI/CD in mind.

Garak is open-source and technically capable, but it requires local installation, Python environment management, and ongoing maintenance. Running it in a CI environment means maintaining a Docker image or a managed runner with the right dependencies. That is friction most teams will not sustain.

PyRIT is Microsoft's red teaming framework. It is powerful for agentic scenarios but requires deep AI and security expertise to configure. It has no hosted endpoint testing mode. Integrating it into a pipeline is a project, not a step.

Mindgard targets enterprise security teams with dedicated AI budgets. It requires significant setup and is designed for periodic assessments, not continuous monitoring. It is not built for the engineer who wants to add a CI step before a Friday deploy.

Runtime protection tools like Lakera Guard and LLM Guard sit in the request path and block attacks at inference time. That is a different problem. They do not tell you whether your endpoint is vulnerable before you deploy.

BastionLLM is designed for the workflow described in this article. Paste a URL, configure headers, run a scan, get results. No installation, no setup friction, no sales call. The Pro plan at 29 euros per month, or 23 euros per month billed annually, gives you scheduled scans, 12-month history, and full OWASP LLM Top 10 coverage across 489 payloads.

FAQs

Start testing before the next deploy

One-time pre-launch testing is not enough. Every system prompt change, model update, and new integration is a potential regression. The only way to catch those regressions reliably is to make adversarial testing a repeatable step in your pipeline.

Start with a guest scan at bastionllm.com — no account required, 6 attacks, results in minutes. If your endpoint passes, you have a baseline. If it fails, you have something to fix before it ships.