Hva bør en KI-agent få tilgang til og lov til å gjøre?

Hvilke tilganger trenger agenten?

En KI-agent kan få innsyn i kundedata, interne priser, avtaler eller forretningsplaner. Den kan også få mulighet til å sende meldinger eller endre opplysninger. Det som gjør den nyttig for bedriften, kan også gjøre den interessant for uvedkommende.

Se igjen for deg en assistent som skal hjelpe med reiseregninger. Den trenger kanskje reiseregler og brukerens egne bestillinger. Det gir ikke i seg selv grunn til å åpne hele personalarkivet eller tillate utbetalinger. Vi bør starte med en liste over opplysninger og handlinger oppgaven faktisk krever.

Vi bør bygge løsningen slik at skaden blir begrenset også om noen klarer å lure modellen. En agent som bare kan lese egne reiser og lagre utkast, har færre muligheter til å gjøre skade enn en som kan hente personalopplysninger og godkjenne utbetalinger.

Hva er prompt injection?

Prompt injection betyr at tekst forsøker å styre modellen på en måte som strider mot oppgaven eller reglene som er forhåndsdefinert i programvaren. Det kan skje direkte i en melding fra brukeren, eller indirekte i et dokument, en nettside eller et verktøysvar agenten leser.

Et vedlegg til en reiseregning kan for eksempel inneholde en beskjed om å sende opplysningene til en uvedkommende, eller hente ut informasjon om en annen kollega. Modellen skal lese vedlegget som dokumentasjon, men kan komme til å behandle beskjeden som en ordre.

Dette er noe annet enn en hallusinasjon, der modellen lager en uriktig påstand. En manipulert agent kan hente helt riktige data og likevel sende dem til feil mottaker, eller hente data den ikke får lov til å hente. Godt kildegrunnlag løser derfor ikke hele sikkerhetsoppgaven.

Svakheter i chatbot-utvidelser

I en studie fra 2025 fant forskere ved UC Santa Barbara at åtte av 17 undersøkte chatbot-utvidelser lot brukeren forfalske deler av samtalehistorikken. Brukeren kunne dermed legge inn meldinger som så ut til å komme fra en rolle med større myndighet.

Her lå svakheten i programvaren rundt modellen. Hvis chatboten godtar at brukeren selv bestemmer hvem en melding kommer fra, hjelper det lite å skrive strengere instrukser til modellen. Samtalehistorikken og brukerens rolle må kontrolleres av serveren.

Lange dokumenter må også testes

LongPIBench fra august 2026 undersøker angrep gjemt i forskningsartikler, CV-er, kode og e-posttråder. Forsvar som fungerte godt i korte tester, kunne svikte når teksten ble lengre.

Skal assistenten lese lange avtaler, ville jeg derfor testet den med lange avtaler. Både innholdet og omfanget bør ligne det den møter i bruk. En kort demonstrasjon forteller lite om hvordan den håndterer en instruks gjemt langt inne i et dokument.

Når sikkerhetstiltak fjerner nyttig innhold

SecFid-studien fra juni 2026 fant at enkelte forsvar stoppet mange angrep ved å ignorere tekst. Problemet var at noe av teksten var nødvendig for å løse oppgaven. Sikkerheten gikk dermed på bekostning av funksjonaliteten.

En assistent som hopper over viktige vilkår i en avtale, kan gi en misvisende oppsummering selv om den avviser angrepet. Testene må derfor undersøke både om manipulasjonen stoppes og om assistenten fortsatt gjør jobben riktig.

Angriperen kan prøve igjen

I et NIST-forsøk fra januar 2025 lyktes det sterkeste av de opprinnelige angrepene i 11 prosent av tilfellene. Etter at forskerne tilpasset angrepene til systemet, lyktes det sterkeste i 81 prosent av tilfellene. Forsøket brukte en 2024-modell og én bestemt testserie, men viser hvor mye fremgangsmåten kan bety.

En angriper med noe å vinne kan prøve mange formuleringer og lære av svarene. Det er derfor helt essensielt å vite hvilke variasjoner løsningen er testet mot, og hva som skjer når noen forsøker gjentatte ganger. Det er også viktig med god logging slik at man oppdager gjentatte mistenkelige forespørsler tidlig og kan gjøre grep.

Sikkerhet i flere lag

Hvis modellen lar seg lure, må programvaren rundt fortsatt kunne stoppe en handling eller hindre at data sendes ut. For reiseassistenten kan vi legge inn disse kontrollene:

• Datatilgang: Serveren kontrollerer hvem brukeren er og henter bare dokumenter og reiser vedkommende får se.
• Verktøy: Agenten får avgrensede funksjoner som «hent egen reise» og «lagre utkast», ikke fri tilgang til databasen eller et kommandovindu.
• Validering: Programvaren kontrollerer felter, tillatte verdier og rettigheter før hvert verktøykall.
• Utgående data: Forbindelser og mottakere begrenses. Modellen får ikke velge vilkårlige adresser for å sende informasjon ut.
• Godkjenning: Handlinger som kan gi vesentlige konsekvenser krever en kontroll av akkurat det som skal utføres.
• Drift: Relevante hendelser logges uten unødvendige sensitive data. Bruksgrenser, varsling og en måte å stenge tilganger på avtales.

Hva om agenten ikke har websøk?

En chatbot kan bygges uten websøk og uten mulighet til å åpne vilkårlige nettadresser. Det håndhever vi ved å begrense verktøyene og nettverkstilgangen.

Samtidig kan interne dokumenter inneholde tekst fra eksterne parter, gamle vedlegg eller brukerbidrag. RAG-søk og MCP-integrasjoner gjør ikke slikt innhold automatisk pålitelig. Vi må undersøke hvem som kan påvirke kildene, og hvilke konsekvenser det kan få.

Et dokument med et godt søketreff kan fortsatt inneholde et angrep. Relevansterskelen hjelper oss å finne materiale om riktig tema; tilgangskontrollen må begrense hva agenten kan gjøre med det.

Dette bør leverandøren kunne vise

Enten dere kjøper en ferdig tjeneste eller bestiller en skreddersydd løsning, bør leverandøren kunne vise hvordan tilgangene er begrenset og hva som er testet. Be om konkrete svar på disse spørsmålene:

• Hvilke data kan agenten lese, og hvordan kontrolleres brukerens tilgang?
• Hva kan agenten utføre på egen hånd, og hva må godkjennes?
• Hva skjer når den mangler kilder eller får motstridende opplysninger?
• Hvilke manipulasjonsforsøk er prøvd, og hvilke svakheter gjenstår?
• Hvem følger opp sikkerhetsfunn og endringer etter levering?