I løpet av de siste årene har applikasjonssikkerhet hatt en klar grense: depotet og pipelineDet var der kontrollene satt, der skanningene kjørte, der teamene bestemte om noe skulle sendes til produksjon. Alt hvilte på én antagelse: en utvikler valgte eksplisitt hvilken kode og hvilke avhengigheter som skulle legges inn i systemet.
Den antagelsen holder ikke lenger. En økende andel av kode i dag skrives, foreslås eller installeres av en AI-agent, ofte uten at noen ser på navnet på det som hentes inn. Når decisSelv om det som kommer inn i koden beveger seg, gjør angrepet det også. Det beveger seg helt til forkant av prosessen: i det øyeblikket koden opprettes, inne i selve assistenten og i filene som konfigurerer den.
Dette er din AI-angrepsflate: hver modell, agent, MCP-server, ferdighet og AI-foreslått avhengighet som nå kan introdusere risiko før et menneske i det hele tatt vurderer den. Den samme AI-en som utviklerne dine stoler på er nå en del av det. Dette er ikke en fremtidig risiko. Det er et skifte som allerede har skjedd, og slik ser det ut i praksis.
En bølge av angrep, ikke en isolert hendelse
Ingen av de følgende er en laboratorieøvelsecise eller en hypotetisk. Dette er offentlige, dokumenterte hendelser, nesten alle fra det siste året, og hver av dem lander litt nærmere selve AI-agenten:
- August 2025, s1ngularitet: Angripere stjal et publiseringstoken fra Nx, et av de mest brukte byggesystemene, og sendte skadelige versjoner til npm ved hjelp av AI-verktøy for å jakte på hemmeligheter på utviklernes maskiner.
- September 2025, kritt/feilsøking: et av npms største kompromisser etter rekkevidde, 18 pakker med mer enn to milliarder ukentlige nedlastinger, overtatt gjennom kapring av en enkelt vedlikeholders konto.
- September 2025, Shai-Hulud: en av de første dokumenterte ormene som var i stand til å formere seg selv via npm. Den andre bølgen, i november, var mer aggressiv og knyttet til hemmeligheter eksponert på tvers av mer enn 25 000 databaser.
- Oktober 2025, ubrukt import: en del av PhantomRaven-kampanjen, der AI-hallusinasjoner introduserte ekte skadelig programvare i npm gjennom en slopquatting-teknikk.
- I år, ClawHub: et forgiftet register over AI-ferdigheter der fem av de syv mest nedlastede ferdighetene var skadelig programvare.
Bransjen formaliserer den samme konklusjonen. OWASP Top 10 for LLM-applikasjoner setter rask injeksjon som nummer én. OWASP MCP Top 10 (for tiden i beta) retter seg mot protokollen som agenter bruker for å kommunisere med verktøy. OWASP Agentic Skills Top 10, et nytt prosjekt i inkubatorfasen, nevner ondsinnede ferdigheter som sin største risiko. OWASP beveger seg vanligvis forsiktig; å åpne tre fronter samtidig, én av dem raskt, sier noe om hvor raskt dette beveger seg.
Alle tre konvergerer om den samme ideen: instruksjonene, verktøyene og konfigurasjonene rundt en modell er nå en del av AI-angrepsflaten, og de ligger vanligvis i ditt eget repository. Noe som reiser det første spørsmålet som er verdt å stille teamene dine: hvem gjennomgår regelfilene, ferdighetene og MCP-konfigurasjonene som ligger i repositoryet ditt?
Vektor 1: den forgiftede ferdigheten
En ferdighet er en fil med instruksjoner og evner som lærer en AI-agent hvordan man utfører en oppgave. Det er ikke den eneste måten å forme en agents oppførsel på (regelfiler, hooks, og MCP-konfigurasjoner gjør det samme), men de deler alle én egenskap: de beveger seg inne i depotet, med koden.
Årets forskning gjennomgikk 4,000 av disse ferdighetene:
- 36 % hadde minst én sikkerhetsfeil.
- 13.4 % var kritiske.
- Nesten 100 hadde direkte skadelige nyttelaster.
Kjerneskiftet: angriperen retter seg ikke lenger mot koden din. De retter seg mot agenten som skriver koden din, og planter skjulte instruksjoner (noen ganger med usynlige tegn) som modellen leser og behandler som operative. En menneskelig gransker godkjenner pull request i god tro fordi filen ser ren ut i deres øyne. Modellen tolker instruksjoner som anmelderen aldri så.
Dette er ikke teoretisk. CVE-2025-59536 (CVSS 8.7) tillot oppstart av Claude Code fra et ikke-klarert arkiv, der en ondsinnet konfigurasjon kunne kjøre kommandoer før brukeren godtok tillitsdialogen. En annen sårbarhet, CVE-2026-21852, tillot uttak av en API-nøkkel gjennom prosjektstyrt konfigurasjon, uten at brukeren godkjente noe.
H2: Vektor 2: slopsquatting
Navnet blander «slop» (søppelet en AI noen ganger genererer) med det klassiske typosquatting-angrepet. Typosquatting avhenger av menneskelige feil: en angriper registrerer et pakkenavn som er nært et populært navn og venter på en skrivefeil. Det er tilfeldig.
Slapshuting venter ikke på en feil. I studien som det refereres til i denne økten, 19.7 % av pakkereferansene generert av AI-modeller pekte på pakker som ikke finnes. Modeller har en tendens til å hallusinere de samme navnene gjentatte ganger, så en angriper ser på hvilke navn AI-en finner opp, registrerer disse navnene med ondsinnet kode og venter på at den neste AI-foreslåtte installasjonen skal hente den inn i applikasjonen din.
Skalaen er ikke liten: Mer enn 450 000 nye ondsinnede pakker ble identifisert i 2025. To eksempler gjør det konkret:
- En forsker plantet en ufarlig testpakke kalt klemmeansikt-kli for å bevise poenget. Den logget mer enn 30 000 nedlastinger på tre måneder.
- ubrukte importer, fra tidslinjen ovenfor, ble bekreftet skadelig programvare, lagret i et offentlig register, ved bruk av akkurat denne teknikken. Den var ikke en test.
Spørsmålet er ikke om dette kan skje med teamet ditt. Det handler om hvor mange AI-foreslåtte pakker som legger inn koden din i dag uten at noen ser på dem.
Svaret: standards tar igjen
To krefter løper parallelt. Mens angrepene akselererer, standardkroppene reagerer:
- NIST SP 800-218A utvider rammeverket for sikker programvareutvikling med praksiser spesifikke for AI-modeller, inkludert bevis på integritet og opprinnelse.
- In May 2026, CISA og dens internasjonale G7-partnere publisert veiledning om en programvareliste for AI, som definerer hva som hører hjemme i denne beholdningen: modeller, datasett, komponenter, leverandører og avhengigheter.
Retningen er klar: den SBOM utvider seg til en AI-BOM. Du kan ikke bekrefte eller bekrefte noe du ikke kan føre opp i en inventarliste. Og i dag kan ikke de fleste organisasjoner:
- 43% kan ikke revidere eller lagerføre lagerstatus for AI-verktøyene de allerede bruker.
- 79% har ingen innsikt i AI-agentene og MCP-systemene som kjører i deres eget miljø.
I regulerte miljøer går denne oversikten fra god praksis til kontraktsmessig forventning eller samsvarsforpliktelse. Men en oversikt forteller deg bare hva du har. Den blokkerer ikke et angrep i seg selv.
Gapet: en EDR for AppSec
SAST og SCA Verktøy er utformet for å analysere kode og avhengigheter, ikke oppførselen til en agent eller dens konfigurasjon. En EDR ser prosesser og nettverkstilkoblinger, men mangler vanligvis applikasjonssikkerhetskonteksten for å tolke en avhengighet eller en agentkonfigurasjon. Mellom disse to kategoriene av verktøy ligger det et gap, nøyaktig hvor kode nå lages, og nøyaktig hvor AI-angrepsflaten befinner seg.
Det gapet har tre blinde flekker:
- AI-ressurser. Modeller, agenter og MCP-servere vises ikke på din SASTer eller SCAs radar. Du kan ikke lage en inventar av det du ikke kan se.
- Konfigurasjonsfiler. Ferdigheter, regler og MCP-konfigurasjoner former agentens oppførsel, men blir vanligvis gjennomgått som om de var harmløs ren tekst.
- Pakkeinstallasjoner. A en ondsinnet avhengighet kan kjøres før det er kjent at den er ondsinnet, og deretter eksfiltrere hemmeligheter og tokens uten at noen godkjenner det.
Hvordan Xygeni lukker den
Hva en EDR gjør for endepunkter, Xygeni Shield gjør det for den AI-assisterte utviklingslivssyklusen: den beskytter der kode opprettes, samtidig som den forstår konteksten for applikasjonssikkerhet.
- Sikt der SAST og SCA ikke nå frem. Xygeni flagger skadelige ferdighets- og regelfiler, analyserer MCP-konfigurasjoner og bygger en revisjonsklar løsning. AI-BOM, tilordnet OWASP LLM-, MCP- og Agentic Skills Topp 10-listene.
- Etterretning, ikke bare signaturer. MEW (Malware Early Warning) analyserer oppførselen og risikoen til en pakke for å blokkere den før en CVE, en veiledning eller en offentlig signatur finnes. Oppdatert nettverksintelligens kutter forbindelser til kjent skadelig infrastruktur.
- Ett kontrollpunkt, fra kode til endepunkt. Én enkelt agent, distribuert uten omstrukturering av miljøet, med innebygd dokumentasjon på europeisk datasuverenitet og samsvar.
I en demonstrasjon i sanntid blokkerte denne håndhevingen av retningslinjer en AI-agents forsøk på å installere en skadelig pakke på tvers av tre forskjellige installasjonsbaner (virtuelt miljø, pakkebehandler og direkte nedlasting) før installasjonen var fullført, alt logget i sanntid og eksporterbart til en SOC. Onboarding av et første prosjekt tar vanligvis omtrent en time; å utvide dekningen til en hel organisasjon tar vanligvis én til to uker, avhengig av strukturen.
FAQ
Hva er AI-angrepsflaten i ett avsnitt?
AI-angrepsflaten er settet med modeller, agenter, MCP-servere, ferdigheter, regelfiler og AI-foreslåtte avhengigheter som risiko kan komme inn i et program gjennom, ofte før et menneske gjennomgår det. Den strekker seg utover tradisjonell kode og avhengigheter til å inkludere konfigurasjonsfiler og instruksjoner som former hvordan en AI-agent oppfører seg.
Hvordan kan jeg vite om et pakkenavn foreslått av AI-assistenten min er en hallusinasjon eller bare legitimt, men ukjent?
Valider før installasjon: sjekk registeret og analyser pakkens faktiske innhold og hensikt i stedet for å stole bare på navnet. Xygeni automatiserer denne valideringen i sanntid under kodegenerering, slik at en installasjon godkjennes eller blokkeres før den kjører, enten det er en pakken du gjenkjenner eller ikke.
Påvirker slopsquatting alle AI-modeller likt?
Forskningen bak tallet 19.7 % dekket flere modeller og fant problemet bredt fordelt, med bare små variasjoner mellom dem. Dette er et mønster på tvers av AI-assistert utvikling, ikke en feil som er spesifikk for én assistent.
Kan vi sjekke med tilbakevirkende kraft om vi allerede har installert en hallusinert eller ondsinnet pakke?
Ja. Xygenis plattform gir kundene tilgang til en vedlikeholdt database med oppdagede skadelige pakker, som kan søkes mot din eksisterende komponentbeholdning, slik at du kan bekrefte med et par klikk om noe som allerede er installert er en kjent trussel.
Hvor lang tid tar implementeringen for en mellomstor organisasjon med flere team?
Onboarding av et første prosjekt tar vanligvis omtrent en time. Skalering på tvers av en hel organisasjon tar vanligvis én til to uker, avhengig av teamstruktur og arbeidsmåter.
Kartlegg din AI-angrepsflate, gratis
Kartlegg applikasjonens AI-avtrykk gratis: opprett en konto og kjør en første skanning om minutterStart med én enkelt applikasjon, se hvilken AI som er inni den, og se hvilken del av AI-angrepsflaten din som er farlig.
*Noen av funksjonene som er referert til ovenfor håndheves gjennom Xygeni Shield og ASPM/AI-sikkerhetsmoduler; tilgjengeligheten kan variere avhengig av plan. Se xygeni.io for aktuelle produktdetaljer.
