af AgentRedTeam (LX AI)

Agent red teaming og OWASP LLM01

En red-teaming-checkliste bygget til chatbots mangler det meste af, hvad der gør en agent farlig. Øjeblikket et model kan kalde værktøjer, læse filer eller sende beskeder, bliver prompt-injektion en vej til handling, ikke kun tekst. OWASPs GenAI LLM Top 10 for 2026 holder Prompt Injection på LLM01, og det er det rigtige sted at starte en agent-vurdering.

Hvorfor agenter ændrer injektionsmatematikken

Fra output til handling

I en ren chatbot er formålet med en injektion at få modellen til at sige noget, den ikke bør sige. Impacten stopper ved den tekst, der forlader modellen. Når samme model kan aktivere et værktøj, kan den injicerede tekst blive en kommando, som værktøjet udfører. En angriber, der kan styre et fil-læseværktøj til at hente en fortrolig dokument, eller et mail-sendeværktøj til at videregive dokumentet, har omdannet en ordspil til en datalæk. Alvorligheden afhænger derfor af, hvad værktøjet kan gøre, og ikke af, hvor clever svaret er.

Værktøjets rækkevidde definerer skadecirklen

Skadecirklen er unionen af alle ressourcer, som agentens værktøjer kan berøre. Hvis agenten kun har en læse-only API til en offentlig blog, er værste scenarie lækkage af offentlig information. Hvis agenten kan kalde en database-skriveværktøj, en fil-system-sletteværktøj eller en ekstern betalingsgateway, kan samme injektion slette poster, ændre balancer eller flytte penge. Red-team-arbejde skal kortlægge hvert værktøj til de dataforlag, services eller hardware, det kan påvirke, og derefter teste, om en injektion kan nå disse aktiver.

Almindelige misforståelser

- Antag, at modellens outputlængde begrænser skaden – forkert, fordi en kort streng kan udløse en destruktiv værktøjskald. - Tro, at filtrering af brugermeddelelsen er nok – forkert, fordi injektioner kan ankomme inde i værktøjsresultater eller systemprompts. - Tro, at en lav-parametermodel er sikker – forkert, når den model er parret med et kraftfuldt værktøjsæt.

Til en hurtig reference på defensiv kodning, se OWASP-cheatsheetet om LLM Prompt Injection Prevention.

Overflader til at sonde ud over chatboksen

Systemprompt og konfiguration

Systemprompten indeholder ofte API-nøgler, service-URL'er eller interne politikkersprog. En angriber, der kan injicere i dette område, kan få direkte legitimationsoplysninger eller lære, hvor han skal pege på yderligere sonder. Gennemgå prompten for eventuelle statiske hemmeligheder og test, om de kan ekko eller eksfiltreres gennem en værktøjskald.

Værktøjskemaer og argumentvalidering

Hvert eksponeret værktøj definerer et JSON-skema for sine inputs. Hvis skemaet accepterer fri-form-strings uden streng validering, kan en angriber indlejre kommandoer inde i disse strenger. F.eks. er et „run_sql“-værktøj, der tager en rå SQL-streng, sårbart over for SQL-injektion, medmindre agentlaget sanerer eller parameteriserer inputtet. Tjek, om agenten påtvinger typebegrænsninger, længdebegrænsninger eller tilladelselister for hvert argument.

Retrieval-forstærket generationspipeliner (RAG)

Når agenten henter data fra eksterne kilder – websteder, emails, ticketsystemer – bliver disse data en del af modellens kontekst. En angriber, der kontrollerer en af disse kilder, kan placere instruktioner, som modellen senere vil behandle som tillid. Sondér ved at forgifte en kendt ekstern feed og observere, om agenten handler på den skjulte kommando.

Instruktionspropagation inde i værktøjsresultater

Nogle designs returnerer værktøjsoutput direkte ind i den næste modellkald uden at gensanere. Hvis et værktøj returnerer en tekst, der indeholder en ny instruktion, kan modellen adlyde den i det næste trin. Dette skaber en to-trins injektion, hvor første trin er uskadelig data og andet trin er den maliciøse kommando. Test hver værktøjs outputsti for at se, om agenten genfoder rå resultater ind i promptgenerator.

Praktisk checklist

