En färdighetsfil. En regelfil. En MCP-serverkonfiguration. Tre rader med vanlig text, committed som dokumentation, granskad som dokumentation, och ingen av dem ser ut som kod. Och ändå kan var och en i tysthet skriva om vad din AI-assistent instrueras att göra och vad den får uppnå. Det är den obekväma sanningen bakom AI-säkerhet. i 2026Branschen ägnade två år åt att oroa sig för vad AI-genererad kod innehåller. Det svårare problemet visade sig vara själva AI-leveranskedjan: modellerna, agenterna, MCP-servrarna och konfigurationsfilerna som nu ligger bredvid källkoden och öppen källkod, till stor del outforskade och oreviderade. Det är just därför AI-leveranskedjans säkerhet har blivit en egen disciplin, och varför det är lika viktigt att välja rätt AI-säkerhetsföretag som att välja rätt skanner.
Attackytan som ingen budgeterat för
Programvara brukade ha ett fåtal platser där en angripare kunde hamna: koden, beroendena, pipelineAI har lagt till ytterligare två, och båda matar direkt in i AI-leveranskedjan.
Modellen och agenten. Verktygsförgiftning, snabb injektion, agentautonomi som går längre än någon avsett. En dold instruktion i en MCP-serverbeskrivning kan i tysthet omdirigera vad en copilot gör, och utvecklaren ser det aldrig hända.
Utvecklarens egen miljö. IDE:er, AI-copiloter, MCP-servrar, agent CLI:er. Osynliga för äldre AppSec-skannrar, som inte vet vad en modell är, och osynliga för EDR, som övervakar operativsystemet och inte har någon aning om vad ett beroende eller ett MCP-anrop är.
Inget av detta är teoretiskt. Under de senaste arton månaderna:
- En dold Unicode-"regelfilsbakdörr" lät angripare injicera osynliga instruktioner i konfigurationsfilerna som Copilot och Cursor läste, och i tysthet bakdörra kod som assistenten genererade. GitHub lade till en varning för detta år 2025.
- Ett kommandoinjektionsfel i en populär MCP-brygga (CVSS 9.6) nådde över 400 000 nedladdningar innan det åtgärdades, det första dokumenterade fallet av fullständig fjärrkodkörning som utlöstes helt enkelt genom att ansluta till en opålitlig MCP-server.
- En självförökande npm-mask förvandlade utvecklarna själva till leveransmekanismen, och mönstret upprepades i stor skala under de följande månaderna i andra ekosystem, ett typiskt säkerhetsmisslyckande i AI-leveranskedjan.
- Forskare fann att en betydande andel av de paket som LLM:er rekommenderar inte existerar alls, ”slopsquatted” namn som en angripare registrerar innan en riktig utvecklare ens ber modellen att importera dem.
Googles egen forskning om att säkra leveranskedjan för AI-programvara når en liknande slutsats från en annan vinkel: modeller som hittades i omlopp 2023 och 2024 såg legitima ut samtidigt som de innehöll kod som kunde stjäla data eller plantera en bakdörr när den hade laddats ner, och lösningen var inte en ny kategori av verktyg utan snarare att tillämpa leveranskedjans disciplin, som proveniens och signering, på artefakter som ingen hade spårat tidigare. Det är säkerhetsproblemet med AI-leveranskedjan i en mening: artefakterna är nya, men den disciplin de behöver är det inte.
Varför dina befintliga verktyg inte längre fungerar
SAST läser kod. SCA läser ett manifest av beroenden. Ingen av dem vet vad en modell är, vad en MCP-server exponerar eller vad en färdighetsfil instruerar en agent att göra. Det är precis i det gapet som attacker från AI-eran hamnar, i utrymmet mellan "kod vi skannar" och "AI vi i tysthet anammat".
Resultatet är en kategori av skugg-AI nej CISO kan för närvarande svara på följande frågor: vilka modeller vi kör, vilka agenter kan nå vad, och vilken MCP-server någon anslöt till förra tisdagen utan att berätta för någon. Att svara bra på den frågan är uppgiften för AI:s leveranskedjesäkerhet, och det är anledningen till att generiska AppSec-verktyg ständigt brister här.
Vad AI-säkerhet egentligen innebär
Xygeni är AI-säkerhetsföretaget som behandlar detta som tre sammankopplade rörelser över hela SDLC: upptäcka, upptäcka och verkställa.
Upptäck: ta reda på vilken AI du faktiskt har
Kontinuerlig, automatisk identifiering i dina databaser avslöjar alla AI-tillgångar: modeller, ramverk, datamängder, slutpunkter för slutledning, agenter, MCP-servrar, färdigheter, prompter, guardrailsoch de AI-kodningsverktyg som dina utvecklare faktiskt använder. Inga undersökningar. Ingen självrapportering. Om det lämnade ett spår i ett arkiv, visas det i inventeringen, det första och mest grundläggande kravet för verklig AI-leveranskedjans säkerhet.
AI-grafen kartlägger sedan hur dessa tillgångar kopplas samman: vilken modell en datauppsättning matar, vilken agent anropar vilket verktyg, vilken MCP-server som sitter bakom vilken assistent. En tillgång i sig säger dig lite. Grafen visar dig var risken koncentreras.
Från samma upptäckt genererar Xygeni en AI-BOMEn granskningsklar, maskinläsbar inventering av allt AI-relaterat i din programvara. När en tillsynsmyndighet, en revisor eller en kund frågar vilken AI du kör blir svaret en nedladdning istället för ett tre veckor långt kämpande.
Upptäck: riskerna som konventionella skannrar inte kan se
En dedikerad AI-skanner letar efter de fellägen som är specifika för AI-system: snabb injektion, verktygsinjektion och otillförlitligt verktygsanrop, dataläckage genom hämtning, systempromptförbikoppling, överdriven agency. Varje fynd mappas till OWASP Topp 10 för LLM-applikationer och pekar på exakt den fil och rad som skapar exponeringen, inte en vag "granska din AI-användning"-varning.
Samma detekteringslager behandlar färdighetsfiler, regelfiler och MCP-konfigurationer som de säkerhetsartefakter de är, inte som ofarlig dokumentation. Det flaggar skadliga eller förgiftade färdigheter, inspekterar MCP-serverkonfigurationer för verktygsförgiftning och avslöjar de uppmaningar som faktiskt driver dina AI-arbetsbelastningar.
Prioritera: tratten som skär ner på buller, inte hörn
Varje fynd filtreras successivt: ner till vad som är tillgängligt i applikationskoden, sedan till vad som verkligen är exploaterbart, och sedan till vad som finns i koden som ditt team aktivt utvecklar. Det som når en utvecklares kö är den korta lista som faktiskt hotar produktionen, med ramverksreferensen, exponeringsfönstret och riktlinjer för riskreducering bifogade.
Framtvinga: stoppa det innan det körs
Shield levererar policytillämpning till utvecklarens egen slutpunkt: den blockerar obehöriga och skadliga installationer, icke-godkända modeller och icke-sanktionerade MCP-servrar innan något körs. Under den finns Xygenis Tidig varning om skadlig kod (MEW), som fångar skadliga paket innan en signatur finns, litar fortfarande på lagrets ryktesbaserade verktyg eftersom ingen har rapporterat paketet ännu. Det är den verkställande delen av AI-leveranskedjans säkerhet: upptäckt och detektering berättar vad som är fel, Shield är det som faktiskt stoppar det.
Din AI-exponering finns inte bara i din AI-kod
En komplett säkerhetsbild av AI-leveranskedjan kräver mer än en modellinventering, och det är sällan bara det flashiga:
- AI-leverantörsuppgifter lämnas kvar i promptfiler, agentkonfigurationer eller pipeline Loggar är hemligheter som alla andra, och Xygenis hemlighetsdetektering fångar dem innan de når ett offentligt register.
- Sårbara AI- och ML-beroenden bära vanliga CVE:er, som framkommer genom samma programvarukompositionsanalys som redan täcker resten av din stack. Tredjepartsforskning om AI-användning har pekat på hur mycket av den moderna AI-stacken som består av externt anskaffade paket och dolda komponenter, vilket är precis den yta som programvarukompositionsanalysen byggdes för att täcka.
- Skadliga paket publiceras snabbare än någon rekommendation pipeline kan katalogisera dem fångas upp i förväg, samma MEW-kapacitet som skyddar resten av din leveranskedja.
Agentlagret: DevAI och CoreAI
Upptäckt och detektering täcker det som redan finns i dina databaser. DevAI fungerar där risken skapas: inuti IDE:n, som ett kontinuerligt, proaktivt lager som skannar mänsklig och AI-genererad kod medan den skrivs, inga uppmaningar krävs. Den förklarar hela exploit-vägen bakom ett fynd och föreslår MCP-validerade korrigeringar som en utvecklare kan tillämpa med tillförsikt, utan att förstöra bygget.
CoreAI sitter ovanför de enskilda skannrarna som intelligenslagret: det korrelerar kod, beroende, pipeline, och samlar data i en riskmodell, besvarar frågor på naturligt språk och producerar den chefsfärdiga rapportering som en säkerhetsledare behöver för att visa att styrning faktiskt sker, inte bara påstås.
Utöka det du har inom AI-säkerhet. Riv inte ut något.
Den vanligaste invändningen mot en ny säkerhetskategori är ”vi har redan tillräckligt med verktyg”. Som ett AI-säkerhetsföretag ber Xygeni dig inte att ersätta någonting: samma prioritering, förklaring och bedömning som tillämpas på deras egna resultat gäller även för resultat från dina befintliga. SAST, SCAoch tredjepartsskannrar. Din nuvarande stack blir en input, inte en offer, och din AI-leveranskedjas säkerhetsställning förbättras utan ett rip-and-replace-projekt kopplat till den.
Varför detta är viktigt nu, inte senare
Tillsynsmyndigheter enas om samma förväntningar från olika håll: EU:s AI-lag, NIS2 och Spaniens ENS strävar alla efter inventering och spårbarhet för AI-system, samma bevis som en AI-BOM är byggd för att producera. Riktningen är tydlig även där de exakta efterlevnadsmekanismerna fortfarande är fastställda: du kan inte intyga AI som du aldrig har inventerat, och du kan inte hävda AI-leveranskedjans säkerhet om själva leveranskedjan är osynlig för dig.
Att välja ett AI-säkerhetsföretag
Inte alla AI-säkerhetsföretag drar sin gräns på samma ställe. Vissa stannar vid att skanna din egen AI-genererade kod. Andra stannar vid slutpunkten. Säkerhetsfrågan kring AI-leveranskedjan är större än någon av segmenten för sig: den omfattar modellen, agenten, MCP-servern, kompetensfilen och det vanliga beroendet som finns under alltihop. Den där fullständiga livscykelvyn, från upptäckt till tillämpning, i en konsol med resten av dina AppSec-resultat, är vad du ska leta efter när du utvärderar ett AI-säkerhetsföretag snarare än ett enda verktyg.
Filerna som ingen granskar blev vägen in. AI-säkerhet är disciplinen att granska dem, och AI-leveranskedjans säkerhet är det som gör att den disciplinen håller från början till slut, på samma plattform där du redan granskar allt annat.
Se vad din AI faktiskt får göra. Börja gratis or BOKA EN DEMO.
FAQ
Lämnar Xygenis kod någonsin min infrastruktur?
Nej. Skanningar körs i din egen miljö och källkod laddas aldrig upp till Xygenis servrar. AI-inventeringen och AI-BOM byggs utifrån vad skannern ser lokalt, inte från en kopia som skickats externt.
Vad är skillnaden mellan AI-säkerhet, DevAI och CoreAI?
AI-säkerhet upptäcker och detekterar: den bygger AI-inventeringen, AI-BOM, och hittar risker som snabb injektion eller förgiftade färdighetsfiler. DevAI arbetar inuti IDE:n medan utvecklare skriver kod och föreslår korrigeringar allt eftersom. CoreAI ligger ovanför båda, korrelerar resultat över hela plattformen och besvarar frågor om din säkerhetssituation på naturligt språk.
Vilka AI-säkerhetsramverk anpassar sig Xygeni till?
Resultaten stämmer överens med OWASP Top 10 för LLM-ansökningar, OWASP Top 10 för MCP och OWASP Top 10 för Agentic Skills, tillsammans med NIST SP 800-218A och CISA/G7-vägledning om AI-materiallistor. Den kartläggningen är det som gör AI-BOM användbar som bevis på efterlevnad snarare än bara en inventering.
Kommer detta att flagga varje AI-bibliotek eller modell som risk?
Nej. Prioriteringsfunnet begränsar resultaten till vad som är tillgängligt i applikationskoden, verkligt exploaterbart och i aktiv utveckling, så listan en utvecklare ser är kort, inte en dump av varje AI-tillgång som upptäckts.
