TL; DR
«Sikkerhetstrusler knyttet til kunstig intelligens» dekker to forskjellige ting: angrep rettet mot kunstig intelligens-systemer og angrep som bruker kunstig intelligens som våpen. De trenger forskjellige kontroller, forskjellige eiere og forskjellige bevis, og de fleste lister blander dem sammen, og det er derfor de er så vanskelige å handle ut fra. De fem første nedenfor retter seg mot din AI. De andre fem bruker AI mot din forsyningskjede.
- Trusler mot AI-systemer ligger stort sett i konfigurasjonen, ikke i modellen. Verktøyomfang, legitimasjonen en agent kjører under, en regelfil, en
.mcp/servers.jsoninngang. Ingenting av dette er tilgjengelig fra modellens endepunkt, og det er derfor red-teaming alene kommer tilbake rent. - AI-drevne angrep kommer stort sett gjennom avhengigheter, ikke gjennom perimeteret ditt. Hallusinerte pakkenavn registrert av angripere, selvpropagerende ormer ved hjelp av utviklerlegitimasjon, AI-leverandørnøkler som mål.
- Ni av de ti er spørsmål om spesifikke ting. Hvilke MCP-servere, hvilke agenter, hvilket omfang, hvilken legitimasjon, hvilken regelfil, hvilken pakke. Et policydokument svarer ikke på noen av disse spørsmålene.
- Hver av de ti deler en forutsetning. Du kan ikke forsvare en AI-ressurs du aldri har kartlagt, noe som gjør oppdagelse til et steg før kontrollene snarere enn det etter.
Hva er de to typene AI-sikkerhetstrusler?
De fleste lister over AI-sikkerhetstrusler blander de to, og det er derfor de er vanskelige å handle på.
- Trusler mot AI-systemer Behandle din AI som målet. Noen manipulerer en modell, forgifter instruksjonene den følger, eller misbruker tillatelsene en agent har fått. Forsvarerens jobb er inneslutning: å redusere hva en kompromittert AI kan nå.
- AI-drevne angrep Behandle AI som angriperens instrument. Målet er din vanlige programvare: avhengigheter, legitimasjonsinformasjon, byggesystemer, utviklere. Forsvarerens jobb er å oppdage raskt, fordi angrepets økonomi har endret seg og volumet har økt.
De trenger forskjellige kontroller, forskjellige eiere og forskjellige bevis. Et team som har satt chatboten sin i red-team har ikke gjort noe med slopsquatting. Et team med utmerket avhengighetsscreening kan fortsatt kjøre en agent med skrivetilgang til produksjonsdatabaser og ingen omfangsgrense. Begge er AI-sikkerhetstrusler. Ingen av dem dekker den andre.
Trusler mot AI-systemer: de fem som rammer oftest
01. Rask injeksjon som når en verktøyvask
Uklarert innhold ankommer, blir sammenkoblet til en systemledetekst, og agenten i den andre enden kan aktivere verktøy. Ledeteksten er ikke sårbarheten. Veien fra uklarert inndata til en farlig funksjon er det.
Dette er grunnen til at rask filtrering alene skuffer. Det forsterker den ene enden av en kjede, mens det interessante spørsmålet er om et rekkverk befinner seg noe sted mellom input og verktøykallet. OWASP Topp 10 for LLM-applikasjoner holder rask injeksjon øverst på listen, men kombinerer det med overdreven handlefrihet av nettopp denne grunnen.
Hva skal du se etter: uklarert inndata som når en systemledetekst, henting av matingskontekst uten sanering og tilgjengelige verktøyvasker uten rekkverk imellom.
02. Ondsinnede regler og ferdighetsfiler
En regelfil er ren tekst. Den er committed som dokumentasjon og gjennomgått som dokumentasjon, og den instruerer assistenten om hva han skal gjøre. Tegn med nullbredde gjør linjer usynlige i en pull request diff samtidig som den forblir perfekt lesbar for agenten.
GJÆR ATLAS katalogiserer dette som Rules File Backdoor, casestudie AML.CS0041. Granskeren godkjenner en formateringskonvensjon. Agenten leser en instruksjon om å importere fra en angriperkontrollert pakke og ikke si noe om det.
Hva skal du se etter: regelfiler, ferdighetsfiler og ledetekstmaler analysert som kode i stedet for prosa, med gjenkjenning av usynlige tegn.
03. Usikker MCP-serverkonfigurasjon
MCP-konfigurasjon er der en agent tar imot ordrene sine og der legitimasjon samler seg. Begge halvdelene er et problem. CVE-2025-6514, som ble avslørt i juli 2025, var en kritisk OS-kommandoinjeksjon i en mye brukt MCP-bro, med en CVSS-poengsum på 9.6 og tillot vilkårlige kommandoer på klientverten når man koblet til en ikke-klarert server.
Den delen av legitimasjonsdelen er verre fordi den er passiv. Forskning i 2026 fant mer enn 24 000 hemmeligheter i MCP-konfigurasjonsfiler på den offentlige GitHub, hvorav over 2,000 fortsatt er gyldige.
Hva skal du se etter: en oversikt over MCP-servere i bruk, versjonene deres, deklarerte verktøyene deres og hemmelighetsdeteksjon som kjører over konfigurasjonsfiler.
04. Overdreven handlefrihet
En agent som får bredt verktøyomfang og en langvarig legitimasjon er en stående privilegiumsøkning som venter på en utløser. Ingenting trenger å utnyttes for at dette skal skade. En forvirret agent og en kompromittert agent gjør lignende skade når begge har skrivetilgang de aldri trengte.
Dette er det minst glamorøse elementet på listen og det vanligste. Det har også den billigste løsningen, som er reduksjon av omfang, og løsningen brukes sjelden fordi ingen eier spørsmålet.
Hva skal du se etter: hvilke agenter finnes, hva hver av dem kan påberope seg, under hvis legitimasjon, og om noen har godkjent dette omfanget.
05. Forgiftede modeller, datasett og AI-avhengigheter
AI-stakken er bygget på vanlige pakker og vertsbaserte artefakter. Modeller lastes ned fra offentlige huber. Datasett hentes fra hvor som helst. Begge har samme proveniensproblem som enhver avhengighet, med mindre verktøy og langt mindre gransking.
Hva skal du se etter: modeller, rammeverk og datasett behandlet som forsyningskjedekomponenter, med samme sammensetningsanalyse og samme CVE-sporing som resten av avhengighetene dine.
AI-drevne angrep: de fem som omformer forsyningskjeden din
06. Slopsquatting
Forskning presentert på USENIX Security i 2025 genererte 2.23 millioner kodeeksempler på tvers av 16 modeller og fant at 19.7 % av anbefalte pakker ikke eksisterte, noe som produserte over 205 000 unike hallusinerte navn. Rundt 43 % av disse navnene dukket opp igjen ved gjentatte kjøringer av samme ledetekst, noe som gjør dem farmable.
Angripere trenger ikke lenger å kompromittere en vedlikeholder. De registrerer navnet agenten din fant opp og venter på installasjonen. Pakken har ingen signatur og ingen veiledning, fordi den er ny og ingen har sett den før.
Hva skal du se etter: screening av skadelig programvare som fokuserer på atferd snarere enn omdømme, brukt på alle avhengigheter en agent legger til.
07. Selvformerende ormer i forsyningskjeden
Ocuco September 2025 npm-orm markerte punktet der utviklermaskiner ble leveringsmekanismen snarere enn målet. Mønsteret gjentok seg i stor skala frem til 2026. Hver kompromitterte utviklerlegitimasjon publiserer neste runde med kompromitterte pakker, og eksplosjonsradiusen kombineres i stedet for å legges til.
Hva skal du se etter: uvanlig publiseringsaktivitet commit mønstre og bruk av legitimasjon som ikke samsvarer med utviklerens normale oppførsel.
08. Nasjonal målretting av AI-legitimasjon
I mars 2026 ble en pakke med omtrent 100 millioner ukentlige nedlastinger kompromittert i en periode målt i timer, med AI-leverandørens API-nøkler som mål. Vinduet var bevisst kort. Langt nok til å høste, kort nok til å redusere sjansen for oppdagelse.
AI-legitimasjon er nå et førsteklasses mål i seg selv, fordi den kjøper databehandling, tilgang og en troverdig identitet. Angrep som hadde som mål å stjele den økte kraftig mellom slutten av 2025 og begynnelsen av 2026.
Hva skal du se etter: AI-leverandørnøkler behandles som hemmeligheter med samme deteksjon og tilbakekalling som skylegitimasjon.
09. Skadelig programvare forfattet eller plantet ved hjelp av en LLM
Innen 2026 var det dokumenterte tilfeller av en språkmodell som ble utnyttet til å plante ondsinnet kode i en agentarbeidsflyt. Betydningen er ikke at skadevaren var ny. Det er at forfatterskap sluttet å være en flaskehals, og volumet av plausibelt utseende ondsinnet kode tilgjengelig for en angriper økte tilsvarende.
Hva skal du se etter: deteksjon det avhenger ikke av å ha sett prøven før.
10. Gjennomgå kapasitetskollaps
Dette er ikke et angrep, og det er derfor det er det siste og det viktigste. Når en agent produserer tusen filer i løpet av en uke, slutter kodegjennomgang å være en kontroll og blir til en kø. Alle andre trusler på denne listen blir enklere når den siste menneskelige kontrollen er overveldet.
Hva skal du se etter: funn rangert etter utnyttbarhet snarere enn rå alvorlighetsgrad, slik at det lille antallet som truer produksjonen faktisk når en utvikler.
Ti trusler er kartet. Det tar lengre tid enn et blogginnlegg å gjøre hva man skal gjøre med hver enkelt, så vi hadde en skikkelig samtale. I denne episoden av SafeDev-samtalerJesús Cuadrado, administrerende direktør i Xygeni, setter seg ned med Atanas Nikolov, DevSecOps-ekspert og SSDLC teknologileder, om polymorf skadelig programvare, umiddelbar injeksjon, modellmanipulering og hva som faktisk holder stand mot dem. Ingen skjema, ingen port.
Hvorfor kan dere ikke forsvare AI-ressurser dere ikke har kartlagt?
Les de ti igjen, og mønsteret er vanskelig å overse. Ni av dem er spørsmål om spesifikke ting: hvilke MCP-servere, hvilke agenter, hvilket omfang, hvilken legitimasjon, hvilken regelfil, hvilken pakke.
Ingen av disse spørsmålene kan besvares fra et policydokument. De besvares fra en oversikt, og de fleste organisasjoner har ikke en. AI-en kom gjennom utviklere som handlet raskt, uten en sak, en anskaffelsesprosess eller en oppføring i arkivet som annonserte seg selv som AI.
Det gjør kartlegging til en forutsetning snarere enn det første trinnet. Et AI-sikkerhetstrusselprogram som starter med kontroller, vil anvende dem på AI-en den kjenner til, som er et delsett den ikke kan dimensjonere. Oppdagelse må komme først: modeller, rammeverk, datasett, slutningspunkter, agenter, MCP-servere, ferdigheter, ledetekster og AI-kodingsverktøyene utviklerne dine faktisk bruker, med forholdet mellom dem, fordi en ressurs isolert sett forteller deg svært lite, og risikoen konsentreres i kjeden.
Ocuco NIST AI Risk Management Framework setter kart før mål og administrere av samme grunn. Det er den minst interessante funksjonen i rammeverket og den alt annet er avhengig av.
Hvilke AI-sikkerhetstrusler bør du handle mot først?
Ikke den mest sofistikerte. Den mest tilgjengelige.
- Denne uka: Tell MCP-serverne dine og kjør hemmelighetsdeteksjon over konfigurasjonsfilene deres. Trussel 03 har det høyeste forholdet mellom eksponering og innsats på listen, og nesten ingen har sett på det.
- Denne måneden: Finn agentene dine og skriv ned hva hver enkelt kan påkalle og under hvem sin legitimasjon. Det adresserer trussel 04, som er den vanligste og billigste å redusere.
- Dette kvartalet: plasser atferdsbasert skadelig programvarescreening foran alle avhengigheter en agent legger til. Det dekker trusler 06, 07 og 09 samtidig, fordi alle tre overvinner omdømmebaserte kontroller ved å være nye.
Alt annet kan vente bak disse tre, fordi alt annet forutsetter at du allerede vet hva du har.
Organisasjonene som håndterer AI-sikkerhetstrusler godt i 2027 vil ikke være de med de beste modellvurderingene. Det vil være de som på en gitt tirsdag kan svare på hva AI kjører i programvaren deres og hva den har lov til å nå. Det er posisjonen. Xygeni ble bygget rundt: kontinuerlig oppdagelse av alle AI-ressurser på tvers av databaser og pipelines, risikoscoret mot rammeverkene revisorene dine allerede kjenner igjen, og screeningen av forsyningskjeden som fanger opp det som ennå ikke har noen signatur.
Ti trusler, to kategorier, ett kart under begge.
FAQ
Er AI-sikkerhetstrusler virkelig forskjellige fra vanlige applikasjonssikkerhetstrusler?
Delvis. Konsekvensene er kjente: kodekjøring, tyveri av legitimasjon, dataeksponering. Det som endres er inngangspunktet og hastigheten. Konfigurasjonsfiler som tidligere var inaktive, inneholder nå instruksjoner som noe reagerer på, og en angripers kostnad for å produsere overbevisende ondsinnet kode har sunket. Dine eksisterende kontroller gjelder fortsatt; de dekker bare ikke lenger hele overflaten.
Løser det å sette modellene våre i red teams de fleste av disse truslene?
Den tar for seg deler av en av dem. Red-teaming svarer på om en modell kan overtales til noe den bør avvise, noe som er genuint nyttig. Den kan ikke se verktøyomfanget, legitimasjonen, regelfilen eller MCP-konfigurasjonen, fordi ingen av disse er tilgjengelige via modellens endepunkt. En ren red-team-rapport og en farlig overprivilegert agent sameksisterer uten motsigelser.
Hvilken av disse AI-sikkerhetstruslene er mest undervurdert?
Overdreven handlefrihet, med god margin. Den har ingen CVE, ingen utnyttelse å demonstrere, og ingen leverandør som selger et dedikert produkt for den, så den genererer ingen hastverk. Det er også forskjellen mellom en innesluttet hendelse og en ikke-innesluttet hendelse, fordi omfanget er det som avgjør hvor langt noe beveger seg etter den første feilen.
Hvordan endrer AI-drevne angrep hva vi bør måle?
De endrer den nyttige målingen fra alvorlighetsgrad til tid. Når skadelige pakker genereres raskere enn signaturer publiseres, betyr «hvor mange kritiske saker som er åpne» mindre enn «hvor raskt noe nytt blir flagget». Mål gapet mellom en avhengighet som kommer inn i kodebasen din og blir screenet, og gapet mellom et funn som blir gjort og når en utvikler som kan handle ut fra det.
