Guardrails- & veiligheidslaagarchitectuur

Hoe guardrail-systemen architectonisch zijn ontworpen, inclusief voorverwerkings-, inverwerkings- en naverwerkingslagen, veelvoorkomende ontwerppatronen, en waar elke laag kan worden omzeild.

Guardrail-systemen zitten rond het LLM als lagen pantser. Begrip van hun architectuur -- hoe ze zijn gestructureerd, hoe data erdoorheen stroomt, en waar de naden zitten -- is essentieel voor systematische omzeiling.

De drielaagse architectuur

Vrijwel alle productie-guardrail-systemen volgen een drielaags patroon:

                    ┌──────────────────┐
   User Input ────→ │  PRE-PROCESSING  │ ──→ Block/Allow
                    │  (Input Guards)  │
                    └────────┬─────────┘
                             │ (allowed)
                    ┌────────▼─────────┐
                    │  IN-PROCESSING   │
                    │  (Model + Prompt │ ──→ Generation
                    │   Constraints)   │
                    └────────┬─────────┘
                             │ (generated)
                    ┌────────▼─────────┐
                    │ POST-PROCESSING  │ ──→ Block/Redact/Allow
                    │ (Output Guards)  │
                    └──────────────────┘

Laag 1: Voorverwerking

Voorverwerkingsguards analyseren gebruikersinvoer voordat deze het model bereikt. Ze werken op de ruwe tekst (of multimodale invoer) en beslissen of het verzoek wordt toegestaan, aangepast of geblokkeerd.

Omzeilingsfocus: Codering, obfuscatie, semantische parafrasering, payloads uit meerdere delen die afzonderlijk goedaardig lijken. Zie Systemen voor in-/uitvoerfiltering.

Laag 2: Inverwerking

Inverwerkingsverdedigingen werken tijdens modelinferentie. Ze maken deel uit van het eigen gedrag van het model en de prompt engineering eromheen.

• Systeempromptinstructies -- gedragsbeperkingen die in de prompt zijn geschreven
• Instructiehiërarchie -- modeltraining die systeeminstructies prioriteert boven gebruikersinvoer
• Samplingbeperkingen -- temperatuurlimieten, logit-bias, stopsequenties
• Tokenbudgetten -- het beperken van de uitvoerlengte om grootschalige exfiltratie te voorkomen

Omzeilingsfocus: Prompt-injectie, jailbreaken, contextmanipulatie. Deze aanvallen richten zich op de besluitvorming van het model in plaats van op externe filters.

Laag 3: Naverwerking

Naverwerkingsguards analyseren de uitvoer van het model voordat deze aan de gebruiker wordt teruggegeven.

• Inhoudsclassifiers -- ML-modellen die schadelijke inhoud in het antwoord detecteren
• PII-detectie -- regex- en NER-modellen die het lekken van persoonsgegevens opvangen
• Formaatvalidators -- zorgen dat de uitvoer overeenkomt met het verwachte schema (JSON, specifieke velden)
• LLM-rechters -- secundaire LLM evalueert of het antwoord het beleid schendt

Omzeilingsfocus: Uitvoer coderen (base64, rot13), metaforen of een fictiekader gebruiken, schadelijke inhoud over meerdere antwoorden verdelen, categoriegaten in classifiers uitbuiten.

Ontwerppatronen

Patroon 1: Sequentiële pijplijn

Elke guard draait achtereenvolgens. Als een guard blokkeert, wordt het verzoek geweigerd.

def process_request(user_input: str) -> str:
    # Voorverwerking
    if not input_classifier.is_safe(user_input):
        return "I cannot process this request."
    if not prompt_shield.check(user_input):
        return "I cannot process this request."
 
    # Inverwerking
    response = llm.generate(system_prompt + user_input)
 
    # Naverwerking
    if not output_classifier.is_safe(response):
        return "I cannot provide that information."
    response = pii_redactor.redact(response)
 
    return response

Zwakte: Eén enkele omzeiling bij welke voorverwerkingslaag dan ook laat de invoer door. Naverwerking wordt dan de enige overgebleven verdediging.

Patroon 2: Parallelle evaluatie

Meerdere guards evalueren tegelijkertijd. Het verzoek gaat alleen door als alle guards het eens zijn.

