Framework voor het scoren van aanvalsresultaten
Een framework ontwikkelen om aanvalsresultaten automatisch te scoren op basis van meerdere succescriteria.
Overzicht
Een framework ontwikkelen om aanvalsresultaten automatisch te scoren op basis van meerdere succescriteria.
Dit onderwerp vertegenwoordigt een cruciaal gebied binnen AI-beveiliging dat het onderwerp is geweest van veel onderzoek en misbruik in de praktijk. Inzicht in de concepten, technieken en defensieve maatregelen die hier worden behandeld, is essentieel voor iedereen die in AI-beveiliging werkt, of dat nu in een offensieve of defensieve rol is.
Zou et al. 2023 — "Universal and Transferable Adversarial Attacks on Aligned Language Models" biedt de fundamentele context voor de klasse van kwetsbaarheden die in dit artikel wordt verkend.
Kernconcepten
Fundamentele principes
De beveiligingsimplicaties van dit onderwerp vloeien voort uit fundamentele eigenschappen van de manier waarop moderne taalmodellen worden ontworpen, getraind en geïmplementeerd. Dit zijn geen geïsoleerde implementatiefouten, maar eerder systemische kenmerken die in meer of mindere mate alle transformer-gebaseerde taalmodellen treffen.
Inzicht in deze fundamentele eigenschap is de sleutel om te begrijpen waarom de technieken in dit artikel werken en waarom ze effectief blijven ondanks de voortdurende verbeteringen in de veiligheidstraining van modellen. Veiligheidstraining voegt een gedragslaag toe die het minder waarschijnlijk maakt dat modellen overduidelijk schadelijke instructies opvolgen, maar deze laag ligt boven op dezelfde architectuur en kan worden beïnvloed door dezelfde attentiemechanismen die legitieme invoer verwerken.
Technische verdieping
Het mechanisme achter deze klasse van kwetsbaarheden speelt zich af op het raakvlak tussen het vermogen om instructies op te volgen en het authenticeren van de bron. Tijdens de training leren modellen om instructies op te volgen die in specifieke formaten en contexten worden aangeboden. Een aanvaller die adversariële content kan aanbieden in een formaat dat overeenkomt met de aangeleerde patronen voor het opvolgen van instructies, kan het gedrag van het model met hoge betrouwbaarheid beïnvloeden.
from dataclasses import dataclass
from typing import Optional
import json
@dataclass
class SecurityAnalysis:
"""Framework voor het analyseren van de beveiligingseigenschappen van LLM-systemen."""
target: str
model: str
defenses: list
vulnerabilities: list
def assess_risk(self, attack_type: str) -> dict:
"""Beoordeel het risico voor een specifiek aanvalstype."""
# Controleer of een verdediging dit aanvalstype aanpakt
relevant_defenses = [
d for d in self.defenses
if attack_type in d.get("covers", [])
]
# Risicofactoren
likelihood = "high" if not relevant_defenses else "medium"
impact = self._assess_impact(attack_type)
return {
"attack_type": attack_type,
"likelihood": likelihood,
"impact": impact,
"defenses": len(relevant_defenses),
"risk_level": self._calculate_risk(likelihood, impact),
}
def _assess_impact(self, attack_type: str) -> str:
"""Beoordeel de potentiële impact van een aanvalstype."""
high_impact = ["data_exfiltration", "unauthorized_actions", "privilege_escalation"]
return "high" if attack_type in high_impact else "medium"
def _calculate_risk(self, likelihood: str, impact: str) -> str:
"""Bereken het totale risico op basis van waarschijnlijkheid en impact."""
risk_matrix = {
("high", "high"): "critical",
("high", "medium"): "high",
("medium", "high"): "high",
("medium", "medium"): "medium",
}
return risk_matrix.get((likelihood, impact), "medium")
def generate_report(self) -> str:
"""Genereer een rapport met de risicobeoordeling."""
attacks = ["prompt_injection", "data_exfiltration", "unauthorized_actions"]
assessments = [self.assess_risk(a) for a in attacks]
report = f"# Risk Assessment: {self.target}\n\n"
for assessment in assessments:
report += (
f"## {assessment['attack_type']}\n"
f"- Risk: {assessment['risk_level']}\n"
f"- Likelihood: {assessment['likelihood']}\n"
f"- Impact: {assessment['impact']}\n"
f"- Active defenses: {assessment['defenses']}\n\n"
)
return reportAnalyse van het aanvalsoppervlak
Inzicht in het aanvalsoppervlak is essentieel voor zowel offensief als defensief werk:
| Aanvalsvector | Toegangspunt | Typische impact | Verdedigingsaanpak |
|---|---|---|---|
| Directe injectie | Invoer via gebruikersbericht | Extractie van systeemprompt, omzeilen van veiligheid | Invoerclassificatie |
| Indirecte injectie | Externe databronnen (web, documenten, tools) | Data-exfiltratie, ongeautoriseerde acties | Datasanering |
| Misbruik van function calling | Injectie via toolparameters | Ongeautoriseerde API-aanroepen, datatoegang | Tool-sandboxing |
| Geheugenmanipulatie | Gespreksgeschiedenis, persistent geheugen | Persistentie over sessies heen, valse context | Geheugenvalidatie |
| Contextmanipulatie | Beheer van het contextvenster | Overschrijven van instructieprioriteit | Contextisolatie |
Toepassing in de praktijk
Implementatieaanpak
Om deze concepten in de praktijk toe te passen, is een systematische methodologie nodig:
class PracticalFramework:
"""Praktisch framework om de concepten uit dit artikel toe te passen."""
def __init__(self, target_config: dict):
self.config = target_config
self.findings = []
self.tested_vectors = set()
def test_vector(self, vector: str, payload: str) -> dict:
"""Test een specifieke aanvalsvector tegen het target."""
self.tested_vectors.add(vector)
# Verstuur de payload
response = self._send(payload)
# Evalueer het resultaat
finding = {
"vector": vector,
"payload_length": len(payload),
"response_length": len(response),
"success": self._evaluate(response),
"defense_triggered": self._detect_defense(response),
}
if finding["success"]:
self.findings.append(finding)
return finding
def coverage_report(self) -> dict:
"""Rapporteer over de testdekking."""
all_vectors = {
"direct_injection", "indirect_injection", "function_abuse",
"memory_manipulation", "context_manipulation",
}
return {
"tested": list(self.tested_vectors),
"untested": list(all_vectors - self.tested_vectors),
"coverage": f"{len(self.tested_vectors)/len(all_vectors)*100:.0f}%",
"findings": len(self.findings),
}
def _send(self, payload: str) -> str:
"""Verstuur de payload naar het target (implementatie verschilt per target)."""
pass
def _evaluate(self, response: str) -> bool:
"""Evalueer of de aanval geslaagd is."""
pass
def _detect_defense(self, response: str) -> Optional[str]:
"""Detecteer welk verdedigingsmechanisme is geactiveerd."""
passOverwegingen voor de verdediging
Inzicht in defensieve maatregelen is net zo belangrijk:
-
Invoervalidatie: De eerste verdedigingslinie. Zet invoerclassifiers in die binnenkomende prompts beoordelen op adversariële patronen voordat ze het model bereiken. Moderne classifiers combineren keyword-matching, regex-patronen en ML-gebaseerde detectie voor volledige dekking.
-
Uitvoerfiltering: Het vangnet. Verwerk alle modeluitvoer achteraf om datalekken van gevoelige informatie, fragmenten van de systeemprompt en andere beleidsovertredingen te detecteren en te verwijderen. Uitvoerfilters moeten onafhankelijk zijn van invoerfilters om defense-in-depth te bieden.
-
Gedragsmonitoring: De detectielaag. Monitor interactiepatronen van het model op afwijkingen die wijzen op lopende aanvallen — ongebruikelijke verzoekpatronen, herhaalde weigeringen of antwoordkenmerken die afwijken van het basisgedrag.
-
Architectuurontwerp: De basis. Ontwerp applicatiearchitecturen die zo min mogelijk vertrouwen in modeluitvoer leggen, least privilege afdwingen voor toolgebruik en duidelijke beveiligingsgrenzen tussen componenten handhaven.
Relevantie in de praktijk
Deze concepten zijn direct toepasbaar op AI-systemen in productie, sectoroverschrijdend. De volgende factoren maken dit onderwerp bijzonder relevant:
- Alomtegenwoordigheid: De klasse van kwetsbaarheden treft alle grote modelproviders en deployment-configuraties
- Impact: Geslaagd misbruik kan leiden tot blootstelling van data, ongeautoriseerde acties en compliance-overtredingen
- Persistentie: De onderliggende architectonische eigenschappen zorgen ervoor dat deze technieken relevant blijven naarmate modellen evolueren
- Regelgeving: Opkomende regelgeving (EU AI Act, NIST AI RMF) vereist steeds vaker dat organisaties deze risico's beoordelen en mitigeren
Lopend onderzoek
Het actieve onderzoek op dit gebied omvat:
- Formele robuustheidsgaranties: Het ontwikkelen van wiskundige frameworks om modelgedrag te bewijzen onder begrensde adversariële verstoring
- Adversariële training op schaal: Trainingsprocedures die modellen tijdens de veiligheidstraining blootstellen aan adversariële invoer om de robuustheid te verbeteren
- Verdediging op basis van interpreteerbaarheid: Mechanistische interpreteerbaarheid gebruiken om te begrijpen waarom aanvallen slagen op neuronniveau, wat gerichte verdedigingen mogelijk maakt
- Gestandaardiseerde evaluatie: Benchmarks zoals HarmBench en JailbreakBench die systematische meting van de effectiviteit van aanvallen en verdedigingen mogelijk maken
Implementatieoverwegingen
Architectuurpatronen
Wanneer je systemen bouwt die met LLM's communiceren, beïnvloeden verschillende architectuurpatronen de beveiligingshouding van de applicatie als geheel:
Gateway-patroon: Een speciale API-gateway zit tussen gebruikers en het LLM en regelt authenticatie, rate limiting, invoervalidatie en uitvoerfiltering. Dit centraliseert de beveiligingscontroles, maar creëert wel een single point of failure.
from dataclasses import dataclass
from typing import Optional
import time
@dataclass
class SecurityGateway:
"""Gateway-patroon voor het beveiligen van toegang tot een LLM-applicatie."""
input_classifier: object # ML-gebaseerde invoerclassifier
output_filter: object # Contentfilter voor uitvoer
rate_limiter: object # Rate limiting-service
audit_logger: object # Logger voor het audittrail
def process_request(self, user_id: str, message: str, session_id: str) -> dict:
"""Verwerk een verzoek door alle beveiligingslagen heen."""
request_id = self._generate_request_id()
# Laag 1: rate limiting
if not self.rate_limiter.allow(user_id):
self.audit_logger.log(request_id, "rate_limited", user_id)
return {"error": "Rate limit exceeded", "retry_after": 60}
# Laag 2: invoerclassificatie
classification = self.input_classifier.classify(message)
if classification.is_adversarial:
self.audit_logger.log(
request_id, "input_blocked",
user_id, classification.category
)
return {"error": "Request could not be processed"}
# Laag 3: LLM-verwerking
response = self._call_llm(message, session_id)
# Laag 4: uitvoerfiltering
filtered = self.output_filter.filter(response)
if filtered.was_modified:
self.audit_logger.log(
request_id, "output_filtered",
user_id, filtered.reason
)
# Laag 5: auditlogging
self.audit_logger.log(
request_id, "completed",
user_id, len(message), len(filtered.content)
)
return {"response": filtered.content}
def _generate_request_id(self) -> str:
import uuid
return str(uuid.uuid4())
def _call_llm(self, message: str, session_id: str) -> str:
# Implementatie van de LLM API-aanroep
passSidecar-patroon: Beveiligingscomponenten draaien naast het LLM als onafhankelijke services, elk verantwoordelijk voor een specifiek beveiligingsaspect. Dit zorgt voor betere isolatie en onafhankelijke schaalbaarheid, maar verhoogt wel de complexiteit van het systeem.
Mesh-patroon: Bij multi-agentsystemen heeft elke agent een eigen beveiligingsperimeter met authenticatie, autorisatie en auditing. Communicatie tussen agents volgt zero-trust-principes.
Gevolgen voor de performance
Beveiligingsmaatregelen voegen onvermijdelijk latency en rekenkosten toe. Inzicht in deze afwegingen is essentieel voor productie-implementaties:
| Beveiligingslaag | Typische latency | Rekenkosten | Impact op UX |
|---|---|---|---|
| Keyword-filter | <1ms | Verwaarloosbaar | Geen |
| Regex-filter | 1-5ms | Laag | Geen |
| ML-classifier (klein) | 10-50ms | Matig | Minimaal |
| ML-classifier (groot) | 50-200ms | Hoog | Merkbaar |
| LLM-as-judge | 500-2000ms | Zeer hoog | Aanzienlijk |
| Volledige pipeline | 100-500ms | Hoog | Matig |
De aanbevolen aanpak is om eerst snelle, lichtgewicht checks te gebruiken (keyword- en regex-filters) om voor de hand liggende aanvallen te onderscheppen, gevolgd door duurdere ML-gebaseerde analyse, alleen voor invoer die de eerste filters passeert. Deze trapsgewijze aanpak biedt goede beveiliging met acceptabele performance.
Monitoring en observability
Effectieve beveiligingsmonitoring voor LLM-applicaties vereist het bijhouden van metrics die adversariële gedragspatronen vastleggen:
from dataclasses import dataclass
from collections import defaultdict
import time
@dataclass
class SecurityMetrics:
"""Houd beveiligingsrelevante metrics bij voor LLM-applicaties."""
# Tellers
total_requests: int = 0
blocked_requests: int = 0
filtered_outputs: int = 0
anomalous_sessions: int = 0
# Tijdregistratie
_request_times: list = None
_block_times: list = None
def __post_init__(self):
self._request_times = []
self._block_times = []
def record_request(self, was_blocked: bool = False, was_filtered: bool = False):
"""Registreer een verzoek en de afhandeling ervan."""
now = time.time()
self.total_requests += 1
self._request_times.append(now)
if was_blocked:
self.blocked_requests += 1
self._block_times.append(now)
if was_filtered:
self.filtered_outputs += 1
def get_block_rate(self, window_seconds: int = 300) -> float:
"""Bereken het blokkeerpercentage over een tijdvenster."""
now = time.time()
cutoff = now - window_seconds
recent_requests = sum(1 for t in self._request_times if t > cutoff)
recent_blocks = sum(1 for t in self._block_times if t > cutoff)
if recent_requests == 0:
return 0.0
return recent_blocks / recent_requests
def should_alert(self) -> bool:
"""Bepaal of de huidige metrics een melding rechtvaardigen."""
block_rate = self.get_block_rate()
# Alarmeer als het blokkeerpercentage de drempel overschrijdt
if block_rate > 0.3: # >30% van de verzoeken geblokkeerd in de laatste 5 min
return True
return FalseBeveiligingstests in CI/CD
Door AI-beveiligingstests in de ontwikkelpipeline te integreren, vang je regressies op voordat ze in productie terechtkomen:
- Tests op unitniveau: Test individuele beveiligingscomponenten (classifiers, filters) tegen bekende payloads
- Integratietests: Test de volledige beveiligingspipeline end-to-end
- Regressietests: Onderhoud een suite met eerder ontdekte aanvalspayloads en controleer of ze geblokkeerd blijven
- Adversariële tests: Draai periodiek geautomatiseerde red team-tools (Garak, Promptfoo) als onderdeel van de deploymentpipeline
Opkomende trends
Huidige onderzoeksrichtingen
Het vakgebied van LLM-beveiliging evolueert razendsnel. Belangrijke onderzoeksrichtingen die het landschap waarschijnlijk gaan vormgeven, zijn onder meer:
-
Formele verificatie van LLM-gedrag: Onderzoekers verkennen wiskundige frameworks om eigenschappen van modelgedrag onder adversariële omstandigheden te bewijzen. Hoewel volledige formele verificatie van neurale netwerken onhaalbaar blijft, biedt begrensde verificatie van specifieke eigenschappen perspectief.
-
Adversariële training voor robuustheid van LLM's: Naast standaard-RLHF ontwikkelen onderzoekers trainingsprocedures die modellen tijdens de veiligheidstraining expliciet blootstellen aan adversariële invoer, wat de robuustheid tegen bekende aanvalspatronen verbetert.
-
Verdediging op basis van interpreteerbaarheid: Onderzoek naar mechanistische interpreteerbaarheid stelt verdedigers in staat te begrijpen waarom specifieke aanvallen slagen op het niveau van neuronen en circuits, wat gerichtere defensieve maatregelen mogelijk maakt.
-
Beveiliging van multi-agentsystemen: Naarmate LLM-agents gangbaarder worden, is het beveiligen van communicatie tussen agents en het bewaken van vertrouwensgrenzen binnen agentsystemen een actief onderzoeksgebied met aanzienlijke praktische implicaties.
-
Geautomatiseerde AI-redteaming op schaal: Tools zoals Garak van NVIDIA, PyRIT van Microsoft en het Inspect-framework van de UK AISI maken geautomatiseerde beveiligingstests mogelijk op een schaal die voorheen onhaalbaar was, maar de kwaliteit en dekking van geautomatiseerd testen blijft een open uitdaging.
De integratie van deze onderzoeksrichtingen in productiesystemen zal de volgende generatie AI-beveiligingspraktijken bepalen.
Geavanceerde overwegingen
Het evoluerende aanvalslandschap
Het AI-beveiligingslandschap evolueert razendsnel, naarmate zowel offensieve technieken als defensieve maatregelen zich ontwikkelen. Een aantal trends bepaalt de huidige stand van zaken:
Toenemende modelcapaciteiten creëren nieuwe aanvalsoppervlakken. Naarmate modellen toegang krijgen tot tools, code-uitvoering, webbrowsen en computergebruik, introduceert elke nieuwe capaciteit potentiële misbruikvectoren die in eerdere, tekst-only systemen niet bestonden. Het principe van least privilege wordt steeds belangrijker naarmate de capaciteiten van modellen toenemen.
Verbeteringen in veiligheidstraining zijn nodig, maar niet voldoende. Modelproviders investeren zwaar in veiligheidstraining via RLHF, DPO, constitutional AI en andere alignment-technieken. Deze verbeteringen leggen de lat voor geslaagde aanvallen hoger, maar elimineren de fundamentele kwetsbaarheid niet: modellen kunnen legitieme instructies niet betrouwbaar onderscheiden van adversariële, omdat dit onderscheid niet in de architectuur is vastgelegd.
Geautomatiseerde red team-tools democratiseren het testen. Tools zoals Garak van NVIDIA, PyRIT van Microsoft en Promptfoo stellen organisaties in staat geautomatiseerde beveiligingstests uit te voeren zonder diepgaande expertise in AI-beveiliging. Geautomatiseerde tools onderscheppen echter bekende patronen; nieuwe aanvallen en kwetsbaarheden in de bedrijfslogica vereisen nog altijd menselijke creativiteit en domeinkennis.
Druk vanuit regelgeving stuwt investeringen in organisaties. De EU AI Act, NIST AI RMF en sectorspecifieke regelgeving vereisen steeds vaker dat organisaties AI-specifieke risico's beoordelen en mitigeren. Deze druk vanuit regelgeving stuwt investeringen in AI-beveiligingsprogramma's, maar veel organisaties bevinden zich nog in de beginfase van het opbouwen van volwassen AI-beveiligingspraktijken.
Overkoepelende beveiligingsprincipes
Een aantal beveiligingsprincipes geldt voor alle onderwerpen die in dit curriculum aan bod komen:
-
Defense-in-depth: Geen enkele defensieve maatregel is op zichzelf voldoende. Stapel meerdere onafhankelijke verdedigingen zodat het falen van één enkele laag niet leidt tot compromittering van het systeem. Invoerclassificatie, uitvoerfiltering, gedragsmonitoring en architectonische controles moeten allemaal aanwezig zijn.
-
Ga uit van een inbraak: Ontwerp systemen vanuit de aanname dat elk afzonderlijk component gecompromitteerd kan raken. Deze mindset leidt tot betere isolatie, monitoring en incidentresponscapaciteiten. Wanneer een prompt injection slaagt, moet de blast radius worden geminimaliseerd via architectonische controles.
-
Least privilege: Geef modellen en agents alleen de minimale capaciteiten die nodig zijn voor hun beoogde functie. Een chatbot voor klantenservice heeft geen toegang nodig tot het bestandssysteem of code-uitvoering. Overmatige capaciteiten vergroten de impact van geslaagd misbruik.
-
Continu testen: AI-beveiliging is geen eenmalige beoordeling. Modellen veranderen, verdedigingen evolueren en er worden regelmatig nieuwe aanvalstechnieken ontdekt. Implementeer continu beveiligingstesten als onderdeel van de ontwikkel- en deploymentlevenscyclus.
-
Secure by default: Standaardconfiguraties moeten veilig zijn. Vereis expliciete opt-in voor riskante capaciteiten, gebruik allowlists in plaats van denylists en kies eerder voor restrictie dan voor permissiviteit.
Integratie met de beveiliging van de organisatie
AI-beveiliging staat niet op zichzelf — het moet worden geïntegreerd in het bredere beveiligingsprogramma van de organisatie:
| Beveiligingsdomein | AI-specifieke integratie |
|---|---|
| Identity en Access | Beheer van API-sleutels, toegangscontroles voor modellen, gebruikersauthenticatie voor AI-functies |
| Databescherming | Classificatie van trainingsdata, PII in prompts, dataresidentie voor modelaanroepen |
| Applicatiebeveiliging | Dreigingsmodellering van AI-functies, prompt injection in SAST/DAST, veilige AI-ontwerppatronen |
| Incidentrespons | AI-specifieke playbooks, monitoring van modelgedrag, forensisch onderzoek naar prompt injection |
| Compliance | Mapping van AI-regelgeving (EU AI Act, NIST), AI-audittrails, modeldocumentatie |
| Supply chain | Herkomst van modellen, beveiliging van dependencies, integriteitsverificatie van adapters/gewichten |
class OrganizationalIntegration:
"""Framework voor het integreren van AI-beveiliging in beveiligingsprogramma's van de organisatie."""
def __init__(self, org_config: dict):
self.config = org_config
self.gaps = []
def assess_maturity(self) -> dict:
"""Beoordeel de volwassenheid van de AI-beveiliging van de organisatie."""
domains = {
"governance": self._check_governance(),
"technical_controls": self._check_technical(),
"monitoring": self._check_monitoring(),
"incident_response": self._check_ir(),
"training": self._check_training(),
}
overall = sum(d["score"] for d in domains.values()) / len(domains)
return {"domains": domains, "overall_maturity": round(overall, 1)}
def _check_governance(self) -> dict:
has_policy = self.config.get("ai_security_policy", False)
has_framework = self.config.get("risk_framework", False)
score = (int(has_policy) + int(has_framework)) * 2.5
return {"score": score, "max": 5.0}
def _check_technical(self) -> dict:
controls = ["input_classification", "output_filtering", "rate_limiting", "sandboxing"]
active = sum(1 for c in controls if self.config.get(c, False))
return {"score": active * 1.25, "max": 5.0}
def _check_monitoring(self) -> dict:
has_monitoring = self.config.get("ai_monitoring", False)
has_alerting = self.config.get("ai_alerting", False)
score = (int(has_monitoring) + int(has_alerting)) * 2.5
return {"score": score, "max": 5.0}
def _check_ir(self) -> dict:
has_playbook = self.config.get("ai_ir_playbook", False)
return {"score": 5.0 if has_playbook else 0.0, "max": 5.0}
def _check_training(self) -> dict:
has_training = self.config.get("ai_security_training", False)
return {"score": 5.0 if has_training else 0.0, "max": 5.0}Toekomstige richtingen
Een aantal onderzoeks- en industrietrends zal de evolutie van dit vakgebied vormgeven:
- Formele methoden voor AI-veiligheid: De ontwikkeling van wiskundige frameworks die begrensde garanties kunnen bieden over modelgedrag onder adversariële omstandigheden
- Geautomatiseerde AI-redteaming op schaal: Voortdurende verbetering van geautomatiseerde testtools die nieuwe kwetsbaarheden kunnen ontdekken zonder menselijke sturing
- AI-ondersteunde verdediging: AI-systemen gebruiken om aanvallen op andere AI-systemen te detecteren en erop te reageren, wat een dynamisch ecosysteem van aanval en verdediging creëert
- Gestandaardiseerde evaluatie: Groeiende adoptie van gestandaardiseerde benchmarks (HarmBench, JailbreakBench) die consistente meting van vooruitgang mogelijk maken
- Harmonisatie van regelgeving: Convergentie van AI-regelgevingsframeworks over jurisdicties heen, wat duidelijkere eisen biedt voor organisaties
Bronnen en verder lezen
- OWASP LLM Top 10 2025 — Uitgebreide gids over LLM-beveiligingsrisico's (owasp.org/www-project-top-10-for-large-language-model-applications)
- MITRE ATLAS — Adversarial Threat Landscape for AI Systems (atlas.mitre.org)
- Zou et al. 2023 — "Universal and Transferable Adversarial Attacks on Aligned Language Models"
- Chao et al. 2023 — "Jailbreaking Black-Box LLMs in Twenty Queries" (PAIR)
- Garak (NVIDIA) — LLM-kwetsbaarheidsscanner (github.com/NVIDIA/garak)
Wat is de meest effectieve defensieve strategie tegen de aanvalsklasse die in dit artikel wordt beschreven?
Waarom blijven de technieken die in dit artikel worden beschreven effectief, ondanks de voortdurende beveiligingsverbeteringen door modelproviders?