Phase 8: Production AI Security Architecture · 60 min · Promptfoo · GitHub Actions · pytest

CI/CD for AI Security

A security control you test manually once is a security control you'll forget to re-test after the next prompt change.

Hiring signal: DevSecOps for AI Pipelines roles ($150k-$210k) exist specifically because manual red-teaming (Phase 6 of this course) doesn't scale to a team shipping prompt changes daily. Interviewers ask candidates to design a CI pipeline that blocks a deploy on a failed adversarial test or guardrail regression -- not describe one abstractly, but show the gate script and the exit code logic. This lesson builds exactly that: a `check_security_gates.py` you could drop into a GitHub Actions workflow today.

What you will learn

Design an automated adversarial test suite (injection, jailbreak, PII-leak payloads) that runs against a guardrail pipeline on every change
Build a guardrail regression gate that fails when previously-blocked attack categories are no longer blocked
Write a security gate script that exits non-zero on failure, matching the contract CI systems expect from a check step
Wire adversarial testing and guardrail regression into a GitHub Actions workflow that blocks merge/deploy on failure

The Problem

By Phase 6 of this course you knew how to red-team a system by hand: run Garak, run PyRIT, try the injection payloads from Phase 2, confirm the guardrails from Phase 5 hold. That's real work, and it finds real vulnerabilities. It also doesn't survive contact with a team that ships prompt changes, model version bumps, and guardrail config edits every day.

Here's the failure mode this lesson exists to prevent, and it is not hypothetical — it's the single most common way real guardrail regressions ship to production: an engineer is debugging a false-positive complaint ("the bot blocked a customer asking about their lost social security card"), temporarily disables the injection detector to isolate the bug, fixes the false positive, and merges — without re-enabling injection detection. Nobody red-teamed the merged PR by hand, because red-teaming by hand doesn't happen on every PR. The system ships to production with prompt-injection detection silently off until someone notices, usually because an attacker did.

The fix isn't "remember to test more carefully." The fix is turning the Phase 6 red-team suite and the Phase 5 guardrail checks into code that runs automatically on every change and fails the build — the same trust model a team already has for unit tests, just applied to security. This is exactly what DevSecOps for AI Pipelines roles ($150k-$210k) are hired to build, and it's why interviews for that role ask candidates to produce the gate script, not describe the concept.

Gate 1: Automated Adversarial Testing in CI

The first gate is a fixed adversarial suite — a set of known attack payloads (injection, jailbreak, PII-leak, tool-abuse) that must be blocked by the guardrail pipeline under test, run automatically on every pull request. This is the CI-native version of what Garak and PyRIT do interactively in Phase 6: a fixed, reproducible battery of attacks, except now it runs on git push instead of when someone remembers to run it.

Two properties make this gate trustworthy rather than theater:

It must include benign controls, not just attacks. A gate that only checks "are attacks blocked" can be passed by a guardrail so aggressive it blocks half of legitimate traffic — you'd never know, because nothing in the suite checks for false positives. Every adversarial case in this lesson's suite is paired with benign cases that must specifically not be blocked, including a deliberately tricky one ("my social security card was lost, what's the process for replacing it?") designed to look like a PII-leak attempt to a keyword-only filter but is legitimate.
It must exit non-zero on failure. CI systems don't parse prose. A gate script that prints "3 tests failed" but exits 0 will merge the PR anyway. The contract every CI system expects from a check step is the process exit code, and this lesson's check_security_gates.py is built around that contract from the first line.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Gate 2: Guardrail Regression Testing, Security Gates for Model Deployment, Wiring It Into GitHub Actions, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.