En ferdighetsfil. En regelfil. En MCP-serverkonfigurasjon. Tre linjer med ren tekst, committed som dokumentasjon, gjennomgått som dokumentasjon, og ingen av dem ser ut som kode. Og likevel kan hver enkelt stille omskrive hva AI-assistenten din er instruert til å gjøre og hva den har lov til å nå. Det er den ubehagelige sannheten bak AI-sikkerhet i 2026Bransjen brukte to år på å bekymre seg for hva AI-generert kode inneholder. Det vanskeligere problemet viste seg å være selve AI-forsyningskjeden: modellene, agentene, MCP-serverne og konfigurasjonsfilene som nå ligger ved siden av kildekoden og avhengigheter med åpen kildekode, stort sett uoppførte og ugjennomgåtte. Dette er nettopp grunnen til at sikkerhet i forsyningskjeden for AI har blitt sin egen disiplin, og hvorfor det å velge riktig AI-sikkerhetsselskap er like viktig som å velge riktig skanner.
Angrepsflaten ingen budsjetterte med
Programvare pleide å ha en håndfull steder en angriper kunne lande: koden, avhengighetene, pipelineAI har lagt til to til, og begge går direkte inn i AI-forsyningskjeden.
Modellen og agenten. Verktøyforgiftning, rask injeksjon, agentautonomi som går lenger enn noen hadde til hensikt. En skjult instruksjon i en MCP-serverbeskrivelse kan stille omdirigere det en copilot gjør, og utvikleren ser det aldri skje.
Utviklerens eget miljø. IDE-er, AI-kopiloter, MCP-servere, agent-CLI-er. Usynlig for eldre AppSec-skannere, som ikke vet hva en modell er, og usynlig for EDR, som overvåker operativsystemet og ikke aner hva en avhengighet eller et MCP-kall er.
Ingenting av dette er teoretisk. I løpet av de siste atten månedene:
- En skjult Unicode-«regelfil-bakdør» lar angripere injisere usynlige instruksjoner i konfigurasjonsfilene som Copilot og Cursor leser, og dermed stille bakdøre koden som assistenten genererte. GitHub la til en advarsel for dette i 2025.
- En kommandoinjeksjonsfeil i en populær MCP-bro (CVSS 9.6) nådde over 400 000 nedlastinger før den ble fikset, det første dokumenterte tilfellet av full ekstern kodekjøring utløst ganske enkelt ved å koble til en upålitelig MCP-server.
- En selvforplantende npm-orm gjorde utviklerne selv til leveringsmekanismen, og mønsteret gjentok seg i stor skala i de påfølgende månedene på tvers av andre økosystemer – en lærebok for sikkerhetsfeil i AI-forsyningskjeden.
- Forskere fant at en betydelig andel av pakkene som LLM-er anbefaler ikke eksisterer i det hele tatt, «slopsquatted»-navn en angriper registrerer før en ekte utvikler i det hele tatt ber modellen om å importere dem.
Googles egen forskning på å sikre forsyningskjeden for AI-programvare kommer til en lignende konklusjon fra en annen vinkel: modeller som ble funnet i omløp i 2023 og 2024 så ut til å være legitime, men inneholdt kode som kunne tømme data eller plante en bakdør etter nedlasting, og løsningen var ikke en ny verktøykategori, men snarere å anvende forsyningskjededisiplin, som proveniens og signering, på artefakter ingen hadde sporet før. Det er sikkerhetsproblemet med AI-forsyningskjeden i én setning: artefaktene er nye, men disiplinen de trenger er ikke det.
Hvorfor dine eksisterende verktøy stopper opp
SAST leser kode. SCA leser et manifest av avhengigheter. Ingen av dem vet hva en modell er, hva en MCP-server eksponerer, eller hva en ferdighetsfil instruerer en agent til å gjøre. Det er akkurat i dette gapet at angrep fra AI-æraen havner, i rommet mellom «kode vi skanner» og «AI vi i stillhet tok i bruk».
Resultatet er en kategori av skygge-AI nei CISO kan for øyeblikket svare på følgende: hvilke modeller vi kjører, hvilke agenter kan nå hva, og hvilken MCP-server noen koblet seg til forrige tirsdag uten å fortelle noen. Å svare godt på det spørsmålet er jobben til AI-forsyningskjedesikkerhet, og det er grunnen til at generiske AppSec-verktøy stadig svikter her.
Hva AI-sikkerhet egentlig betyr
Xygeni er AI-sikkerhetsselskapet som behandler dette som tre sammenkoblede bevegelser på tvers av SDLC: oppdag, avslør og håndhev.
Oppdag: Finn ut hvilken AI du faktisk har
Kontinuerlig, automatisk oppdagelse på tvers av databasene dine avdekker alle AI-ressurser: modeller, rammeverk, datasett, slutningspunkter, agenter, MCP-servere, ferdigheter, ledetekster, guardrails, og AI-kodingsverktøyene utviklerne dine faktisk bruker. Ingen spørreundersøkelser. Ingen egenrapportering. Hvis det etterlot et spor i et arkiv, vises det i inventaret, det første og mest grunnleggende kravet til ekte AI-forsyningskjedesikkerhet.
AI-grafen kartlegger deretter hvordan disse ressursene kobles sammen: hvilken modell et datasett mater, hvilken agent aktiverer hvilket verktøy, hvilken MCP-server som sitter bak hvilken assistent. Et ressurs alene forteller deg lite. Grafen viser deg hvor risikoen konsentreres.
Fra den samme oppdagelsen genererer Xygeni en AI-BOMEn revisjonsklar, maskinlesbar oversikt over alt AI-relatert i programvaren din. Når en regulator, en revisor eller en kunde spør hvilken AI du kjører, blir svaret en nedlasting i stedet for et tre ukers kaos.
Oppdag: risikoene konvensjonelle skannere ikke kan se
En dedikert AI-skanner ser etter feilmoduser som er spesifikke for AI-systemer: umiddelbar injeksjon, verktøyinjeksjon og uklarert verktøypåkalling, datalekkasje gjennom henting, omgåelse av systemledetekster og overdreven handlefrihet. Hvert funn er knyttet til OWASP Topp 10 for LLM-applikasjoner og peker på den nøyaktige filen og linjen som oppretter eksponeringen, ikke et vagt «gjennomgå AI-bruken din»-varsel.
Det samme deteksjonslaget behandler ferdighetsfiler, regelfiler og MCP-konfigurasjoner som de sikkerhetsartefaktene de er, ikke som ufarlig dokumentasjon. Det flagger ondsinnede eller forgiftede ferdigheter, inspiserer MCP-serverkonfigurasjoner for verktøyforgiftning og avdekker ledetekstene som faktisk driver AI-arbeidsbelastningene dine.
Prioriter: trakten som kutter støy, ikke hjørner
Alle funn filtreres gradvis: ned til hva som er tilgjengelig i applikasjonskoden, deretter til hva som virkelig kan utnyttes, og deretter til hva som finnes i koden teamet ditt aktivt utvikler. Det som havner i utviklerkøen er den korte listen som faktisk truer produksjonen, med rammeverksreferansen, eksponeringsvinduet og veiledning for tiltak knyttet til.
Håndhev: stopp det før det kjører
Shield bringer håndheving av retningslinjer til utviklerens eget endepunkt: den blokkerer uautoriserte og ondsinnede installasjoner, ikke-godkjente modeller og usanksjonerte MCP-servere før noe kjøres. Under den ligger Xygenis Tidlig varsling om skadelig programvare (MEW), som fanger opp ondsinnede pakker før en signatur finnes, er lagets omdømmebaserte verktøy fortsatt tillitsfulle fordi ingen har rapportert pakken ennå. Det er håndhevingsdelen av AI-forsyningskjedesikkerhet: oppdagelse og deteksjon forteller deg hva som er galt, Shield er det som faktisk stopper det.
Din KI-eksponering ligger ikke bare i KI-koden din
Et komplett sikkerhetsbilde av AI-forsyningskjeden trenger mer enn en modellbeholdning, og det er sjelden bare de prangende tingene:
- AI-leverandørlegitimasjon etterlatt i promptfiler, agentkonfigurasjoner eller pipeline Logger er hemmeligheter som alle andre, og Xygenis hemmelighetsdeteksjon fanger dem opp før de når et offentlig register.
- Sårbare avhengigheter innen kunstig intelligens og maskinlæring bære vanlige CVE-er, som dukker opp gjennom den samme programvaresammensetningsanalysen som allerede dekker resten av stacken din. Tredjepartsforskning på AI-adopsjon har pekt på hvor mye av den moderne AI-stakken som er eksternt hentede pakker og skjulte komponenter, noe som er akkurat det overflaten programvaresammensetningsanalysen ble bygget for å dekke.
- Ondsinnede pakker publisert raskere enn noen veiledning pipeline kan katalogisere dem som fanges opp før signering, den samme MEW-funksjonen som beskytter resten av forsyningskjeden.
Agentlaget: DevAI og CoreAI
Oppdagelse og deteksjon dekker det som allerede finnes i databasene dine. DevAI fungerer der risikoen oppstår: inne i IDE-en, som et kontinuerlig, proaktivt lag som skanner menneskelig og AI-generert kode mens den skrives, uten behov for ledetekster. Den forklarer hele utnyttelsesstien bak et funn og foreslår MCP-validerte rettelser som en utvikler kan bruke med trygghet, uten å ødelegge bygget.
KjerneAI sitter over de individuelle skannerne som intelligenslaget: det korrelerer kode, avhengighet, pipeline, og samler data i én risikomodell, svarer på spørsmål i naturlig språk og produserer den ledelsesklare rapporteringen en sikkerhetsleder trenger for å vise at styring faktisk skjer, ikke bare påstås.
Utvid det du har innen AI-sikkerhet. Ikke riv noe ut
Den vanligste innvendingen mot en ny sikkerhetskategori er «vi har allerede nok verktøy». Som et AI-sikkerhetsselskap ber ikke Xygeni deg om å erstatte noe: den samme sorteringen, forklaringen og prioriteringen som brukes på deres egne funn, gjelder også for funn fra dine eksisterende SAST, SCA, og tredjepartsskannere. Din nåværende stabel blir en input, ikke et offer, og sikkerhetstilstanden i AI-forsyningskjeden din forbedres uten et rip-and-erstatt-prosjekt knyttet til den.
Hvorfor dette er viktig nå, ikke senere
Regulatorer konvergerer rundt den samme forventningen fra forskjellige kanter: EUs AI-lov, NIS2 og Spanias ENS presser alle på for lagerbeholdning og sporbarhet for AI-systemer, den samme bevisen en AI-BOM er bygget for å produsere. Retningen er klar selv der de nøyaktige samsvarsmekanismene fortsatt er i ferd med å avgjøres: du kan ikke bekrefte AI du aldri har lagerbeholdning på, og du kan ikke hevde sikkerhet i AI-forsyningskjeden hvis selve forsyningskjeden er usynlig for deg.
Velge et AI-sikkerhetsselskap
Ikke alle AI-sikkerhetsselskaper setter grensen sin på samme sted. Noen stopper ved å skanne din egen AI-genererte kode. Andre stopper ved endepunktet. Sikkerhetsspørsmålet rundt AI-forsyningskjeden er større enn hver av delene alene: det spenner over modellen, agenten, MCP-serveren, ferdighetsfilen og den vanlige avhengigheten som ligger under alt. Denne fulle livssyklusvisningen, fra oppdagelse til håndheving, i én konsoll med resten av AppSec-funnene dine, er det du bør se etter når du evaluerer et AI-sikkerhetsselskap i stedet for et enkeltpunktsverktøy.
Filene ingen gjennomgår ble veien inn. AI-sikkerhet er disiplinen med å gjennomgå dem, og AI-forsyningskjedesikkerhet er det som gjør at denne disiplinen holder ende til ende, på den samme plattformen der du allerede gjennomgår alt annet.
Se hva AI-en din faktisk har lov til å gjøre. Start gratis or planlegg en demonstrasjon.
FAQ
Forlater Xygenis kode noen gang infrastrukturen min?
Nei. Skanninger kjører i ditt eget miljø, og kildekoden lastes aldri opp til Xygenis servere. AI-inventaret og AI-BOM er bygget fra det skanneren ser lokalt, ikke fra en kopi sendt eksternt.
Hva er forskjellen mellom AI-sikkerhet, DevAI og CoreAI?
AI-sikkerhet oppdager og detekterer: den bygger AI-inventaret, AI-BOM, og finner risikoer som umiddelbar injeksjon eller forgiftede ferdighetsfiler. DevAI fungerer inne i IDE-et mens utviklere skriver kode og foreslår rettelser underveis. CoreAI ligger over begge deler, korrelerer funn på tvers av hele plattformen og svarer på spørsmål om sikkerhetsstatusen din på naturlig språk.
Hvilke AI-sikkerhetsrammeverk samsvarer Xygeni med?
Funnene samsvarer med OWASP Topp 10 for LLM-søknader, OWASP Topp 10 for MCP og OWASP Topp 10 for agentiske ferdigheter, sammen med NIST SP 800-218A og CISA/G7-veiledning om materiallister for kunstig intelligens. Denne kartleggingen er det som gjør AI-stykklisten brukbar som samsvarsbevis i stedet for bare en inventarliste.
Vil dette flagge alle AI-biblioteker eller -modeller som risiko?
Nei. Prioriteringstrakten snevrer inn funnene til det som er tilgjengelig i applikasjonskoden, reelt utnyttbart og i aktiv utvikling, så listen en utvikler ser er kort, ikke en oversikt over alle AI-ressurser som oppdages.
