AI-agenter går fra å svare på spørsmål til å utføre handlinger: lese innbokser, spørre databaser, oppdatere saker, sende meldinger og kalle API-er. Det endrer sikkerhetsbildet. En modell som bare produserer tekst, kan villede; en agent med verktøy kan handle ut fra den teksten. Prompt injection, der instruksjoner skjult i innhold styrer modellen, er den mest omtalte risikoen, men den er én av flere. Denne guiden forklarer de viktigste risikoene på et enkelt språk og kontrollene som reduserer dem.
Hva det er
Store språkmodeller skiller ikke pålitelig mellom instruksjoner fra operatøren og instruksjoner som er innebygd i dataene de behandler. Direkte prompt injection skjer når en bruker skriver instruksjoner som skal overstyre systemets regler. Indirekte prompt injection skjer når modellen leser eksternt innhold, som en nettside, en e-post, et dokument eller en supportsak, som inneholder skjulte instruksjoner, for eksempel om å avsløre data eller kalle et verktøy. Andre risikoer forsterker dette. Sensitiv informasjon kan lekke når modellen har tilgang til data brukeren ikke skal se. For stor handlefrihet (excessive agency) oppstår når en agent har vide verktøytillatelser, som muligheten til å sende e-post eller slette poster, uten bekreftelse. Feil håndtering av utdata oppstår når utdata fra modellen sendes direkte inn i kode, spørringer eller nettsider uten validering. Risiko i forsyningskjeden kommer fra tredjepartsmodeller, utvidelser og koblinger. OWASP Top 10 for LLM-applikasjoner (2025-utgaven) katalogiserer disse og beslektede kategorier, som lekkasje av systemprompt og ubegrenset ressursbruk, og OWASP GenAI Security Project publiserer også veiledning spesifikt for agentbaserte applikasjoner. Fordi ingen nåværende teknikk fullt ut forhindrer prompt injection, bør designet anta at noen injiserte instruksjoner vil lykkes, og begrense hva de kan gjøre.
Hvem det er for
Denne guiden er relevant for:
- Team som bygger agenter som bruker verktøy, API-er eller selskapsdata
- Virksomheter som tar i bruk AI-assistenter for kunder eller ansatte
- Sikkerhets- og risikoansvarlige som blir bedt om å godkjenne en AI-funksjon
- Produkteiere som integrerer AI-plattformer eller koblinger fra tredjeparter
Hva det hjelper med å klarlegge
En gjennomgang av disse risikoene bidrar til å avklare:
- Hvilke data agenten kan lese, og om hver bruker har rett til dem
- Hvilke handlinger agenten kan utføre, og hvilke som krever menneskelig bekreftelse
- Hvordan upålitelig innhold når modellen, og hva det kan påvirke
- Hvor utdata fra modellen går videre, og om de valideres
Hva er inkludert
- Lag en oversikt over alle verktøy, koblinger og datakilder agenten har tilgang til
- Bruk minste privilegium: gi hvert verktøy den smaleste tillatelsen og avgrens det til gjeldende bruker
- Krev menneskelig bekreftelse for handlinger som sender, sletter, betaler, publiserer eller endrer tillatelser
- Behandle hentet innhold, e-poster, filer og nettsider som upålitelige inndata
- Skill systeminstruksjoner fra bruker- og hentet innhold så tydelig som plattformen tillater
- Valider og kod utdata fra modellen før de når kode, spørringer eller nettsider
- Håndhev tilgangskontroll i datalaget, ikke i prompten
- Sett grenser for rate, kostnad og antall handlinger per økt
- Logg prompter, verktøykall og utfall med egnede personvernhensyn, og gjennomgå dem
- Test med fiendtlige inndata, inkludert indirekte injeksjon via dokumenter og lenker
- Definer en måte å raskt deaktivere et verktøy eller agenten på hvis misbruk oppdages
Hva er ikke inkludert
- En påstand om at prompt injection kan forhindres fullstendig
- Sertifisering eller regulatorisk godkjenning av et AI-system
- Juridisk rådgivning om AI-regulering
- Kontinuerlig overvåking av agenter i produksjon, med mindre det er avtalt separat
Når skal den velges
Håndter disse risikoene før en agent kobles til ekte verktøy eller data, og igjen hver gang nye verktøy, datakilder eller brukergrupper legges til. En agent som var trygg som en intern prototype med bare lesetilgang, er ikke nødvendigvis trygg når den kan sende e-post til kunder. Hvis en leverandør tilbyr agentplattformen, spør hvordan den håndterer verktøytillatelser, bekreftelsestrinn, logging og dataisolering.
Vår tilnærming
Design for inndemming i stedet for perfekt forebygging. Spør hva det verste realistiske utfallet ville være hvis en injisert instruksjon lyktes, og reduser deretter tillatelser og legg til bekreftelsestrinn til utfallet er akseptabelt. Hold autorisasjonsbeslutninger i deterministisk kode utenfor modellen. Tjenesten vår LLM & AI Agent Security Review undersøker avtalte AI-systemer med tanke på prompt injection, eksponering av data, usikre utdata, risiko ved datainnhenting (retrieval), verktøytillatelser og grenser for overlevering til mennesker, og leverer skriftlige funn med prioriterte anbefalinger. Der dere fortsatt utformer agenten, kan Secure AI Agent Integration bygge den med godkjente data, avgrensede verktøy og kontrollpunkter fra starten, og AI Governance, Policy & Data Safety kan definere bruksreglene rundt den. Gjenta gjennomgangen når modeller, verktøy eller datakilder endres, fordi atferden kan endre seg med hver av dem.
Ofte stilte spørsmål
Beslektede artikler
Kom i gang
Kobler dere en AI-agent til ekte verktøy eller data?
Beskriv agenten, verktøyene, datakildene og brukerne. Vi foreslår en avgrenset sikkerhetsgjennomgang.
Be om et skriftlig omfang