Red Team CI/CD Integration

Integrating red team testing into your CI/CD pipeline shifts adversarial testing left — catching vulnerabilities at the PR stage rather than in production. A red team quality gate operates alongside your unit tests and integration tests: if a policy change, model update, or configuration change raises your Attack Success Rate above your threshold, the deployment is blocked.

For probe library details and ASR scoring, see the Red Team overview. For CLI installation and usage, see the quickstart guide.

Why CI/CD integration matters

AI application security is not static. Policy changes, model updates, new tool integrations, and retrieval corpus changes can all introduce regressions. Without automated testing:

A policy change that inadvertently loosens prompt injection defenses ships to production undetected
A model update changes behavior in ways that bypass existing DLP rules
A new plugin integration opens a supply chain attack surface that wasn’t present before

Automated red team testing catches these regressions the same way unit tests catch code regressions — at the PR stage, before they affect users.

GitHub Actions workflow

The following workflow runs a full red team assessment on every pull request to main and on a weekly schedule. Copy it into .github/workflows/red-team.yml:

name: Red Team Security Assessment

on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 2 * * 1'  # Weekly Monday 2 AM UTC

jobs:
  red-team:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install red team framework
        run: pip install arbitex-redteam

      - name: Run red team assessment
        env:
          ARBITEX_TOKEN: ${{ secrets.ARBITEX_TOKEN }}
        run: |
          arbitex-redteam scan \
            --target-url ${{ vars.ARBITEX_URL }} \
            --auth-token $ARBITEX_TOKEN \
            --output results/redteam-results.json

      - name: Quality gate
        run: arbitex-redteam gate --threshold 0.05

      - name: Upload results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: redteam-results
          path: results/
          retention-days: 90

Setup required:

Add ARBITEX_TOKEN as a repository secret (Settings > Secrets and variables > Actions > Secrets)
Add ARBITEX_URL as a repository variable (Settings > Secrets and variables > Actions > Variables)

The if: always() condition on the upload step ensures results are uploaded even when the quality gate fails — so you can review which probes bypassed defenses regardless of whether the check passed.

PR-gated red team testing

With the workflow above, every pull request to main triggers a full red team assessment. The Quality gate step exits with code 1 if ASR exceeds the threshold, which causes the GitHub Actions check to fail.

Configure your repository to require this check to pass before merging:

Go to Settings > Branches > Branch protection rules
Add or edit the rule for main
Enable Require status checks to pass before merging
Search for and add Red Team Security Assessment / red-team
Save the rule

With branch protection enabled, a PR that raises ASR above your threshold cannot be merged until the regression is remediated. This is particularly valuable for catching prompt injection regressions introduced by system prompt changes or policy updates.

Configuring ASR thresholds

Overall threshold

Pass a single threshold for the overall ASR across all probe categories:

arbitex-redteam gate --threshold 0.05

Recommended thresholds by deployment context:

Threshold	Use case
`0.02` (2%)	Strict — high-security environments handling sensitive data
`0.05` (5%)	Recommended — production deployments
`0.10` (10%)	Lenient — acceptable during initial deployment while tuning defenses

Per-category thresholds

For more granular control, set different thresholds per probe category:

arbitex-redteam gate \
  --threshold prompt-injection=0.03 \
  --threshold dlp-evasion=0.05 \
  --threshold supply-chain=0.02

Per-category thresholds let you enforce stricter limits on the attack surfaces most relevant to your deployment’s risk profile. For example, a deployment that handles personal data might set a tighter DLP evasion threshold while allowing a more lenient prompt injection threshold during an active tuning cycle.

The gate fails if any category exceeds its threshold.

SARIF integration with the GitHub Security tab

SARIF (Static Analysis Results Interchange Format) is a standard format that GitHub uses to populate the Security tab. Upload red team results as SARIF to surface findings alongside code scanning alerts:

Add --format sarif to the scan command:

      - name: Run red team assessment
        env:
          ARBITEX_TOKEN: ${{ secrets.ARBITEX_TOKEN }}
        run: |
          arbitex-redteam scan \
            --target-url ${{ vars.ARBITEX_URL }} \
            --auth-token $ARBITEX_TOKEN \
            --format sarif \
            --output results/redteam-results.sarif

Add a SARIF upload step after the quality gate:

      - name: Upload SARIF
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: results/redteam-results.sarif

With SARIF upload in place, successful probe bypasses appear as security alerts in the GitHub Security tab, where they can be triaged, assigned, and tracked to resolution alongside other code scanning findings.

Scheduled assessments

The workflow’s schedule trigger runs a full assessment every Monday at 2 AM UTC, independent of any PR activity. Scheduled runs catch regressions that don’t originate from code changes:

Model updates: If your deployment uses a model that receives silent updates from the provider, behavior can change without a code commit
Policy drift: Configuration changes applied directly to your Arbitex instance rather than through source control
Infrastructure changes: Network topology or proxy configuration changes that affect how Arbitex enforces policies
Retrieval corpus changes: New documents added to a RAG system that introduce supply chain attack surface

Scheduled run results are uploaded as artifacts with 90-day retention. Review weekly trends in the Actions tab to identify gradual ASR increases that might not trigger individual PR gates but indicate systemic drift.

To compare results across runs and detect trend changes, export in json format and feed results into your observability tooling alongside other security metrics.

Complete workflow reference

Full workflow with both JSON artifact upload and SARIF Security tab integration:

name: Red Team Security Assessment

on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 2 * * 1'  # Weekly Monday 2 AM UTC

jobs:
  red-team:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install red team framework
        run: pip install arbitex-redteam

      - name: Run red team assessment
        env:
          ARBITEX_TOKEN: ${{ secrets.ARBITEX_TOKEN }}
        run: |
          mkdir -p results
          arbitex-redteam scan \
            --target-url ${{ vars.ARBITEX_URL }} \
            --auth-token $ARBITEX_TOKEN \
            --format sarif \
            --output results/redteam-results.sarif

      - name: Quality gate
        run: arbitex-redteam gate --threshold 0.05

      - name: Upload results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: redteam-results
          path: results/
          retention-days: 90

      - name: Upload SARIF
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: results/redteam-results.sarif

Red Team overview — probe library, campaign strategies, and scoring methodology
Red Team quickstart — installation, scan commands, and configuration file reference
Compliance mapping — OWASP LLM Top 10, MITRE ATLAS, NIST AI RMF, and EU AI Act coverage