Under de senaste åren har applikationssäkerhet haft en tydlig gräns: arkivet och pipelineDet var där kontrollerna satt, där skanningarna kördes, där teamen bestämde om något skulle skickas till produktion. Allt vilade på ett antagande: en utvecklare valde explicit vilken kod och vilka beroenden som skulle läggas in i systemet.
Det antagandet håller inte längre. En växande andel av koden idag skrivs, föreslås eller installeras av en AI-agent, ofta utan att någon tittar på namnet på det som hämtas. När decisLiksom det som kommer in i koden rör sig, gör även attacken det. Den rör sig längst fram i processen: i det ögonblick då koden skapas, inuti själva assistenten och i filerna som konfigurerar den.
Detta är din AI-attackyta: varje modell, agent, MCP-server, färdighet och AI-föreslagna beroenden som nu kan introducera risker innan en människa någonsin granskar dem. Samma AI som dina utvecklare litar på är nu en del av det. Detta är inte en framtida risk. Det är ett skifte som redan har skett, och så här ser det ut i praktiken.
En våg av attacker, inte en isolerad incident
Inget av följande är en labbövningcise eller en hypotetisk. Dessa är offentliga, dokumenterade incidenter, nästan alla från det senaste året, och var och en av dem landar lite närmare själva AI-agenten:
- Augusti 2025, s1ngularity: Angripare stal en publiceringstoken från Nx, ett av de mest använda byggsystemen, och skickade skadliga versioner till npm med hjälp av AI-verktyg för att leta efter hemligheter på utvecklarnas maskiner.
- September 2025, krita/felsök: en av npms största kompromisser sett till räckvidd, 18 paket med mer än två miljarder nedladdningar per vecka, övertagna genom kapningen av ett enda underhållarkonto.
- September 2025, Shai-Hulud: en av de första dokumenterade maskarna som kunde självföröka sig via npm. Dess andra våg, i november, var mer aggressiv och kopplad till hemligheter som exponerats i fler än 25 000 arkiv.
- Oktober 2025, oanvända importer: en del av PhantomRaven-kampanjen, där AI-hallucinationer introducerade riktig skadlig kod i npm genom en slopsquatting-teknik.
- I år, ClawHub: ett förgiftat register över AI-färdigheter där fem av de sju mest nedladdade färdigheterna var skadlig programvara.
Branschen formaliserar samma slutsats. OWASP Top 10 för LLM-applikationer placerar snabb injektion som nummer ett. OWASP MCP Top 10 (för närvarande i beta) riktar in sig på de protokoll som agenter använder för att kommunicera med verktyg. OWASP Agentic Skills Top 10, ett nytt projekt i inkubatorfasen, anger skadliga färdigheter som sin största risk. OWASP rör sig vanligtvis försiktigt; att öppna tre fronter samtidigt, varav en brådskande, säger något om hur snabbt detta rör sig.
Alla tre sammanfaller kring samma idé: instruktionerna, verktygen och konfigurationerna kring en modell är nu en del av AI-attackytan, och de finns vanligtvis i ert eget repository. Vilket väcker den första frågan som är värd att ställa era team: vem granskar regelfilerna, färdigheterna och MCP-konfigurationerna som finns i ert repo?
Vektor 1: den förgiftade färdigheten
En färdighet är en fil med instruktioner och förmågor som lär en AI-agent hur man utför en uppgift. Det är inte det enda sättet att forma en agents beteende (regelfiler, hooks, och MCP-konfigurationer gör detsamma), men de delar alla en egenskap: de färdas inuti repositoriet, med koden.
Årets forskning granskade 4 000 av dessa färdigheter:
- 36 % hade minst en säkerhetsbrist.
- 13.4 % var kritiska.
- Nära 100 hade direkt skadliga nyttolaster.
Kärnförändringen: angriparen riktar sig inte längre mot din kod. De riktar sig mot agenten som skriver din kod och planterar dolda instruktioner (ibland med osynliga tecken) som modellen läser och behandlar som operativa. En mänsklig granskare godkänner pull request i god tro eftersom filen, i deras ögon, ser ren ut. Modellen tolkar instruktioner som granskaren aldrig såg.
Detta är inte teoretiskt. CVE-2025-59536 (CVSS 8.7) tillät att Claude Code startades från ett opålitligt arkiv, där en skadlig konfiguration kunde köra kommandon innan användaren accepterade förtroendedialogrutan. En andra sårbarhet, CVE-2026-21852, tillät exfiltrering av en API-nyckel genom projektstyrd konfiguration, utan att användaren godkände något.
H2: Vektor 2: slopsquatting
Namnet blandar "slop" (skräpet som en AI ibland genererar) med den klassiska typosquatting-attacken. Typosquatting beror på mänskliga fel: en angripare registrerar ett paketnamn som ligger nära ett populärt namn och väntar på ett stavfel. Det är slumpmässigt.
Slopphukning väntar inte på ett misstag. I studien som refereras till under den här sessionen, 19.7 % av paketreferenserna som genererades av AI-modeller pekade på paket som inte finns. Modeller tenderar att hallucinera samma namn upprepade gånger, så en angripare tittar på vilka namn AI:n uppfinner, registrerar dessa namn med skadlig kod och väntar på nästa AI-föreslagna installation för att hämta det till din applikation.
Skalan är inte liten: Mer än 450 000 nya skadliga paket identifierades under 2025. Två exempel gör det konkret:
- En forskare planterade ett ofarligt testpaket som hette kramandeansikte-kli för att bevisa poängen. Den loggade mer än 30 000 nedladdningar på tre månader.
- oanvända importer, från tidslinjen ovan, bekräftades vara skadlig kod, som finns i ett offentligt register, med just den här tekniken. Den där var inte ett test.
Frågan är inte om detta kan hända ditt team. Det handlar om hur många AI-föreslagna paket som matar in din kod idag utan att någon tittar på dem.
Svaret: standards kommer ikapp
Två krafter löper parallellt. Medan attackerna accelererar, standards kroppar reagerar:
- NIST SP 800-218A utökar ramverket för säker programvaruutveckling med metoder specifika för AI-modeller, inklusive bevis på integritet och proveniens.
- In Kan 2026, CISA och dess internationella G7-partner publicerade riktlinjer för en programvaruförteckning för AI, som definierar vad som hör hemma i den inventeringen: modeller, datamängder, komponenter, leverantörer och beroenden.
Riktningen är tydlig: den SBOM expanderar till en AI-BOM. Du kan inte certifiera eller intyga det du inte kan inventera. Och idag kan de flesta organisationer inte:
- 43% kan inte granska eller inventera de AI-verktyg de redan använder.
- 79% har ingen insyn i AI-agenterna och MCP-systemen som körs i deras egen miljö.
I reglerade miljöer går denna inventering från god praxis till avtalsenliga förväntningar eller efterlevnadsskyldigheter. Men en inventering visar bara vad du har. I sig själv blockerar den inte en attack.
Gapet: en EDR för AppSec
SAST och SCA Verktyg är utformade för att analysera kod och beroenden, inte en agents beteende eller dess konfiguration. EDR ser processer och nätverksanslutningar, men saknar vanligtvis applikationssäkerhetskontexten för att tolka ett beroende eller en agentkonfiguration. Mellan dessa två kategorier av verktyg finns en lucka, exakt var kod nu skapas, och exakt var AI-attackytan finns.
Det gapet har tre blinda fläckar:
- AI-tillgångar. Modeller, agenter och MCP-servrar visas inte på din SASTär eller SCAs radar. Du kan inte inventera det du inte kan se.
- Konfigurationsfiler. Färdigheter, regler och MCP-konfigurationer formar agenternas beteende men granskas vanligtvis som om de vore ofarlig vanlig text.
- Paketinstallationer. A skadligt beroende kan köras innan det är känt att det är skadligt, och sedan exfiltrera hemligheter och tokens utan att någon godkänner det.
Hur Xygeni stänger den
Vad en EDR gör för endpoints, Xygeni Shield gör det för den AI-assisterade utvecklingslivscykeln: den skyddar var kod skapas samtidigt som den förstår applikationssäkerhetskontexten.
- Sikt där SAST och SCA når inte. Xygeni flaggar skadliga färdigheter och reglerfiler, analyserar MCP-konfigurationer och bygger en granskningsklar version. AI-BOM, mappad till OWASP LLM, MCP och Agentic Skills Top 10.
- Intelligens, inte bara underskrifter. MEW (Malware Early Warning) analyserar beteendet och risken för att ett paket blockerar det innan en CVE, en rekommendation eller en offentlig signatur finns. Uppdaterad nätverksinformation avbryter anslutningar till känd skadlig infrastruktur.
- En kontrollpunkt, från kod till slutpunkt. En enda agent, driftsatt utan omstrukturering av miljön, med inbyggda bevis på europeisk datasuveränitet och efterlevnad.
I en livedemonstration blockerade denna policytillämpning en AI-agents försök att installera ett skadligt paket över tre olika installationsvägar (virtuell miljö, pakethanterare och direkt nedladdning) innan installationen var klar, allt loggat i realtid och exporterbart till en SOC. Onboarding av ett första projekt tar vanligtvis ungefär en timme; att utöka täckningen till en hel organisation tar vanligtvis en till två veckor, beroende på struktur.
FAQ
Vad är AI:s attackyta i ett stycke?
AI-attackytan är den uppsättning modeller, agenter, MCP-servrar, färdigheter, regelfiler och AI-föreslagna beroenden genom vilka risker kan komma in i en applikation, ofta innan en människa granskar den. Den sträcker sig bortom traditionell kod och beroenden och inkluderar konfigurationsfiler och instruktioner som formar hur en AI-agent beter sig.
Hur kan jag avgöra om ett paketnamn som föreslagits av min AI-assistent är en hallucination eller bara legitimt men okänt?
Validera före installation: kontrollera registret och analysera paketets faktiska innehåll och avsikt istället för att lita enbart på namnet. Xygeni automatiserar denna validering i realtid under kodgenerering, så en installation godkänns eller blockeras innan den körs, oavsett om paketet är ett du känner igen eller inte.
Påverkar slopsquatting alla AI-modeller lika?
Forskningen bakom siffran 19.7 % omfattade flera modeller och fann att problemet var brett fördelat, med endast små variationer mellan dem. Detta är ett mönster inom AI-assisterad utveckling, inte en brist som är specifik för en assistent.
Kan vi kontrollera retroaktivt om vi redan har installerat ett hallucinerat eller skadligt paket?
Ja. Xygenis plattform ger kunder tillgång till en underhållen databas med upptäckta skadliga paket, sökbara mot ert befintliga komponentlager, så att ni med ett par klick kan bekräfta om något som redan är installerat är ett känt hot.
Hur lång tid tar implementeringen för en medelstor organisation med flera team?
Onboarding av ett första projekt tar vanligtvis ungefär en timme. Att skala upp till en hel organisation tar vanligtvis en till två veckor, beroende på teamstruktur och arbetssätt.
Kartlägg din AI-attackyta, gratis
Kartlägg din applikations AI-avtryck gratis: skapa ett konto och kör en första skanning om några minuterBörja med en enda applikation, se vilken AI som finns inuti den och se vilken del av din AI-attackyta som är farlig.
*Vissa funktioner som nämns ovan tillämpas via Xygeni Shield och ASPM/AI-säkerhetsmoduler; tillgängligheten kan variera beroende på plan. Se xygeni.io för aktuell produktinformation.
