Programma's voor continue redteaming

Doorlopende AI-redteamprogramma's ontwerpen en uitvoeren met geautomatiseerde testpijplijnen, metric-dashboards, KPI-frameworks, alert-gedreven assessments en integratie met CI/CD- en modeldeploymentworkflows.

Redteamopdrachten op één moment geven een momentopname van de securitypositie van een AI-systeem. Maar AI-systemen veranderen continu: modellen worden bijgewerkt, system prompts worden aangepast, nieuwe tools worden geïntegreerd en trainingsdata evolueert. Een bevinding die vorige maand is verholpen, kan deze maand weer opduiken door een modelupdate. Continue redteaming pakt dit aan door een doorlopend testprogramma op te zetten dat regressies detecteert, nieuwe kwetsbaarheden identificeert en de securitypositie over tijd volgt.

Programma-architectuur

Een programma voor continue redteaming bestaat uit vier lagen:

LAYER 4: GOVERNANCE & REPORTING
  Metrics dashboard | KPIs | Executive reporting | Program reviews

LAYER 3: MANUAL TESTING
  Periodic expert assessments | Novel technique research | Edge case discovery

LAYER 2: AUTOMATED TESTING
  Scheduled test suites | CI/CD integration | Alert-driven assessments

LAYER 1: MONITORING
  Output monitoring | Anomaly detection | User report triage

Elke laag geeft informatie door naar boven: monitoring detecteert afwijkingen, geautomatiseerd testen valideert ze, handmatig testen verkent nieuwe aanvallen en governance volgt de algehele trend.

Laag 1: monitoring

Continue monitoring vormt de basis door potentiële securityproblemen in real-time te detecteren:

Output-monitoring. Classificeer modeloutputs op schadelijke content, beleidsovertredingen en tekenen van een geslaagde injectie. Hiermee vang je aanvallen op die langs de inputverdediging glippen.

Anomalie-detectie. Volg gedragsmetrics (refusal rate, onderwerpverdeling, patronen van tool-calls) en sla alarm bij significante afwijkingen die kunnen wijzen op een geslaagde aanval of een regressie in veiligheidsgedrag.

Triage van gebruikersmeldingen. Bied een kanaal aan waar gebruikers onverwacht modelgedrag kunnen melden. Triageer meldingen om potentiële securityproblemen te onderscheiden van normale modelbeperkingen.

Laag 2: geautomatiseerd testen

Geautomatiseerde testsuites draaien op schema en bij triggerevents:

Geplande suites. Draai de volledige testsuite met een vaste cadans tegen productiemodellen (dagelijks voor kritieke systemen, wekelijks voor standaard).

CI/CD-integratie. Draai gerichte testsuites voor elke systeemwijziging:

• Modelversie-updates: volledige veiligheids- en injectietestsuite
• Wijzigingen aan system prompt: injectie- en hiërarchietestsuite
• Wijzigingen aan tool-integratie: testsuite voor toolmisbruik
• Wijzigingen aan guardrails: bypass-testsuite

Alert-gedreven assessments. Wanneer monitoring een afwijking detecteert, draai automatisch gerichte tests om vast te stellen of het om een kwetsbaarheid gaat.

Laag 3: handmatig testen

Geautomatiseerd testen vangt bekende aanvalspatronen op. Handmatig testen ontdekt nieuwe:

Periodieke expertassessments. Plan kwartaal- of maandelijkse handmatige assessments met focus op:

• Nieuwe aanvalstechnieken die sinds de vorige assessment zijn gepubliceerd
• Gecombineerde of geketende aanvallen die geautomatiseerde suites niet kunnen construeren
• Creatief adversarial testen waarvoor menselijke intuïtie nodig is
• Evaluatie van nieuwe systeemfeatures en integraties

Onderzoeksgestuurd testen. Wanneer er nieuw aanvalsonderzoek wordt gepubliceerd (papers, blogposts, conferentietalks), vertaal je de techniek naar testcases en voeg je ze toe aan de geautomatiseerde suite.

Geautomatiseerde testpijplijn

Pijplijnarchitectuur

TRIGGER (schedule, CI/CD event, alert)
  │
  ├── Test Suite Selection
  │   └── Based on trigger type and scope
  │
  ├── Test Execution
  │   ├── Run N trials per test case
  │   ├── Capture full evidence (logs, traces, configs)
  │   └── Calculate bypass rates
  │
  ├── Result Analysis
  │   ├── Compare against baseline bypass rates
  │   ├── Detect regressions (bypass rate increased)
  │   ├── Detect improvements (bypass rate decreased)
  │   └── Identify new findings
  │
  ├── Alerting
  │   ├── Critical: bypass rate > threshold for high-severity test
  │   ├── Warning: regression detected (bypass rate increased)
  │   └── Info: improvement detected (bypass rate decreased)
  │
  └── Reporting
      ├── Update metrics dashboard
      ├── Store evidence in repository
      └── Generate change reports

Indeling van testsuites

Orden testsuites op aanvalscategorie en severity:

Ontwerp van testcases voor automatisering

Geautomatiseerde testcases moeten deterministisch zijn in hun classificatie (ook al is modelgedrag stochastisch):

