AI-nøkler lekker fra både agentferdigheter og iOS-apper

Forskning fra Wake Forest University peker på en felles svakhet i to raskt voksende AI-økosystemer: Hemmelige nøkler og tilgangspoletter blir ofte lagt på steder der agenter, apper eller angripere kan hente dem ut. I én studie ble 17 022 tredjepartsbaserte agentferdigheter undersøkt. Forskerne fant 520 berørte ferdigheter med til sammen 1 708 sikkerhetsproblemer. En separat studie av 444 iOS-apper med store språkmodeller (LLM-er) fant at 282 eksponerte legitimasjoner eller mekanismer for tilgang til backend-systemer under testing. 124

Risikoen handler om mer enn at en tilfeldig tekststreng kommer på avveie. En eksponert nøkkel eller et token kan gi tilgang til private data, agentens funksjoner eller betalt modellbruk på utviklerens konto.

Hva studien av agentferdigheter fant

Forskerne valgte ut 17 022 ferdigheter fra 170 226 artefakter på SkillsMP, en åpen markedsplass for agentferdigheter. Analysen kombinerte statisk deteksjon av hemmeligheter, dynamisk testing i sandkasse med testlegitimasjoner og kontroller som sammenlignet ferdighetens beskrevne formål med det den faktisk gjorde under kjøring. 34

Analysen viste blant annet:

• 520 berørte ferdigheter med 1 708 sikkerhetsproblemer, fordelt på 10 mønstre for lekkasje av legitimasjoner. 416
• 466 av de 520 berørte ferdighetene eksponerte legitimasjoner som kunne brukes uten utvidede privilegier. Det tilsvarer en rapportert umiddelbar utnyttelsesgrad på 89,6 prosent. 14
• I 76,3 prosent av lekkasjetilfellene måtte forskerne undersøke både ferdighetens naturlige språk og programkoden for å oppdage problemet.
• 3,1 prosent av tilfellene skyldtes instruksjonsangrep i naturlig språk, uten kjørbar kode. 4

Det betyr at en tradisjonell kodegjennomgang alene kan overse viktige risikoer. En ferdighet kan beskrive en tilsynelatende legitim oppgave, mens instruksjonene eller støtteskriptene samtidig eksponerer hemmeligheter under kjøring.

Debug-logger kan gjøre hemmeligheter lesbare for modellen

Debug-logging var et særlig viktig lekkasjemønster. I agentrammeverk som sender standardutdata inn i modellens kontekst, kan en legitimasjon som skrives ut med funksjoner som print eller console.log, bli tilgjengelig gjennom en helt vanlig forespørsel i naturlig språk. Studien peker på debug-logging som den viktigste lekkasjeveien, og knytter 73,5 prosent av lekkasjene til at utdata ble eksponert for LLM-er. 4

Risikoen begrenser seg ikke til åpenbare, hardkodede API-nøkler. Legitimasjoner kan også eksponeres gjennom skript, miljøvariabler, håndtering av konfigurasjon, logger, instruksjoner i prompten eller kombinasjoner av kode og språk som først blir farlige under normal bruk.

Både ondsinnet og uforsiktig utvikling spiller inn

Forskningen beskriver to hovedårsaker til lekkasje av legitimasjoner:

• Ondsinnet utvikling: En ferdighet inneholder bevisst instruksjoner eller nyttelast som skal samle inn legitimasjoner eller private data, og som potensielt kan sende dem videre til en ekstern server.
• Uforsiktig utvikling: Utvikleren følger ikke sikker praksis og etterlater utilsiktet legitimasjoner eller tilgangsveier som angripere kan utnytte. 1

Skillet er viktig når problemet skal håndteres. Ondsinnet innhold må oppdages og fjernes, mens utilsiktede lekkasjer krever bedre håndtering av hemmeligheter, tryggere logging, sterkere autentisering og testing før publisering.

Etter at forskerne varslet SkillsMP, opplyste Wake Forest at alle identifiserte ondsinnede ferdigheter var fjernet, og at de fleste sårbare ferdighetene var rettet. Studien advarer likevel om at opprydding i det opprinnelige arkivet ikke nødvendigvis er nok: Forgrenede kopier kan fortsatt inneholde eksponerte legitimasjoner etter at kilden er sikret. 14

iOS-studien fant en annen vei til kapring av LLM-kontoer