async def process_request(user_input: str) -> str:
    # Voer alle voorverwerkingsguards parallel uit
    results = await asyncio.gather(
        input_classifier.is_safe(user_input),
        prompt_shield.check(user_input),
        embedding_scanner.check(user_input),
    )
    if not all(results):
        return "I cannot process this request."
 
    response = await llm.generate(system_prompt + user_input)
 
    # Voer alle naverwerkingsguards parallel uit
    post_results = await asyncio.gather(
        output_classifier.is_safe(response),
        pii_detector.check(response),
        policy_judge.evaluate(response),
    )
    if not all(post_results):
        return "I cannot provide that information."
 
    return response

Zwakte: Alle guards moeten tegelijkertijd worden omzeild, maar ze delen vergelijkbare detectieparadigma's. Een invoer die één ML-classifier ontwijkt, ontwijkt vaak ook anderen die op vergelijkbare data zijn getraind.

Patroon 3: Getrapte escalatie

Snelle, goedkope guards draaien eerst; dure guards draaien alleen als de eerste controles dubbelzinnig zijn.

def process_request(user_input: str) -> str:
    # Trap 1: Snelle controles (regex, blocklist)
    risk_score = fast_scanner.score(user_input)
    if risk_score > HIGH_THRESHOLD:
        return block_response()
 
    # Trap 2: ML-classifier (alleen als trap 1 onzeker is)
    if risk_score > LOW_THRESHOLD:
        if not ml_classifier.is_safe(user_input):
            return block_response()
 
    # Trap 3: LLM-rechter (alleen voor hoogrisicoscores die trap 2 passeerden)
    if risk_score > MEDIUM_THRESHOLD:
        if not llm_judge.approve(user_input):
            return block_response()
 
    return llm.generate(system_prompt + user_input)

Zwakte: Invoer die onder LOW_THRESHOLD scoort, omzeilt alle classificatie volledig. Red teamers zouden "saai ogende" payloads moeten maken die onder trap 1 doorglippen.

Synchrone vs. asynchrone verdedigingen

Veelvoorkomende architectonische zwaktes

1. Inconsistente dekking over endpoints -- het hoofd-chat-endpoint heeft guardrails, maar het completion-endpoint of het function-calling-endpoint niet
2. Tool-aanroepen omzeilen uitvoerfilters -- de argumenten van de tool-aanroep van het model worden niet op dezelfde manier gefilterd als de tekstuitvoer
3. Streaming omzeilt naverwerking -- in streamingmodus ziet de naverwerking de volledige uitvoer mogelijk niet voordat chunks naar de gebruiker worden verzonden
4. Multimodale gaten -- tekstinvoer wordt gefilterd, maar beeld-, audio- of bestandsinvoer niet
5. Sessiestatus wordt niet bijgehouden -- guards evalueren elk bericht onafhankelijk en missen escalatiepatronen over meerdere beurten

Verder lezen

• Systemen voor in-/uitvoerfiltering -- diepgaande verkenning van filtertypes en omzeilingstechnieken
• Prompt shields & injectiedetectie -- speciale injectiedetectiesystemen
• LLM-als-rechter-verdedigingssystemen -- LLM's gebruiken om andere LLM's te evalueren
• Defense-in-depth voor LLM-apps -- gelaagde verdedigingsstrategie

Verwante onderwerpen

• Systemen voor in-/uitvoerfiltering - Diepgaande verkenning van filtertypes en omzeilingstechnieken
• Prompt shields & injectiedetectie - Speciale injectiedetectiesystemen
• LLM-als-rechter-verdedigingssystemen - LLM's gebruiken om andere LLM's te evalueren
• Defense-in-depth voor LLM-apps - Gelaagde verdedigingsstrategie
• Het AI-verdedigingslandschap - Bredere kijk op verdedigingstools en de markt

Referenties

• "NVIDIA NeMo Guardrails: Programmable Safety" - NVIDIA (2024) - Documentation for the open-source guardrails framework implementing dialog-flow-based safety rails
• "Guardrails AI: Output Validation Framework" - Guardrails AI (2025) - Schema-based output validation framework for LLM applications
• "LLM Guard: Comprehensive Input/Output Scanning" - ProtectAI (2025) - Open-source toolkit implementing multi-layer input and output scanning
• "Rebuff: Self-Hardening Prompt Injection Detector" - Rebuff (2024) - Multi-layer prompt injection detection combining heuristic, LLM, and embedding approaches