class TestCase:
    """Base class for automated red team test cases."""
 
    def __init__(self, name, category, severity, min_trials=10):
        self.name = name
        self.category = category
        self.severity = severity
        self.min_trials = min_trials
 
    def generate_payload(self) -> str:
        """Return the attack payload."""
        raise NotImplementedError
 
    def classify_response(self, response: str) -> str:
        """Classify model response as bypass, partial, or refusal."""
        raise NotImplementedError
 
    def run(self, model_client) -> dict:
        """Execute the test case and return results."""
        results = {"bypass": 0, "partial": 0, "refusal": 0}
        for trial in range(self.min_trials):
            payload = self.generate_payload()
            response = model_client.send(payload)
            classification = self.classify_response(response)
            results[classification] += 1
        results["bypass_rate"] = results["bypass"] / self.min_trials
        results["total_bypass_rate"] = (
            (results["bypass"] + results["partial"]) / self.min_trials
        )
        return results

Metrics en KPI's

Operationele metrics

Volg deze metrics op het live dashboard:

Programma-KPI's

Rapporteer deze KPI's per kwartaal aan de leiding:

Security posture score. Samengestelde metric die bypass-rates over alle categorieën combineert, gewogen op severity:

Score = 100 - sum(bypass_rate_i * severity_weight_i) for all test suites

Where severity_weight:
  Critical = 4.0
  High     = 3.0
  Medium   = 2.0
  Low      = 1.0

Score range: 0 (all tests bypassed) to 100 (no bypasses)

Trendmetrics.

• Verandering kwartaal-op-kwartaal in security posture score
• Verandering kwartaal-op-kwartaal in gemiddelde bypass-rate per categorie
• Mitigatie-tempo: percentage bevindingen dat binnen SLA is opgelost

Dekkingsmetrics.

• Geteste aanvalscategorieën (van totaal aantal gedefinieerde categorieën)
• Gedekte systeemcomponenten (van totaal aantal componenten)
• Percentage modelupdates dat getest is voor deployment

Dashboard-ontwerp

Een dashboard voor continue redteaming moet het volgende tonen:

1. Statuspaneel: algehele security posture score, actieve alerts, timestamp van de laatste testrun
2. Trendpaneel: trends in bypass-rate over tijd, per categorie
3. Regressiepaneel: bevindingen die geregresseerd zijn (bypass-rate is gestegen)
4. Dekkingspaneel: testdekking-kaart die geteste tegen niet-geteste gebieden toont
5. Alertgeschiedenis: recente alerts met status van afhandeling

CI/CD-integratie

Pre-deployment gates

Integreer redteam-testen als kwaliteitsgate in de deployment-pijplijn:

# Example CI/CD pipeline stage
ai-security-gate:
  stage: security
  trigger: on model or prompt change
  steps:
    - name: Run core safety suite
      command: redteam-cli run --suite core-safety --threshold 0.05
      # Fail if any critical test has > 5% bypass rate
 
    - name: Run regression suite
      command: redteam-cli run --suite regression --threshold 0.0
      # Fail if any previously-fixed finding reappears
 
    - name: Run injection suite
      command: redteam-cli run --suite prompt-injection --threshold 0.10
      # Fail if injection bypass rate exceeds 10%
 
  on_failure:
    - block deployment
    - notify security team
    - create incident ticket

Gate-thresholds

Definieer pass/fail-thresholds per suite en severity:

Alertbeheer

Alertclassificatie

Ruis bij alerts verminderen

Veelvoorkomende bronnen van false alerts bij AI-redteam-automatisering:

• Variantie in modelgedrag: stochastische modellen variëren van nature tussen runs. Gebruik betrouwbaarheidsintervallen om echte regressies van ruis te onderscheiden.
• Classificatiefouten: de antwoordclassifier markeert onschuldige outputs als bypasses. Verbeter de nauwkeurigheid van de classifier en voeg confidence-thresholds toe.
• Omgevingswijzigingen: API-latentie, rate limiting of tijdelijke storingen beïnvloeden testresultaten. Voeg health checks toe voor elke testrun.

Programma-governance

Rollen en verantwoordelijkheden

Reviewcyclus van het programma

Wekelijks: bekijk de geautomatiseerde testresultaten, triageer alerts, werk testcases bij voor pas gepubliceerde technieken.

Maandelijks: voer handmatige assessment uit met focus op nieuwe technieken. Bekijk programmametrics. Werk testsuites bij op basis van handmatige bevindingen.

Per kwartaal: KPI-review met de leiding. Beoordeel de effectiviteit van het programma. Pas thresholds, dekkingstargets en resource-allocatie aan. Plan de focuspunten van het volgende kwartaal.

Probeer het zelf

Gerelateerde onderwerpen

• Redteam-methodologie - Methodologie voor opdrachten op een specifiek moment
• Purple teaming - Samenwerkend testen geïntegreerd in continue programma's
• Bewijsverzameling - Standaarden voor geautomatiseerde bewijsverzameling
• Guardrails & filtering - Verdediging die door continue programma's getest wordt

Referenties

• Google (2024). "Securing AI: A Framework for Continuous Evaluation"
• MITRE (2024). ATLAS - Adversarial Threat Landscape for AI Systems
• NVIDIA (2024). Garak: LLM Vulnerability Scanner
• OWASP (2025). OWASP Top 10 for LLM Applications
• NIST (2024). AI Risk Management Framework