Agent red teaming en OWASP LLM01

Waarom agenten de injectiemathematica veranderen

Van output naar actie

In een pure chatbot is het doel van een injectie om de model te laten zeggen wat het niet zou moeten zeggen. De impact stopt bij de tekst die de model verlaat. Wanneer hetzelfde model een tool kan aanroepen, kan de geïnjecteerde tekst een opdracht worden die de tool uitvoert. Een aanvaller die een file-read-tool kan sturen om een vertrouwelijk document op te halen, of een mail-send-tool om dat document door te sturen, heeft een woordkeuze-truc omgezet in een datalek. De ernst hangt dus af van wat de tool kan doen, niet van hoe slim de reactie is.

Tool-reikwijdte definieert blast radius

De blast radius is de unie van alle resources die de tools van de agent kunnen aanraken. Als de agent alleen een read-only API naar een openbare blog heeft, is het ergste geval het lekken van openbare informatie. Als de agent een database-schrijftool, een file-systeem-deletetool of een externe betalingsgateway kan aanroepen, kan dezelfde injectie records wissen, saldi wijzigen of geld overmaken. Red-team-werk moet elke tool in kaart brengen naar de data-opslag, services of hardware die het kan beïnvloeden, en vervolgens testen of een injectie die assets kan bereiken.

Gangbare misverstanden

- Aannemen dat de outputlengte van de model de schade beperkt – vals, omdat een korte string een destructieve tool-aanroep kan triggeren. - Geloven dat het filteren van de gebruikersbericht genoeg is – vals, omdat injecties binnen tool-resultaten of systeemprompts kunnen komen. - Denken dat een laag-parametermodel veilig is – vals, wanneer dat model is gekoppeld aan een krachtige toolset.

Voor een snel overzicht van defensieve codering, zie de OWASP-kaart voor LLM Prompt Injectie Preventie.

Oppervlakken om verder te onderzoeken dan de chatbox

Systeemprompt en configuratie

De systeemprompt bevat vaak API-sleutels, service-URL's of interne beleidstaal. Een aanvaller die in dit gebied kan injecteren, kan directe referenties of leren waar hij verder moet zoeken. Bekijk de prompt op statische geheimen en test of ze kunnen worden weergegeven of geëxtraheerd via een tool-aanroep.

Tool-schemas en argumentvalidatie

Elke blootgestelde tool definieert een JSON-schema voor zijn invoer. Als het schema vrije-tekst-strings zonder strikte validatie accepteert, kan een aanvaller opdrachten in die strings embedden. Bijvoorbeeld, een "run_sql"-tool die een raw query-string accepteert, is kwetsbaar voor SQL-injectie, tenzij de agent-laag de invoer sanitize of parameteriseert. Controleer of de agent type-limieten, lengte-limieten of allow-lijsten voor elk argument afdwingt.

Retrieval-augmented generatie (RAG)-pijplijnen

Wanneer de agent gegevens ophaalt uit externe bronnen – webpagina's, e-mails, ticketsystemen – worden die gegevens onderdeel van de context van de model. Een aanvaller die een van die bronnen controleert, kan instructies plaatsen die de model later als vertrouwd zal behandelen. Onderzoek door een bekende externe feed te vergiftigen en te kijken of de agent op de verborgen opdracht reageert.

Instructie-propagatie binnen tool-resultaten

Sommige ontwerpen retourneren tool-output rechtstreeks naar de volgende model-aanroep zonder opnieuw te saniteren. Als een tool een stuk tekst retourneert dat een nieuwe opdracht bevat, kan de model die opdracht in de volgende stap gehoorzamen. Dit creëert een tweefasen-injectie waarbij de eerste fase onschuldig lijkende gegevens is en de tweede fase de kwaadaardige opdracht is. Test elke tool-output-pad om te zien of de agent rauwe resultaten opnieuw voedt in de prompt-generator.

Praktische checklist

- Haal de systeemprompt op en zoek naar harde, ingebouwde geheimen. - Lijst elke tool op, noteer zijn schema en probeer onverwachte datatypen door te geven. - Identificeer alle externe gegevensbronnen die voor RAG worden gebruikt en injecteer onschuldige markers om bereik te verifiëren. - Vang tool-outputs op en voer ze opnieuw in als nieuwe invoer om te zien of de agent ze als opdrachten behandelt. - Documenteer elke keten waarin een enkele gebruikersbericht meerdere tool-aanroepen tot gevolg heeft.

Voor vergelijking met klassieke injectie-verdedigingen, biedt de SQL-injectie-kaart nuttige patronen: OWASP A03:2021 – Injectie.

Overmatige agentbevoegdheid is het companionrisico

Wat overmatige agentbevoegdheid betekent

OWASP plaatst Overmatige Agentbevoegdheid op LLM03 voor 2026. Het beschrijft agents die onomkeerbare acties kunnen uitvoeren - e-mail verzenden, bestanden verwijderen, code uitvoeren - zonder een separate goedkeuringsstap. Het risico groeit wanneer de autonomie van het model de waarborgen rond zijn tools overtreft.

Focusgebieden voor rood team

- Controleer of destructieve tools een expliciete bevestiging van een mens of een separate service vereisen. - Probeer twee of meer tools samen te ketenen met behulp van alleen model-gegenereerde tussenoutputs. - Kijk of de agent zijn eigen privileges kan verhogen, bijvoorbeeld door een tool aan te roepen die zijn eigen API-sleutel bijwerkt. - Test tijd-gebaseerde triggers: kan een vertraagde toolaanroep worden gebruikt om een ratelimit of een sessietimeout te omzeilen?

Illustratieve risicomatrix