Den relaterte iOS-studien undersøkte 444 apper med LLM-funksjoner. Forskerne fant at 282 – rundt 64 prosent – eksponerte utnyttbare LLM-legitimasjoner eller mekanismer for tilgang til backend-systemer i nettverkstrafikken. 25

De rapporterte lekkasjetypene var:

• JWT-baserte poletter som kunne gjenbrukes: 48 prosent
• Backend-proxyer uten autentisering: 33 prosent
• API-nøkler sendt i klartekst: 19 prosent 3

Svakhetene kan være synlige under helt vanlig bruk av appen. En angriper som fanger opp en nøkkel, gjenbruker et token eller finner en åpen proxy, kan i noen tilfeller sende forespørsler via utviklerens LLM-konto. Det kan bruke opp betalt modellkapasitet, misbruke tilknyttede skytjenester eller føre til uautoriserte kostnader. 25

Funnene underbygger risikoen for svært høye eller potensielt ubegrensede kostnader, avhengig av kontogrensene og hvor lenge et innbrudd varer. De dokumenterer imidlertid ikke i seg selv et konkret tap på for eksempel «flere hundre tusen dollar».

Også feilrettingen gikk sakte. Tre måneder etter at sårbarhetene ble meldt inn gjennom ansvarlig varsling, hadde bare 28 prosent av de berørte iOS-appene rettet problemet. I oppfølgingen var dermed 72 prosent fortsatt utnyttbare. 311

Derfor er sikkerhet viktig i AI-assistert utvikling

Sett under ett viser studiene at en ny AI-funksjon eller en gjenbrukbar agentferdighet kan utvide angrepsflaten i et produkt. De nye risikoene omfatter blant annet:

• Leverandørnøkler som bygges inn i klientapper eller eksponeres i agentens kontekst
• Verktøy med privilegert tilgang til filer, tjenester eller private data
• Logger som utilsiktet blir en del av modellens lesbare kontekst
• Backend-endepunkter som godtar forespørsler uten tilstrekkelig autentisering
• Poletter som angripere kan spille av på nytt
• LLM-kostnader som en angriper kan påføre utviklerens konto

Bekymringen øker i takt med at utviklere bruker AI-assistert «vibe coding» for å generere og sette sammen programvare raskt. Høy fart erstatter ikke trusselmodellering: Autentisering, håndtering av hemmeligheter, tilgangsstyring, logging og gjennomgang av avhengigheter krever fortsatt bevisste tekniske valg.

Studien av agentferdigheter fant dessuten tegn på AI-assistert utvikling i 72 prosent av tilfellene med hardkodede legitimasjoner. Det kan tyde på at usikre mønstre spres gjennom generert eller raskt sammenstilt kode. 4

Sikkerhetstiltak studiene peker mot

Funnene støtter et grunnleggende sikkerhetsnivå for team som utvikler AI-produkter eller distribuerer agentferdigheter:

1. Hold langsiktige leverandørnøkler borte fra klientenheter og modellkontekster. Send sensitive modellforespørsler via en autentisert server i stedet.
2. Bruk kortlivede legitimasjoner med snevert omfang. Følg prinsippet om minste privilegium, og valider poletter i stedet for å anta at et token alene er nok til å gi tilgang.
3. Fjern hemmeligheter fra logger og standardutdata. Alt som sendes inn i en agents kontekst, bør behandles som noe modellen eller brukeren potensielt kan hente ut igjen.
4. Skann kode, konfigurasjon, prompt-instruksjoner og avhengigheter etter hemmeligheter. Funnene fra agentstudien viser hvorfor naturlig språk og kjørbar kode må vurderes samlet.
5. Test nettverkstrafikk og autorisering på backend. Kontroller at en oppfanget forespørsel ikke kan spilles av på nytt eller sendes gjennom en proxy uten autentisering.
6. Bytt ut eksponerte legitimasjoner, og sjekk forgreninger og kopier. Å fjerne en hemmelighet fra originalarkivet betyr ikke at alle distribuerte versjoner er ryddet opp.
7. Innfør kontroll før distribusjon. Gjennomgang av markedsplasser, tydelig veiledning til utviklere, ansvarlig varsling og automatiserte kontroller kan utfylle utviklernes egen årvåkenhet. 34

Hovedlærdommen er enkel: AI-sikkerhet kan ikke legges på i etterkant, når produktet allerede er lansert. Legitimasjoner, agenttillatelser, modellkontekst og kostnadskontroll må behandles som sentrale deler av produktsikkerheten fra første dag.