AI-beveiligingsrisico's in de landbouw
Beveiligingsrisico's voor AI in de landbouw, waaronder gewasanalyse, supply chain en autonome apparatuur.
Overzicht
Beveiligingsrisico's voor AI in de landbouw, waaronder gewasanalyse, supply chain en autonome apparatuur.
Dit onderwerp vertegenwoordigt een cruciaal gebied binnen AI-beveiliging dat het onderwerp is geweest van aanzienlijk onderzoek en misbruik in de praktijk. Het begrijpen van de concepten, technieken en verdedigingsmaatregelen die hier worden behandeld, is essentieel voor iedereen die in AI-beveiliging werkt, of dat nu in offensieve of defensieve rollen is.
Zou et al. 2023 — "Universal and Transferable Adversarial Attacks on Aligned Language Models" biedt fundamentele context voor de klasse van kwetsbaarheden die in dit artikel wordt verkend.
Kernconcepten
Fundamentele principes
De beveiligingsimplicaties van dit onderwerp komen voort uit fundamentele eigenschappen van hoe moderne taalmodellen worden ontworpen, getraind en uitgerold. Dit zijn geen geïsoleerde implementatiefouten, maar systemische kenmerken die in verschillende mate alle transformer-gebaseerde taalmodellen treffen.
Het begrijpen van deze fundamentele eigenschap is de sleutel tot het begrijpen waarom de technieken die in dit artikel worden beschreven werken en waarom ze effectief blijven ondanks voortdurende verbeteringen in de veiligheidstraining van modellen. Veiligheidstraining voegt een gedragslaag toe die het minder waarschijnlijk maakt dat modellen overduidelijk schadelijke instructies volgen, maar deze laag werkt bovenop dezelfde architectuur en kan worden beïnvloed door dezelfde attention-mechanismen die legitieme invoer verwerken.
Technische verdieping
Het mechanisme dat ten grondslag ligt aan deze klasse van kwetsbaarheden werkt op het snijvlak van de instructievolgende capaciteit en bronauthenticatie. Tijdens de training leren modellen instructies te volgen die in specifieke formaten en contexten worden gepresenteerd. Een aanvaller die adversariële inhoud kan presenteren in een formaat dat overeenkomt met de aangeleerde instructievolgende patronen van het model, kan het modelgedrag met hoge betrouwbaarheid beïnvloeden.
from dataclasses import dataclass
from typing import Optional
import json
@dataclass
class SecurityAnalysis:
"""Framework voor het analyseren van 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 algehele 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 risicobeoordelingsrapport."""
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
Het begrijpen van het aanvalsoppervlak is essentieel voor zowel offensief als defensief werk:
| Aanvalsvector | Toegangspunt | Typische impact | Verdedigingsaanpak |
|---|---|---|---|
| Directe injectie | Invoer van 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 van toolparameters | Ongeautoriseerde API-aanroepen, datatoegang | Tool-sandboxing |
| Geheugenmanipulatie | Gespreksgeschiedenis, persistent geheugen | Persistentie over sessies heen, valse context | Geheugenvalidatie |
| Contextmanipulatie | Beheer van het contextvenster | Override van instructieprioriteit | Contextisolatie |
Praktische toepassing
Implementatieaanpak
Het in de praktijk toepassen van deze concepten vereist een systematische methodologie:
class PracticalFramework:
"""Praktisch framework voor het toepassen van de concepten in dit artikel."""
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 doelsysteem."""
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 doelsysteem (implementatie verschilt per doelsysteem)."""
pass
def _evaluate(self, response: str) -> bool:
"""Evalueer of de aanval succesvol was."""
pass
def _detect_defense(self, response: str) -> Optional[str]:
"""Detecteer welk verdedigingsmechanisme werd geactiveerd."""
passVerdedigingsoverwegingen
Het begrijpen van verdedigingsmaatregelen is even belangrijk:
-
Invoervalidatie: De eerste verdedigingslinie. Zet invoerclassificatie in die inkomende prompts beoordeelt op adversariële patronen voordat ze het model bereiken. Moderne classifiers combineren keyword-matching, regex-patronen en ML-gebaseerde detectie voor uitgebreide dekking.
-
Uitvoerfiltering: Het vangnet. Bewerk alle modeluitvoer na om het lekken van gevoelige data, fragmenten van de systeemprompt en andere beleidsschendingen te detecteren en te verwijderen. Uitvoerfilters moeten onafhankelijk zijn van invoerfilters om defense-in-depth te bieden.
-
Gedragsmonitoring: De detectielaag. Monitor patronen van modelinteractie op anomalieën die wijzen op lopende aanvallen — ongebruikelijke verzoekpatronen, herhaalde weigeringen of reactiekenmerken die afwijken van het basisgedrag.
-
Architectuurontwerp: Het fundament. Ontwerp applicatiearchitecturen die het vertrouwen in modeluitvoer minimaliseren, minimale privileges voor toolgebruik afdwingen en duidelijke beveiligingsgrenzen tussen componenten handhaven.
Relevantie in de praktijk
Deze concepten zijn direct toepasbaar op AI-systemen in productie binnen allerlei sectoren. De volgende factoren maken dit onderwerp bijzonder relevant:
- Alomtegenwoordigheid: De klasse van kwetsbaarheden treft alle grote modelaanbieders en deploymentconfiguraties
- Impact: Succesvol misbruik kan leiden tot datablootstelling, ongeautoriseerde acties en nalevingsschendingen
- Persistentie: De onderliggende architecturale eigenschappen zorgen ervoor dat deze technieken relevant blijven naarmate modellen evolueren
- Regelgeving: Opkomende regelgeving (EU AI Act, NIST AI RMF) vereist in toenemende mate dat organisaties deze risico's beoordelen en mitigeren
Huidig onderzoek
Actief onderzoek op dit gebied omvat:
- Formele robuustheidsgaranties: Het ontwikkelen van wiskundige frameworks om modelgedrag onder begrensde adversariële verstoring te bewijzen
- Adversariële training op schaal: Trainingsprocedures die modellen tijdens veiligheidstraining blootstellen aan adversariële invoer om de robuustheid te verbeteren
- Interpretatie-gestuurde verdediging: Het gebruik van mechanistische interpreteerbaarheid 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
Bij het implementeren van systemen die met LLM's interacteren, beïnvloeden verschillende architectuurpatronen de beveiligingshouding van de hele applicatie:
Gateway-patroon: Een speciale API-gateway zit tussen gebruikers en het LLM en verzorgt authenticatie, rate limiting, invoervalidatie en uitvoerfiltering. Dit centraliseert beveiligingscontroles maar creëert 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 LLM-applicaties."""
input_classifier: object # ML-gebaseerde invoerclassificatie
output_filter: object # Uitvoer-contentfilter
rate_limiter: object # Rate-limiting-service
audit_logger: object # Audit-trail-logger
def process_request(self, user_id: str, message: str, session_id: str) -> dict:
"""Verwerk een verzoek door alle beveiligingslagen."""
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: Audit logging
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 biedt betere isolatie en onafhankelijke schaalbaarheid, maar verhoogt de complexiteit van het systeem.
Mesh-patroon: Voor multi-agentsystemen heeft elke agent zijn eigen beveiligingsperimeter met authenticatie, autorisatie en auditing. Communicatie tussen agents volgt zero-trust-principes.
Prestatie-implicaties
Beveiligingsmaatregelen voegen onvermijdelijk latentie en rekenkundige overhead toe. Het begrijpen van deze afwegingen is essentieel voor productie-implementaties:
| Beveiligingslaag | Typische latentie | Rekenkosten | Impact op UX |
|---|---|---|---|
| Keyword-filter | <1ms | Verwaarloosbaar | Geen |
| Regex-filter | 1-5ms | Laag | Geen |
| ML-classificatie (klein) | 10-50ms | Gemiddeld | Minimaal |
| ML-classificatie (groot) | 50-200ms | Hoog | Merkbaar |
| LLM-as-judge | 500-2000ms | Zeer hoog | Aanzienlijk |
| Volledige pipeline | 100-500ms | Hoog | Gemiddeld |
De aanbevolen aanpak is om eerst snelle, lichtgewicht controles te gebruiken (keyword- en regex-filters) om voor de hand liggende aanvallen op te vangen, gevolgd door duurdere ML-gebaseerde analyse alleen voor invoer die de eerste filters passeert. Deze trapsgewijze aanpak biedt goede beveiliging met acceptabele prestaties.
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
# Snelheidstracking
_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 blokkadepercentage 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 waarschuwing rechtvaardigen."""
block_rate = self.get_block_rate()
# Waarschuw als het blokkadepercentage de drempel overschrijdt
if block_rate > 0.3: # >30% van de verzoeken geblokkeerd in de laatste 5 min
return True
return FalseBeveiligingstesten in CI/CD
Het integreren van AI-beveiligingstesten in de ontwikkelpijplijn vangt regressies op voordat ze in productie komen:
- Tests op unitniveau: Test afzonderlijke beveiligingscomponenten (classifiers, filters) tegen bekende payloads
- Integratietests: Test de volledige beveiligingspijplijn end-to-end
- Regressietests: Onderhoud een suite van eerder ontdekte attack-payloads en controleer of ze geblokkeerd blijven
- Adversariële tests: Voer periodiek geautomatiseerde red-team-tools (Garak, Promptfoo) uit als onderdeel van de deploymentpijplijn
Opkomende trends
Huidige onderzoeksrichtingen
Het vakgebied van LLM-beveiliging evolueert snel. Belangrijke onderzoeksrichtingen die het landschap waarschijnlijk gaan vormgeven, zijn onder andere:
-
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, is begrensde verificatie van specifieke eigenschappen veelbelovend.
-
Adversariële training voor LLM-robuustheid: Naast standaard-RLHF ontwikkelen onderzoekers trainingsprocedures die modellen tijdens veiligheidstraining expliciet blootstellen aan adversariële invoer, wat de robuustheid tegen bekende aanvalspatronen verbetert.
-
Interpretatie-gestuurde verdediging: Onderzoek naar mechanistische interpreteerbaarheid stelt verdedigers in staat te begrijpen waarom specifieke aanvallen slagen op het niveau van neuronen en circuits, wat gerichtere verdedigingsmaatregelen mogelijk maakt.
-
Multi-agent-beveiliging: Naarmate LLM-agents vaker voorkomen, is het beveiligen van communicatie tussen agents en het handhaven van vertrouwensgrenzen over agentsystemen heen een actief onderzoeksgebied met aanzienlijke praktische implicaties.
-
Geautomatiseerd red teaming op schaal: Tools zoals Garak van NVIDIA, PyRIT van Microsoft en het Inspect-framework van de UK AISI maken geautomatiseerd beveiligingstesten mogelijk op schalen die voorheen onmogelijk waren, 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 landschap van AI-beveiliging evolueert snel naarmate zowel offensieve technieken als verdedigingsmaatregelen vorderen. Verschillende trends bepalen 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 niet bestonden in eerdere, alleen-tekst-systemen. Het principe van minimale privileges wordt steeds belangrijker naarmate de modelcapaciteiten toenemen.
Verbeteringen in veiligheidstraining zijn noodzakelijk maar niet voldoende. Modelaanbieders investeren fors in veiligheidstraining via RLHF, DPO, constitutional AI en andere alignment-technieken. Deze verbeteringen leggen de lat hoger voor succesvolle aanvallen, maar elimineren niet de fundamentele kwetsbaarheid: modellen kunnen legitieme instructies niet betrouwbaar onderscheiden van adversariële, omdat dit onderscheid niet is gerepresenteerd in de architectuur.
Geautomatiseerde red-team-tools democratiseren het testen. Tools zoals Garak van NVIDIA, PyRIT van Microsoft en Promptfoo stellen organisaties in staat geautomatiseerd beveiligingstesten uit te voeren zonder diepgaande AI-beveiligingsexpertise. Geautomatiseerde tools vangen echter bekende patronen op; nieuwe aanvallen en kwetsbaarheden in de bedrijfslogica vereisen nog steeds menselijke creativiteit en domeinkennis.
Druk vanuit regelgeving stuurt investeringen door organisaties aan. De EU AI Act, NIST AI RMF en sectorspecifieke regelgeving vereisen in toenemende mate dat organisaties AI-specifieke risico's beoordelen en mitigeren. Deze regelgevingsdruk stuurt investeringen in AI-beveiligingsprogramma's aan, maar veel organisaties bevinden zich nog in de vroege stadia van het opbouwen van volwassen AI-beveiligingspraktijken.
Overkoepelende beveiligingsprincipes
Verschillende beveiligingsprincipes zijn van toepassing op alle onderwerpen die in dit curriculum worden behandeld:
-
Defense-in-depth: Geen enkele afzonderlijke verdedigingsmaatregel is voldoende. Stapel meerdere onafhankelijke verdedigingen zodat het falen van één laag niet leidt tot compromittering van het systeem. Invoerclassificatie, uitvoerfiltering, gedragsmonitoring en architecturale controles moeten allemaal aanwezig zijn.
-
Ga uit van een inbraak: Ontwerp systemen ervan uitgaande dat elk afzonderlijk component gecompromitteerd kan worden. Deze mindset leidt tot betere isolatie-, monitoring- en incident-responsmogelijkheden. Wanneer een prompt-injectie slaagt, zou de blast radius via architecturale controles geminimaliseerd moeten worden.
-
Minimale privileges: Geef modellen en agents alleen de minimale capaciteiten die nodig zijn voor hun beoogde functie. Een klantenservice-chatbot heeft geen toegang tot het bestandssysteem of code-uitvoering nodig. Excessieve capaciteiten vergroten de impact van succesvol misbruik.
-
Continu testen: AI-beveiliging is geen eenmalige beoordeling. Modellen veranderen, verdedigingen evolueren en nieuwe aanvalstechnieken worden regelmatig ontdekt. Implementeer continu beveiligingstesten als onderdeel van de ontwikkel- en deploymentlevenscyclus.
-
Veilig vanaf de basis: Standaardconfiguraties zouden veilig moeten zijn. Vereis expliciete opt-in voor risicovolle capaciteiten, gebruik allowlists in plaats van denylists en kies bij twijfel voor restrictie in plaats van toegeeflijkheid.
Integratie met organisatorische beveiliging
AI-beveiliging bestaat niet op zichzelf — ze moet integreren met het bredere beveiligingsprogramma van de organisatie:
| Beveiligingsdomein | AI-specifieke integratie |
|---|---|
| Identiteit en toegang | 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-injectie in SAST/DAST, veilige AI-ontwerppatronen |
| Incident response | AI-specifieke playbooks, monitoring van modelgedrag, prompt-injectie-forensics |
| Naleving | Mapping van AI-regelgeving (EU AI Act, NIST), AI-audit-trails, modeldocumentatie |
| Supply chain | Modelherkomst, beveiliging van afhankelijkheden, integriteitsverificatie van adapters/gewichten |
class OrganizationalIntegration:
"""Framework voor het integreren van AI-beveiliging met organisatorische beveiligingsprogramma's."""
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
Verschillende onderzoeks- en industrietrends zullen de evolutie van dit vakgebied bepalen:
- Formele methoden voor AI-veiligheid: Het ontwikkelen van wiskundige frameworks die begrensde garanties kunnen bieden over modelgedrag onder adversariële omstandigheden
- Geautomatiseerd red teaming op schaal: Voortdurende verbetering van geautomatiseerde testtools die nieuwe kwetsbaarheden kunnen ontdekken zonder menselijke begeleiding
- AI-ondersteunde verdediging: Het gebruik van AI-systemen om aanvallen op andere AI-systemen te detecteren en erop te reageren, wat een dynamisch aanval-verdediging-ecosysteem creëert
- Gestandaardiseerde evaluatie: Toenemende toepassing van gestandaardiseerde benchmarks (HarmBench, JailbreakBench) die consistente meting van vooruitgang mogelijk maken
- Harmonisatie van regelgeving: Convergentie van AI-regelgevingskaders tussen jurisdicties, wat duidelijkere vereisten voor organisaties biedt
Referenties en verder lezen
- OWASP LLM Top 10 2025 — Comprehensive guide to LLM security risks (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 vulnerability scanner (github.com/NVIDIA/garak)
Wat is de meest effectieve verdedigingsstrategie tegen de aanvalsklasse die in dit artikel wordt beschreven?
Waarom blijven de technieken die in dit artikel worden beschreven effectief ondanks voortdurende beveiligingsverbeteringen door modelaanbieders?