- Ekstraher systemprompten og søg efter hardkodede hemmeligheder. - List alle værktøjer, notér deres skema og forsøg at overføre uventede datatyper. - Identificér alle eksterne datakilder, der bruges til RAG, og injicer venlige markører for at verificere rækkevidde. - Fange værktøjsoutput og foder dem tilbage som nye inputs for at se, om agenten behandler dem som kommandoer. - Dokumentér enhver kæde, hvor en enkelt brugermeddelelse fører til multiple værktøjskald.

Til sammenligning med klassiske injektionsforsvar, tilbyder SQL-injektions-cheatsheetet nyttige mønstre: OWASP A03:2021 – Injektion.

Udvælgelse af agentrisiko er den ledsagende risiko

Hvad udvælgelse af agentrisiko betyder

OWASP placerer Excessive Agency på LLM03 for 2026. Det beskriver agenter, der kan udføre irreversibele handlinger – sende email, slette filer, udføre kode – uden en separat godkendelsesproces. Risikoen vokser, når modellens autonomi overhaler sikkerhedsforanstaltningerne omkring dens værktøjer.

Fokusområder for rød-hold

- Tjek, om destruktive værktøjer kræver en ekspllicit bekræftelse fra et menneske eller en separat tjeneste. - Prøv at kæde to eller flere værktøjer sammen ved hjælp af kun model-genererede mellemoutputs. - Se, om agenten kan hæve sin egen adgang, f.eks. ved at kalde et værktøj, der opdaterer sin egen API-nøgle. - Test tidsbaserede udløsere: kan en forsinket værktøjskald bruges til at omgå en ratelimit eller en sessions-timeout?

Illustrativ risikomatrix

Værktøjskategori | Typisk adgang | Nødvendig bekræftelse | Potentiel misbrug, hvis mangler Fil-læsning | Læs-adgang til udpegede mapper | Ingen (læsning er normalt sikkert) | Exfiltration af logs, kildekode, konfiguration Fil-skrivning | Oprettelse eller overskrivning af filer | Ja – bruger-godkendelse eller signeret anmodning | Indsættelse af bagdøre, korruption af data Database-skrivning | INSERT/UPDATE/DELETE på tabeller | Ja – transaktions-godkendelse eller MFA | Data-tab, finansielle svindel, adgangs-hævning Ekstern HTTP | Udgående netværk til vilkårlige domæner | Ja – tilladelsesliste-tjek | Data-exfiltration, C2-signalering, SSRF Kode-eksekvering | Vilkårlig shell eller fortolker | Ja – isoleret sandkasse + godkendelse | Fuldstændig vært-kompromittering, ransomware-udvikling

Tabellen viser, hvorfor et rød-hold skal verificere hver række: hvis bekræftelseskolonnen mangler, kan agenten bevæge sig fra harmløs til skadelig med en enkelt forgiftet input.

Hvad en sonde-rapport skal indeholde

Væsentlige felter

En nyttig opdagelse kræver mere end en boolean "bestå/ikke-bestå". Optegn den præcise bruger-udtalelse, der udløste kæden, den ordnede liste over værktøjer, som agenten kaldte, og den endelige observerbare effekt (f.eks. en fil skrevet, en netværksanmodning sendt, en database-række ændret). Inkluder de rå værktøjsargumenter, som de blev sendt, og modellens interne begrundelse-spor, hvis din ramme eksponerer det.

Alvorligheds-vejledning

- Lav – lækkage af offentlig information eller en reversibel tilstandsændring. - Medium – adgang til internt kun-data, der ikke er reguleret, eller en reversibel handling, der kræver manuel nulstilling. - Høj – ændring af reguleret data, finansielle transaktioner eller eksekvering af vilkårlig kode. - Kritisk – varig bagdør, data-destruktion eller evne til at opretholde fodfæste efter sessionens afslutning.

Prioriter løsninger for høje og kritiske fund først; lav-sværheds-punkter kan behandles i en senere hårdnings-sprint.

Handlebare remedierings-hint

- Tilføj skema-niveau-validering, der afviser streng, der indeholder SQL-nøgleord eller shell-metacharacters. - Indpakning destruktive værktøjer i en mikrotjeneste, der kræver en signeret godkendelsestoken. - Implementer en udgangs-tilladelsesliste for udgående HTTP-kald og log hver forsøgt forbindelse. - Saniter værktøjs-outputs, før de genindføres i modellens prompt – fjern eller escapér enhver indhold, der ligner en instruktion. - Brug en læse-kopi for enhver database-forespørgsel-værktøj, medmindre en skrivning er eksplitt krævet.