Toolcategorie | Typische privilege | Vereiste bevestiging | Potentieel misbruik als ontbreekt Bestand lezen | Alleen-lezen-toegang tot aangewezen mappen | Geen (lezen is meestal veilig) | Exfiltratie van logboeken, broncode, configuratie Bestand schrijven | Bestanden maken of overschrijven | Ja - gebruikersgoedkeuring of ondertekend verzoek | Invoeging van backdoors, corruptie van gegevens Database schrijven | INSERT/UPDATE/DELETE op tabellen | Ja - transactiegoedkeuring of MFA | Gegevensverlies, financiële fraude, privilege-escalatie Externe HTTP | Uitgaand netwerk naar willekeurige domeinen | Ja - allow-list-controle | Gegevensexfiltratie, C2-baken, SSRF Code-uitvoering | Willekeurige shell of interpreter | Ja - geïsoleerde sandbox + goedkeuring | Volledige host-compromis, ransomware-implementatie

De tabel laat zien waarom een rood team elke rij moet verifiëren: als de bevestigingskolom ontbreekt, kan de agent van onschadelijk naar schadelijk gaan met één vergiftigde invoer.

Wat een sonderingsrapport moet bevatten

Essentiële velden

Een nuttige bevinding heeft meer nodig dan een boolean "geslaagd/mislukt". Noteer de exacte gebruikersuitspraak die de keten activeerde, de geordende lijst van tools die de agent aanriep, en het finale waarneembare effect (bijv. een geschreven bestand, een verzonden netwerkverzoek, een gewijzigde databaserij). Neem de ruwe toolargumenten op zoals ze werden verzonden, en de interne redeneringstrace van het model als uw framework deze blootstelt.

Severityrichtlijn

- Laag - lekkage van openbare informatie of een omkeerbare statuswijziging. - Medium - toegang tot intern alleen-data die niet is gereguleerd, of een omkeerbare actie die handmatige reset vereist. - Hoog - wijziging van gereguleerde gegevens, financiële transactie of uitvoering van willekeurige code. - Kritiek - persistente backdoor, gegevensvernietiging of mogelijkheid om een voet aan de grond te houden na het einde van de sessie.

Prioriteer herstel voor hoge en kritieke bevindingen eerst; laagdrempelige items kunnen in een latere verhardingsprint worden aangepakt.

Actiegerichte herstelhinten

- Voeg schema-niveau-validatie toe die tekenreeksen afwijst die SQL-sleutelwoorden of shell-metacharacters bevatten. - Wikkel destructieve tools in een microservice die een ondertekend goedkeurings-token vereist. - Implementeer een egress-allow-list voor uitgaande HTTP-aanroepen en log elke poging tot verbinding. - Saniteer tool-outputs voordat ze opnieuw in het model-prompt worden ingevoegd - verwijder of escapeer alle inhoud die eruitziet als een instructie. - Gebruik een alleen-lezen-replica voor elke databasequery-tool, tenzij een schrijfactie expliciet vereist is.

Red teaming is geen vervanging voor ontwerpcontroles

Waarom testen een aanvulling is, geen vervanging, van waarborgen

Red-team-werk ontdekt gaten die al bestaan in de implementatie. Het creëert geen garanties die voortkomen uit het ontwerp van tools met minimale privileges, bevestigingspoorten of netwerksegmentatie. Behandel elke test als een validatiestap: als de controles de ingebrachte keten stoppen, heb je bewijs dat ze werken; als ze dat niet doen, heb je een concreet defect om te fixen.

Controles om prioriteit te geven

- Voer elke tool uit onder een speciale OS-gebruiker met de minimale set bestandssysteem-mogelijkheden. - Vereis een aparte goedkeuringsdienst voor elke oproep die staat kan wijzigen, log de beslissing en dwing een time-out af. - Pas netwerkbeleid toe dat outgebonden verbindingen beperkt tot bekende interne services en een korte lijst met externe API's. - Versleutel geheimen in rust en plaats ze nooit in het systeemprompt; gebruik een kluisdienst in plaats daarvan. - Log elke toolaanroep met gebruikers-ID, tijdstempel, invoerhash en uitvoerhash voor forensische analyse.

Wanneer deze controles zijn geïmplementeerd, verschuiven de resultaten van red teaming van 'we hebben een manier gevonden om het te breken' naar 'we hebben X geprobeerd en de controles hebben het geblokkeerd', wat een sterker signaal van beveiligingsvolwassenheid is.

Wat dit NIET is

Geen garantie van volledigheid

Deze handleiding belooft niet dat het volgen van de stappen elke mogelijke injectie zal detecteren. Nieuwe technieken, zero-day-toolkwetsbaarheden of ongepubliceerd agentfuncties kunnen de controles die hier worden beschreven, ontwijken.

Geen 100% oplossing

Het toepassen van de mitigaties vermindert het risico, maar elimineert het niet. Verdediging in diepte vereist voortdurende monitoring, regelmatige toolketenbeoordelingen en updates wanneer nieuwe OWASP-releases verschijnen.

Claim van nooit missen is vals

Geen enkele red-team-methode kan claimen nooit een fout te missen. Het doel is om de kosten voor een aanvaller te verhogen en om succesvolle exploitatie opmerkbaar en traceerbaar te maken.

Geen vervanging voor veilig programmeren

De aanbevelingen gaan ervan uit dat u al basisprincipes van veilig programmeren volgt - invoervalidatie, uitvoerencodering en het principe van minimale privileges. Zij voegen agent-specifieke lagen toe aan die basis.

Referenties

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://genai.owasp.org/llmrisk/llm01-prompt-injection - https://owasp.org/Top10/2021/A03_2021-Injection

Gerelateerde artikelen

- Tool-abuse tests voor LLM-agents - Verken de volledige AI micro-SaaS onderwerpenmatrix →