En færdighedsfil. En regelfil. En MCP-serverkonfiguration. Tre linjer almindelig tekst, committed som dokumentation, gennemgået som dokumentation, og ingen af dem ligner kode. Og alligevel kan hver enkelt stille og roligt omskrive, hvad din AI-assistent er blevet instrueret i at gøre, og hvad den har tilladelse til at nå. Det er den ubehagelige sandhed bag AI-sikkerhed. i 2026Branchen brugte to år på at bekymre sig om, hvad AI-genereret kode indeholder. Det sværere problem viste sig at være selve AI-forsyningskæden: modellerne, agenterne, MCP-serverne og konfigurationsfilerne, der nu ligger sammen med kildekoden og open source-afhængigheder, stort set uopgjorte og uigennemgåede. Det er netop derfor, at AI-forsyningskædesikkerhed er blevet sin egen disciplin, og hvorfor det er lige så vigtigt at vælge det rigtige AI-sikkerhedsfirma som at vælge den rigtige scanner.
Angrebsfladen, som ingen havde budgetteret med
Software havde tidligere en håndfuld steder, hvor en angriber kunne lande: koden, afhængighederne, pipelineAI har tilføjet to mere, og begge indgår direkte i AI-forsyningskæden.
Modellen og agenten. Værktøjsforgiftning, hurtig indsprøjtning, agentautonomi, der går længere end nogen havde til hensigt. En skjult instruktion i en MCP-serverbeskrivelse kan stille og roligt omdirigere, hvad en copilot gør, og udvikleren ser det aldrig ske.
Udviklerens eget miljø. IDE'er, AI-copiloter, MCP-servere, agent-CLI'er. Usynlig for ældre AppSec-scannere, som ikke ved, hvad en model er, og usynlig for EDR, som overvåger operativsystemet og ikke aner, hvad en afhængighed eller et MCP-kald er.
Intet af dette er teoretisk. I de sidste atten måneder:
- En skjult Unicode-"regelfilbagdør" lod angribere indsprøjte usynlige instruktioner i de konfigurationsfiler, som Copilot og Cursor læser, og dermed stille og roligt bagdøre den kode, som assistenten genererede. GitHub tilføjede en advarsel om det i 2025.
- En kommandoinjektionsfejl i en populær MCP-bro (CVSS 9.6) nåede over 400,000 downloads, før den blev rettet. Det var det første dokumenterede tilfælde af fuld fjernudførelse af kode, der blev udløst blot ved at oprette forbindelse til en MCP-server, der ikke var tillid til.
- En selvspredende npm-orm gjorde udviklerne selv til leveringsmekanismen, og mønsteret gentog sig i stor skala i de følgende måneder på tværs af andre økosystemer – en lærebog i AI-forsyningskædens sikkerhedsfejl.
- Forskere fandt ud af, at en betydelig andel af de pakker, som LLM'er anbefaler, slet ikke findes – "slopsquatted" navne, som en angriber registrerer, før en rigtig udvikler overhovedet beder modellen om at importere dem.
Googles egen forskning i at sikre AI-softwareforsyningskæden når frem til en lignende konklusion fra en anden vinkel: modeller, der blev fundet i omløb i 2023 og 2024, så legitime ud, selvom de indeholdt kode, der kunne tømme data eller plante en bagdør, når den var downloadet, og løsningen var ikke en ny kategori af værktøj, men snarere at anvende forsyningskædedisciplin, såsom proveniens og signering, på artefakter, som ingen havde sporet før. Det er sikkerhedsproblemet med AI-forsyningskæden i én sætning: artefakterne er nye, men den disciplin, de har brug for, er ikke.
Hvorfor dine eksisterende værktøjer stopper
SAST læser kode. SCA læser et manifest af afhængigheder. Ingen af dem ved, hvad en model er, hvad en MCP-server eksponerer, eller hvad en færdighedsfil instruerer en agent i at gøre. Det er præcis i det hul, at angreb fra AI-æraen lander, i rummet mellem "kode vi scanner" og "AI vi stille og roligt adopterede".
Resultatet er en kategori af skygge-AI nej CISO kan i øjeblikket svare på følgende spørgsmål: hvilke modeller vi kører, hvilke agenter kan nå hvad, og hvilken MCP-server nogen forbandt med sidste tirsdag uden at fortælle det til nogen. At besvare det spørgsmål godt er opgaven for AI-forsyningskædesikkerhed, og det er grunden til, at generiske AppSec-værktøjer bliver ved med at komme til kort her.
Hvad AI-sikkerhed egentlig betyder
Xygeni er AI-sikkerhedsfirmaet, der behandler dette som tre forbundne bevægelser på tværs af SDLC: opdage, detektere og håndhæve.
Opdag: Find ud af, hvilken AI du rent faktisk har
Kontinuerlig, automatisk registrering på tværs af dine lagre afslører alle AI-aktiver: modeller, frameworks, datasæt, inferens-slutpunkter, agenter, MCP-servere, færdigheder, prompts, guardrailsog de AI-kodningsværktøjer, dine udviklere rent faktisk bruger. Ingen undersøgelser. Ingen selvrapportering. Hvis det efterlod et spor i et repository, vises det i inventaret, det første og mest grundlæggende krav til reel AI-forsyningskædesikkerhed.
AI-grafen kortlægger derefter, hvordan disse aktiver forbinder sig: hvilken model et datasæt bruger, hvilken agent der aktiverer hvilket værktøj, hvilken MCP-server der sidder bag hvilken assistent. Et aktiv alene siger dig ikke meget. Grafen viser dig, hvor risikoen er koncentreret.
Fra den samme opdagelse genererer Xygeni en AI-BOMEn revisionsklar, maskinlæsbar oversigt over alt AI-relateret i din software. Når en regulator, en revisor eller en kunde spørger, hvilken AI du kører, bliver svaret en download i stedet for et tre ugers kæmpebesvær.
Detect: de risici, som konventionelle scannere ikke kan se
En dedikeret AI-scanner leder efter de fejltilstande, der er specifikke for AI-systemer: prompt injektion, værktøjsinjektion og upålidelig værktøjsaktivering, datalækage gennem hentning, omgåelse af systemprompter og overdreven handlekraft. Hvert fund knytter sig til OWASP Top 10 til LLM-applikationer og peger på den præcise fil og linje, der skaber eksponeringen, ikke en vag "gennemgå din AI-brug"-advarsel.
Det samme detektionslag behandler færdighedsfiler, regelfiler og MCP-konfigurationer som de sikkerhedsartefakter, de er, ikke som harmløs dokumentation. Det markerer ondsindede eller forgiftede færdigheder, inspicerer MCP-serverkonfigurationer for værktøjsforgiftning og afslører de prompter, der rent faktisk driver dine AI-arbejdsbelastninger.
Prioriter: Tragten der skærer støj, ikke hjørner
Alle fund filtreres progressivt: ned til det, der er tilgængeligt i applikationskoden, derefter til det, der reelt kan udnyttes, og derefter til det, der findes i koden, som dit team aktivt udvikler. Det, der når en udviklers kø, er den korte liste, der rent faktisk truer produktionen, med frameworkreferencen, eksponeringsvinduet og vejledningen til afhjælpning tilknyttet.
Håndhæv: Stop det, før det kører
Shield bringer politikhåndhævelse til udviklerens eget slutpunkt: den blokerer uautoriserede og ondsindede installationer, ikke-godkendte modeller og ikke-godkendte MCP-servere, før noget udføres. Under den ligger Xygenis Tidlig advarsel om malware (MEW), som fanger ondsindede pakker, før der findes en signatur, har lagets omdømmebaserede værktøjer stadig tillid, fordi ingen har rapporteret pakken endnu. Det er håndhævelsesdelen af AI-forsyningskædesikkerhed: opdagelse og detektion fortæller dig, hvad der er galt, Shield er det, der rent faktisk stopper det.
Din eksponering for AI findes ikke kun i din AI-kode
Et komplet billede af AI-forsyningskædens sikkerhed kræver mere end en modelopgørelse, og det er sjældent kun de prangende ting:
- AI-udbyderens legitimationsoplysninger efterladt i promptfiler, agentkonfigurationer eller pipeline Logfiler er hemmeligheder som alle andre, og Xygenis hemmelighedsdetektion fanger dem, før de når et offentligt register.
- Sårbare AI- og ML-afhængigheder bære almindelige CVE'er, der er fremkommet af den samme softwaresammensætningsanalyse, som allerede dækker resten af din stak. Tredjepartsforskning om AI-adoption har peget på, hvor meget af den moderne AI-stak, der er eksternt fremskaffede pakker og skjulte komponenter, hvilket er præcis den overflade, softwaresammensætningsanalysen blev bygget til at dække.
- Ondsindede pakker offentliggøres hurtigere end nogen rådgivning pipeline kan katalogisere dem, hvis de er fanget før underskrift, den samme MEW-kapacitet beskytter resten af din forsyningskæde.
Agentlaget: DevAI og CoreAI
Opdagelse og detektion dækker det, der allerede findes i dine lagre. DevAI fungerer der, hvor risikoen skabes: inde i IDE'en, som et kontinuerligt, proaktivt lag, der scanner menneskelig og AI-genereret kode, mens den skrives, uden behov for prompts. Det forklarer den fulde udnyttelsessti bag et fund og foreslår MCP-validerede rettelser, som en udvikler kan anvende med tillid uden at ødelægge buildet.
CoreAI sidder over de individuelle scannere som intelligenslaget: det korrelerer kode, afhængighed, pipelineog samler data i én risikomodel, besvarer spørgsmål i naturligt sprog og producerer den ledelsesklare rapportering, som en sikkerhedsleder har brug for for at vise, at styring faktisk finder sted, ikke bare påstås.
Udvid det, du har inden for AI-sikkerhed. Riv ikke noget ud
Den mest almindelige indvending mod en ny sikkerhedskategori er "vi har allerede nok værktøjer." Som et AI-sikkerhedsfirma beder Xygeni dig ikke om at erstatte noget: den samme triage, forklaring og prioritering, der anvendes på dets egne fund, gælder ligeledes for fund fra dine eksisterende SAST, SCAog tredjepartsscannere. Din nuværende stak bliver et input, ikke et offer, og din AI-forsyningskædes sikkerhedstilstand forbedres uden et "rip-and-replace"-projekt knyttet til den.
Hvorfor dette er vigtigt nu, ikke senere
Regulatorer konvergerer omkring den samme forventning fra forskellige retninger: EU's AI-lov, NIS2 og Spaniens ENS arbejder alle på lagerbeholdning og sporbarhed for AI-systemer, den samme dokumentation, som en AI-BOM er bygget til at producere. Retningen er klar, selv hvor de nøjagtige compliance-mekanismer stadig er ved at blive fastlagt: Du kan ikke bekræfte AI, som du aldrig har opgjort, og du kan ikke påstå AI-forsyningskædesikkerhed, hvis selve forsyningskæden er usynlig for dig.
Valg af et AI-sikkerhedsfirma
Ikke alle AI-sikkerhedsvirksomheder trækker deres grænser på samme sted. Nogle stopper ved at scanne din egen AI-genererede kode. Andre stopper ved slutpunktet. Spørgsmålet om sikkerhed i AI-forsyningskæden er større end hver enkelt del i sig selv: det spænder over modellen, agenten, MCP-serveren, færdighedsfilen og den almindelige afhængighed, der ligger under det hele. Den fulde livscyklusvisning, fra opdagelse til håndhævelse, i én konsol med resten af dine AppSec-fund, er det, du skal kigge efter, når du evaluerer en AI-sikkerhedsvirksomhed, snarere end et enkelt punktværktøj.
De filer, som ingen gennemgår, blev vejen ind. AI-sikkerhed er disciplinen at gennemgå dem, og AI-forsyningskædesikkerhed er det, der får den disciplin til at holde fra start til slut, på den samme platform, hvor du allerede gennemgår alt andet.
Se hvad din AI rent faktisk har tilladelse til at gøre. Start gratis or planlæg en demo.
Ofte stillede spørgsmål
Forlader Xygenis kode nogensinde min infrastruktur?
Nej. Scanninger kører i dit eget miljø, og kildekoden uploades aldrig til Xygenis servere. AI-inventaret og AI-BOM'en er bygget ud fra, hvad scanneren ser lokalt, ikke ud fra en kopi sendt eksternt.
Hvad er forskellen mellem AI-sikkerhed, DevAI og CoreAI?
AI Security opdager og detekterer: det opbygger AI-inventaret, AI-BOM'en, og finder risici som prompt injection eller poisoned skill-filer. DevAI arbejder inde i IDE'et, mens udviklere skriver kode og foreslår rettelser undervejs. CoreAI sidder over begge dele, korrelerer fund på tværs af hele platformen og besvarer spørgsmål om din sikkerhedstilstand i naturligt sprog.
Hvilke AI-sikkerhedsrammer er Xygeni i overensstemmelse med?
Resultaterne sammenlignes med OWASP Top 10 for LLM-ansøgninger, OWASP Top 10 for MCP og OWASP Top 10 for agentiske færdigheder, sammen med NIST SP 800-218A og CISA/G7-vejledning om AI-materialefortegnelser. Denne kortlægning er det, der gør AI-BOM'en brugbar som dokumentation for overholdelse af regler og ikke blot en opgørelse.
Vil dette markere alle AI-biblioteker eller modeller som risiko?
Nej. Prioriteringstragten indsnævrer resultaterne til, hvad der er tilgængeligt i applikationskoden, reelt kan udnyttes, og er i aktiv udvikling, så den liste, en udvikler ser, er kort og ikke en oversigt over alle detekterede AI-aktiver.
