Meta lot supportboten slippe inn angripere

Instagram har stengt en sikkerhetsfeil der angripere ifølge TechCrunch kunne lure Metas AI-drevne supportbot til å gi tilgang til andres kontoer. Saken er liten målt i kjente tall. Den er stor målt i hva den sier om AI i kundeservice.

TechCrunch skriver at flere brukere meldte om kaprede Instagram-kontoer gjennom helgen. Blant kontoene som ble nevnt var den inaktive Instagram-kontoen til Obama-periodens White House og kontoen til John Bentivegna, øverste enlisted-leder i U.S. Space Force. Sikkerhetsforskeren Jane Wong opplyste også at kontoen hennes ble overtatt.

Angrepet skal ikke ha krevd kontroll over offerets e-post. Ifølge beskrivelsene brukte angriperen en supportflyt der Metas AI-assistent kunne presses til å sende eller akseptere gjenoppretting på angriperens premisser. TechCrunch skriver at Instagram-talsperson Andy Stone svarte at problemet var løst. Det er fortsatt uklart hvor mange kontoer som faktisk ble berørt.

Dette er ikke bare en Meta-sak. Det er en varselbjelle for alle virksomheter som setter AI inn i support, identitetsgjenoppretting, onboarding og klagebehandling. Når en chatbot får påvirke tilgang, endre kontaktpunkt eller drive en eskalering, blir den en del av sikkerhetsarkitekturen. Da holder det ikke å teste om den svarer pent. Den må testes som en angripbar kontrollflate.

AI-support blir en tilgangsrisiko

Kundeservice har alltid vært et svakt punkt i identitetssikkerhet. Menneskelige supportmedarbeidere kan sosialmanipuleres. Rutiner kan presses. Dokumentasjon kan forfalskes. Forskjellen nå er at virksomheter legger en modell mellom brukeren og beslutningen. Modellen kan være raskere, billigere og mer tilgjengelig enn et menneske. Den kan også være mer konsekvent feil hvis flyten rundt den er dårlig bygget.

I Instagram-saken var det særlig alvorlige signalet at angriperen angivelig ikke trengte å kompromittere e-posten som var knyttet til kontoen. Hvis en gjenopprettingsprosess kan flyttes til en ny e-post, et nytt kontaktpunkt eller en ny kanal etter en dialog med AI, er det ikke lenger en ren supportfunksjon. Det er en privilegert identitetsoperasjon.

For norske virksomheter er læringen praktisk. AI i kundeservice må skilles fra AI i tilgangsstyring. En modell kan gjerne hjelpe brukeren å finne skjema, forklare regler eller samle inn informasjon. Men den bør ikke alene kunne endre e-post, tilbakestille MFA, gi ny enhet tilgang, endre betalingsdetaljer eller godkjenne eierskap til en konto.

Der beslutningen faktisk påvirker tilgang, må det være harde sperrer utenfor modellen. Ikke bare en systemprompt. Ikke bare et policyavsnitt. Ikke bare en beskjed om at assistenten ikke skal gjøre noe farlig. En angriper angriper ikke intensjonen. Han angriper grensesnittet, konteksten og hullene mellom systemene.

Dette bør CISO og produkteier sjekke

Første kontrollpunkt er fullmakter. Hvilke handlinger kan en AI-assistent direkte eller indirekte utløse? Mange team beskriver boten som rådgivende, men kobler den til saksflyt, CRM, ID-verifisering eller interne verktøy. Da kan den i praksis bli en døråpner.

Andre kontrollpunkt er gjenoppretting. Konto- og tilgangsgjenoppretting bør behandles som høy risiko. Hvis AI brukes i flyten, må prosessen ha uavhengig verifikasjon, rate limits, logging og menneskelig kontroll for sensitive endringer. Det bør også være tydelig hvilke bevis som aldri er nok, uansett hvor overbevisende historien er.

Tredje kontrollpunkt er prompt-injection og sosial manipulering. Supportboten møter brukere med sterke insentiver til å presse systemet. Angriperen kan late som han er offer, regulator, intern ansatt, utvikler eller journalist. Han kan be modellen gå i en annen modus. Han kan fylle dialogen med falske bevis. Dette må inn i testplanen, ikke ligge som en fotnote i risikoregisteret.

Fjerde kontrollpunkt er observability. Sikkerhetsteamet må kunne se når AI-assistenten blir brukt i kontoendringer, hvilke bevis som ble presentert, hvilke systemkall som ble gjort, og hvor ofte samme mønster gjentas. Uten slik logging blir AI-support en blind flekk.

Femte kontrollpunkt er ansvarsdeling. Hvem eier risikoen når produktteamet vil automatisere support, sikkerhetsteamet eier identitet og kundeservice eier brukeropplevelsen? Hvis svaret er uklart, får modellen for mye makt for fort.

Ikke la boten bli helpdesk-admin

Det fristende med AI-support er kostnadskutt og kortere svartid. Det er reelt. Men support er ikke bare dialog. I mange virksomheter er support også et alternativt kontrollplan for identitet. Den kan endre e-post, oppheve sperrer, validere eierskap, slå sammen kontoer, stoppe fakturaer og gi tilgang til data.

Når AI settes inn der, må sikkerhetsmodellen endres. En chatbot som kan snakke med brukeren er ikke farlig i seg selv. En chatbot som kan påvirke tilganger, uten robuste tekniske sperrer rundt seg, er noe helt annet.

Meta-saken bør derfor brukes som en konkret test i norske ledergrupper: Har vi AI i supportflyter som kan påvirke konto, betaling, persondata eller tilgang? Hvis ja, hvilke handlinger er sperret maskinelt, og hvilke stoler vi bare på at modellen ikke gjør?

Det siste svaret er det farlige. Modeller er gode til dialog. De er ikke en erstatning for tilgangskontroll.

Kilder og medier

Kilde: TechCrunch, "Hackers hijacked Instagram accounts by tricking Meta AI support chatbot into granting access", publisert 1. juni 2026: https://techcrunch.com/2026/06/01/hackers-hijacked-instagram-accounts-by-tricking-meta-ai-support-chatbot-into-granting-access/

Supplerende kilder: Krebs on Security om samme hendelse og Sid's Blog med teknisk beskrivelse av gjenopprettingsflyten.

Thumbnail: OpenAI Image 2 / hogby.ai