Ett øres-overføring kan hacke bank-AI-assistenten din

En overføring på to øre med en skjult melding i beskrivelsesfeltet – det er alt som skal til for å kompromittere en bank-AI-assistent. Det har sikkerhetsfirmaet Blue41 demonstrert overfor den nederlandske nettbanken bunq, og resultatet bør få alle som jobber med AI-agenter til å stoppe opp.

Angrepet heter indirekte prompt injection, og det er ikke et nytt konsept – men at det nå demonstreres mot faktiske finansielle AI-systemer i produksjon, er et tegn på at vi er inne i en ny fase. AI-agenter gjør mer og mer. Det betyr at konsekvensene av at de lures, også blir større.

Her er hva som faktisk skjedde, hvorfor dette er et strukturelt problem i moderne AI-arkitektur – og hva du bør tenke på hvis du er med på å bygge, bruke eller godkjenne AI-agenter.

Hva er indirekte prompt injection?

Prompt injection er en angrepsmetode der noen prøver å gi AI-en skjulte instruksjoner som overstyrer det den egentlig skal gjøre. Den direkte varianten er relativt godt kjent: du skriver noe inn i en chatbot og forsøker å lure den. Den indirekte varianten er mer lumsk – og mye vanskeligere å forsvare seg mot.

Ved indirekte prompt injection er det ikke brukeren som forsøker å manipulere AI-en. Det er data fra omverdenen – dokumenter, e-poster, transaksjonshistorikk, nettsider – som inneholder skjulte instruksjoner. Når AI-agenten henter disse dataene og behandler dem som en del av konteksten, tolker den de innebygde instruksjonene som faktiske kommandoer.

Sagt enkelt: AI-en klarer ikke å skille mellom data og instruksjoner. Og det er et fundamentalt arkitekturproblem, ikke en feil du kan lappe med én oppdatering.

Slik fungerte angrepet mot bunq

Blue41 demonstrerte angrepet i tre steg, og det er verdt å gå gjennom dem fordi de viser hvor lavt terskelen faktisk er.

Steg 1 – Injeksjon: Angriperen sender en pengeoverføring til offeret – i dette tilfellet tilsvarende to øre. Det er beløpet som gjør det nesten usynlig. I beskrivelsesfeltet legges det inn en prompt injection-payload, altså en skjult tekst-instruksjon rettet mot AI-assistenten.

Steg 2 – Aktivering: Offeret åpner bankappen sin og stiller et helt normalt spørsmål til AI-assistenten, for eksempel «Vis meg mine siste transaksjoner» eller «Hva har jeg brukt penger på denne uken?»

Steg 3 – Utførelse: AI-assistenten henter transaksjonshistorikken, som nå inneholder angriperens beskrivelse. Den tolker den innebygde instruksjonen som en kommando fra brukeren og utfører den. I Blue41s test resulterte dette i et svært troverdig phishing-angrep der assistenten ba brukeren re-autentisere seg – presentert som om det kom fra banken selv.

Det som gjør dette angrepet elegant og skremmende på en gang, er at offeret ikke trenger å gjøre noe feil. De stiller et normalt spørsmål. AI-en gjør resten.

Hvorfor er dette et problem som ikke forsvinner av seg selv?

Mange i Hacker News-diskusjonen rundt denne saken påpeker noe viktig: dette er ikke en bug, det er en arkitekturfeil. Dagens store språkmodeller skiller ikke mellom instruksjoner og data – alt er tekst, og tekst kan potensielt tolkes som en kommando.

Det er fundamentalt annerledes fra tradisjonell programvare, der kode og data er adskilte. En SQL-injection-sårbarhet kan lappes. Indirekte prompt injection er vanskeligere fordi selve modellen er designet for å være fleksibel og kontekstsensitiv – det er jo det som gjør den nyttig.

Problemet forverres når AI-agenter får tilgang til å utføre handlinger: sende meldinger, flytte penger, opprette forespørsler. Jo mer en agent kan gjøre, jo større er konsekvensene av at den lures. Bankappen er et nesten perfekt scenario for angriperen – den har tilgang til sensitiv informasjon og kan i prinsippet initiere handlinger med finansielle konsekvenser.

Hva anbefaler Blue41 som forsvar?

Blue41s rapport foreslår en firelags forsvarsstrategi, og den er fornuftig selv om den ikke er noen garanti. Det er verdt å kjenne til den:

Minimer kontekst: Ikke send felt til AI-assistenten med mindre de faktisk trengs for oppgaven brukeren skal utføre. Jo mindre data assistenten ser, jo mindre angrepsflate. En assistent som bare skal svare på spørsmål om kontobalanse, trenger ikke se transaksjonsnotater.

Behandle hentet data som ikke-klarert: Skill eksplisitt mellom brukerinstruksjoner og eksternt hentet data i arkitekturen. Dette er teknisk utfordrende, men nødvendig. Noen gjør dette ved å ha separate prompt-seksjoner med tydelig merking.

Begrens sensitiv output: Overvåk og begrens hva AI-assistenten kan gi ut – spesielt lenker, legitimasjonsforespørsler og verktøykall. En assistent som ikke kan sende lenker, kan ikke sende phishing-lenker.

Overvåk kjøretidsatferd: Anomalideteksjon på selve AI-assistentens oppførsel – hvilke datakilder brukes, hvilke responsmønstre produseres, hvilke verktøy kalles. Uvanlig atferd kan avsløre et pågående angrep.

Det Blue41 ikke sier eksplisitt, men som henger mellom linjene i rapporten, er at det kanskje viktigste forsvaret er det enkleste: gi AI-agenter minst mulig tilgang til å faktisk gjøre ting. En AI som kan lese og svare er langt mindre risikabel enn en AI som kan lese, svare og handle.

Hva betyr dette for AI-agenter generelt?

Bankeksemplet er illustrativt fordi det er konkret og konsekvensene er åpenbare. Men prompt injection-problemet er ikke begrenset til bankapper. Enhver AI-agent som henter data fra omverdenen – e-poster, dokumenter, nettsider, CRM-systemer, transaksjonslogger – er potensielt sårbar.

Jeg har skrevet om AI-agenter i bedriften og AI-assistenter som lures av e-post tidligere. Mønsteret er det samme: data fra ikke-klarerte kilder havner i kontekstvinduet, og AI-en kan ikke vite at den ikke skal stole på det.

Det som skjøt fart her er det kombinerte angrepet: injeksjonen skjer eksternt (angriperen sender en ubetydelig overføring), aktiveringen er passiv (offeret gjør noe de gjør hver dag), og utførelsen er automatisk. Det krever ingen feil av brukeren utover å bruke appen sin normalt.

For de som bygger AI-agenter og AI-assistenter er dette en klar påminnelse: det å gi en AI-agent tilgang til å hente data fra omverdenen, og det å gi den verktøy til å handle, er to separate risikovurderinger. Begge må tas på alvor – og jo mer agenten kan gjøre, jo grundigere bør sikkerhetsarbeidet være.

Blue41 hjelper bunq med å sikre systemet sitt. Det er bra. Det hadde vært enda bedre om bankene tenkte på dette før AI-assistenten gikk i produksjon. Den fullstendige rapporten fra Blue41 er verdt å lese for alle som jobber med AI-systemer som håndterer sensitive data.

Ofte stilte spørsmål