Red teaming er ikke en erstatning for designkontroller

Hvorfor testing komplementerer, ikke erstatter, sikkerhedsforanstaltninger

Red-team-arbejde opdager huller, der allerede findes i implementeringen. Det skaber ikke de garantier, der kommer fra mindst-privilegeret værktøjsdesign, bekræftelsesporter eller netværkssegmentering. Behandle hver test som en valideringsstep: hvis kontrollerne stopper den indsprøjtede kæde, har du bevis for, at de virker; hvis de ikke gør, har du en konkrekt fejl at løse.

Kontroller til at prioritere

- Kør hver værktøj under en dedikeret OS-bruger med det minimale sæt af filsystemkapaciteter. - Kræv en separat godkendelsesservice for enhver opkald, der kan ændre tilstand, log beslutningen og gennemtving timeout. - Anvend netværkspolitikker, der begrænser udgående forbindelser til kendte interne tjenester og en kort liste over eksterne API'er. - Kryptér hemmeligheder i ro og placer dem aldrig i systemprompten; brug en vault-tjeneste i stedet. - Log hver værktøjsaktivering med bruger-ID, tidsstempel, indputhash og outputhash til forensisk gennemgang.

Når disse kontroller er på plads, skifter red-team-fund fra “vi fandt en måde at bryde det” til “vi forsøgte X og kontrollerne blokerede det”, hvilket er et stærkere signal af sikkerhedsmoden.

Hvad dette IKKE er

Ingen garanti for fuldstændighed

Denne vejledning lover ikke, at følge trinnene vil fange hver mulig injektion. Nye teknikker, zero-day-værktøjsvulnerabiliteter eller udisclosed agentfunktioner kan undgå de kontroller, der er beskrevet her.

Ikke en 100 % løsning

At anvende mitigationsforanstaltningerne reducerer risikoen, men eliminerer den ikke. Forsvar-i-dybden kræver fortsat overvågning, regelmæssige værktøjskæde-gennemgange og opdateringer, når nye OWASP-udgivelser dukker op.

Aldrig-miss-krav er falsk

Ingen red-team-metode kan hævde, at aldrig missende en svaghed. Målet er at øge omkostningerne for en angriber og at gøre succesfuld udnyttelse synlig og sporbar.

Ikke en erstatning for sikker kodning

Anbefalingerne antager, at du allerede følger grundlæggende sikker-kodningspraksis - inputvalidering, output-kodning og princip om mindst-privilegie. De tilføjer agent-specifikke lag oven på den grundlag.

Referencer

- 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

Relaterede artikler

- Tool-misbrugstests for LLM-agenter - Udforsk det fulde AI mikro-SaaS emne-matrix →

Hvorfor er prompt-injektion stadig LLM01 i 2026?

Fordi mekanismen ikke er ændret: Ubetroet indhold når modellen og behandles som instruktion. Agent-kapaciteter gør konsekvensen værre, hvilket er hvorfor OWASP holder det øverst på listen, samtidig med at de tilføjer Excessive Agency som en ledsagende risiko.

Hvad gør en agent til en højere risiko end en chatbot?

En agent kan handle gennem værktøjer, ikke kun svare. Injektion, der kun producerede forkert tekst i en chatbot, kan udløse et værktøjskald, en filskrivning eller en ekstern besked i en agent. Blast-radius er værktøjs-sættet, ikke svaret.

Hvilke overflader skal jeg undersøge først?

Systemprompts, værktøjsskemaer, indhold fra hentning og instruktioner indbygget i værktøjsresultater. Ethvert sted, hvor ubetroet tekst kommer ind i agentens kontekst, er en kandidat til injektionspunkt.

Erder red teaming en erstatning for sikkerhedsdesign?

Nej. Testning afslører eksisterende huller. Mindst-privilegeret adgang til værktøjer, bekræftelse på destruktive handlinger og egress-kontroller er, hvad der forhindrer flugt. Red teaming validerer disse kontroller efter, at de eksisterer.

Kun til beslutningsstøtte. Ikke en certificeret penetrationstest eller compliance-attest.

← Tilbage til blog

Var dette resultat nyttigt?Feedback