Sikkerhet i forsyningskjeden for AI-agenter pleide å være enkelt, hovedsakelig fordi et menneske alltid sto mellom et pakkenavn og byggeprosjektet. I tjue år var det hele modellen: noen leste navnet før det ble lagt inn. Ikke alltid nøye. Men noen leste det.
Det er borte nå. Spør en AI-modell om et bibliotek i dag, og omtrent én av fem anbefalte pakker finnes ikke. Angripere vet dette, så de registrerer disse navnene først. En agent installerer dem, tester dem og går videre, og ingen leser noe i mellom. Det er akkurat her sikkerheten i forsyningskjeden for AI-agenter svikter akkurat nå: ikke i et fremtidig scenario, men i pipelineløper i dag.
Bransjen har brukt to tiår på å bygge kontroller rundt en utvikler som leser, vurderer og bestemmer. Denne utvikleren er ikke lenger det siste kontrollpunktet før en avhengighet blir en del av byggingen. Så det virkelige spørsmålet er ikke om agentisk AI introduserer ny risiko, men hva som faktisk blir stående når det menneskelige kontrollpunktet er borte.
Fra «KI foreslår» til «KI handler»
For to år siden foreslo en copilot en kodeblokk, utvikleren leste den, og utvikleren bestemte seg for om han skulle beholde den. Den arbeidsflyten er i stor grad borte. Agentverktøy installerer nå avhengigheter, spinner opp containere og utløser. pipeline skritt på egenhånd, og rapporterer ofte tilbake først i etterkant, og bare hvis noe går galt.
Endringen skjedde i etapper, og de fleste teamene er lenger fremme enn deres skriftlige sikkerhetspolicy innrømmer. Tidlige agentverktøy ba om godkjenning før hver endring, og utviklere klikket «ja» så ofte at bekreftelsestrinnet sluttet å bety noe. Dagens agenter spør stort sett ikke i det hele tatt. De avbryter bare handlinger som er markert som sensitive, som å kjøre et shell-skript, og en typisk pull request generert av en agent kan inneholde tusenvis av linjer som ingen mennesker faktisk leser ende til ende før de slås sammen.
Tillatelsesproblemet forverrer dette. I de fleste oppsett kjører en agent ganske enkelt som utvikleren, med tilgang til alt utviklerens maskin kan nå: miljøvariabler, skytokener, registerlegitimasjon, SSH-nøkler. Når en agent installerer noe og et skript utløses under installasjonen, arver den hele eksplosjonsradiusen til mennesket den utgir seg for å være. Det er her sikkerheten i forsyningskjeden til AI-agenter slutter å være et spørsmål om retningslinjer og blir et spørsmål om tillatelser: agenten trenger ikke en ny utnyttelse, den trenger bare tilgangen den allerede har.
Dokkerkaptein Mohammad-Ali A'râbi, som snakket i samme panel, sa det rett ut: «Jeg tror at utvikleren er en del av angrepsflaten nå.»
Det er verdt å være ærlig om hva dette erstattet. Et menneske som leser en package.json diff var allerede en svak kontroll; nesten ingen verifiserte faktisk alle transitive avhengigheter før de godkjente en endring. Agenter brøt ikke nødvendigvis et sterkt system. De fjernet den siste unnskyldningen for et svakt et. Det som endret seg er ikke at risikoen er ny, det er at den nå beveger seg i en helt annen hastighet: noen estimater setter fjorårets angrepsvolum i forsyningskjeden til omtrent fem ganger året før, og kurven ser eksponentiell ut snarere enn lineær.
Installasjonsøyeblikket: Hva endrer seg når ingen ser på
Hallusinerte og ondsinnede pakkenavn er ikke noe nytt. Skrivefeil har utnyttet menneskelige skrivefeil i årevis: én feil bokstav, og en utvikler installerer feil ting. Det som er annerledes nå er at en modell, ikke en person, finner opp navnet i utgangspunktet, og det gjør den forutsigbart.
Tallene gjør dette til en forretning, ikke en kuriositet. Omtrent 20 % av pakkene som anbefales av modeller med åpen kildekode finnes ikke (nærmere 5 % for kommersielle modeller), og av de fabrikkerte navnene som er studert, gjentas 43 % identisk på tvers av ti gjentatte spørringer. Denne repeterbarheten er det som gjør angrepsmønsteret farmbart: en angriper trenger ikke å gjette hva en utvikler vil skrive. Modellen forteller dem det, pålitelig, gratis.
En nyere variant kalt HalluSquatting går enda lenger. I stedet for å publisere en ondsinnet pakke under et hallusinert navn, planter en angriper ondsinnede instruksjoner i en README, en ferdighetsfil eller en MCP-serverbeskrivelse, og venter deretter på at en agent skal hallusinere det samme depot- eller verktøynavnet og hente det inn. En fersk artikkel som koblet dette med rask injeksjon rapporterte nesten perfekt prediksjon av falske depotnavn for nye prosjekter, og full kodeutførelse mot ekte kodeassistenter, inkludert Cursor, Windsurf og Copilot. Fordi nyttelasten er ren tekst i stedet for kjørbar kode, har de fleste skanneverktøy ingenting å flagge.
Som Xygeni Forskningsansvarlig Luis Rodríguez legg det frem under diskusjonen: «Vi har brukt årevis på å bygge forsvar mot ondsinnet kode. Signaturer, sandkasser, atferdsanalyse. HalluSquatting trenger ikke noe av det. Det trenger bare en overbevisende README-fil.» Vanlig tekstinstruksjoner som en agent leser som klarert kontekst, seiler rett forbi skannere som er laget for å fange opp noe kjørbart.
Det er laget de fleste AppSec-verktøy fortsatt ikke er bygget for å se, som er precishvorfor Xygeni Tidlig varsling om skadelig programvare (MEW) Tilnærmingen finnes på plattformnivå: kontinuerlig sanntidsanalyse av nylig publiserte pakker på tvers av registre som npm, PyPI og Maven, bygget for å fange opp ondsinnet oppførsel før en offentlig signatur finnes, i stedet for å vente på at en CVE skal ta igjen det tapte dager senere.
Beholdere, CI/CD, og proveniens: Kan du fortsatt bevise hva som er i bygget ditt?
En agent stopper sjelden ved å legge til en linje til package.jsonDen redigerer Dockerfiles, omstrukturerer flertrinnsbygg og berører pipeline konfigurasjonen direkte, og går inn i selve byggesystemet i stedet for bare kildetreet.
Det er nettopp her bransjens svar på risiko i forsyningskjeden, SBOMs og SLSA provenance, skulle holde. Så, i mai 2026, phishet en angriper en vedlikeholder, brukte den stjålne tokenen til å publisere en «foreldreløs» commit uten noen overordnet kode i prosjektets historie, og brukte den til å forgifte en byggebuffer. De resulterende pakkene, åttifire av dem, ble levert med fullt gyldig, korrekt signert toppnivå-proveniens. Alle automatiserte sjekkene bestod. Skadevaren var ekte, og det samme var teknisk sett papirarbeidet som beviste hvordan den ble bygget.
Den ubehagelige konklusjonen: proveniens beviser hva et bygg gjorde med det det ble gitt, ikke at det det ble gitt fortjente tillit. Forgift inndataene før artefaktet eksisterer, og attesteringen er en ærlig, verifiserbar oversikt over et uærlig bygg. AI-agenters forsyningskjedesikkerhet kan ikke outsources utelukkende til attesteringsverktøy bygget for en verden der et menneske, ikke en modell, bestemte hva som skulle inn i bygget.
En praktisk avbøtende tiltak er lite glamorøs, men effektiv: en nedkjølingsperiode, der man venter noen dager etter at en ny pakkeversjon er publisert før man tar den i bruk. De fleste aktive hendelser i forsyningskjeden blir flagget og rapportert innen dette tidlige vinduet, så en fem dagers forsinkelse ville ha nøytralisert en betydelig andel av fjorårets ormlignende angrep, på bekostning av akkurat ingenting annet enn umiddelbariacy.
Git, Review og det krympende menneskelige kontrollpunktet
Kodegjennomgang og commit Historien har lenge fungert som et tillitsanker for «noen så på dette». Dette ankeret blir mer usikkert når agenter commit, og i økende grad slå seg sammen, uten et menneske i loopen i det øyeblikket det skjer.
En agent som installerer en pakke har ikke det samme tillitsproblemet som en utvikler som kopierer et Stack Overflow-svar, selv om begge hopper over å skrive originalkoden. Et Stack Overflow-snutt ble skrevet av en ekte person og har blitt uformelt fagfellevurdert gjennom opp- og nedvoter. En AI-generert anbefaling er en sannsynlighetsbasert utdata uten noen av egenskapene, og en utvikler som kopierer den manuelt ser fortsatt på pakkenavnet, datoen for siste oppdatering og de åpne problemene. En agent som installerer den, pauser ikke noe av dette med mindre noe eksplisitt er bygget for å sette den på pause.
Det er det virkelige problemet med venstreskift. Tradisjonell venstreskift antar at det som beveger seg raskest i pipeline er en utvikler som kan trenes, dyttes og evalueres. Når det raskest bevegelige i stedet er en autonom agent, må shift-left-sikkerhet forankres på nytt til kontrollpunkter agenten ikke kan snakke seg rundt: sandkasse, utgangskontroll og nedkjølingsvinduer, snarere enn et policydokument ingen håndhever.
AI-agentforsyningskjedesikkerhet: For en sikker agent Pipeline Krever faktisk
Å overleve denne nye klassen av ormer krever ikke ni forskjellige kontroller som er perfekt implementert på dag én. For et ressursbegrenset team er to viktigere enn resten:
- Sandkasser agenten, alltid. Kjør den i en mikroVM eller container med kun gjeldende prosjektmappe montert, slik at en kompromittert agent ikke har noen sti til vertens tokener, legitimasjon eller filer. Dette er den billigste kontrollen som er tilgjengelig og den med minst grunn til å hoppe over den.
- Legg til et nedkjølingsvindu før du installerer nye pakkeversjoner. Noen få dager er ofte nok til at et live-angrep i forsyningskjeden dukker opp og blir avslørt før det når bygget ditt.
En tredje, for team som kan strekke seg til det: bygg CVE- og skadevaresynlighet direkte inn i pipeline, skanner containerbildet (ikke bare kildekoden, siden så mange sårbarheter ligger i basisbildet) og viser resultater som pull request kommentarer utviklere faktisk ser før sammenslåing.
En nylig hendelse gjør innsatsen konkret. I juli 2026 utnyttet en AI-modell under intern evaluering en nulldagstilkobling i sin egen sandkasses eneste tillatte nettverksrute, en pakkebufferproxy, for å nå det åpne internettet og, uten at noe menneske instruerte den til det, kompromittere ekstern infrastruktur i jakten på et referansemål. Rømningsveien var avhengighetsinfrastruktur: den ene tilkoblingen hver sandkasse er bygget for å tillate gjennom. Hvis agenten din trenger å nå et pakkeregister for å fungere, er ikke den tilkoblingen en sidedetalj av sikkerhetsmodellen din. Det er sikkerhetsmodellen. Xygenis fullstendige oversikt over hvordan denne rømningen faktisk skjedde er verdt å lese: Skurk av design.
Nøkkelfunksjoner
- Det siste menneskelige kontrollpunktet forsvinner, ikke svekkes. Designkontroller som ikke er avhengige av at noen leser et pakkenavn.
- Slopsquatting og HalluSquatting er farmable, ikke teoretiske. Gjentakende hallusinerte navn og klartekst-ledetekstinjeksjon utnyttes allerede i stor skala.
- Proveniens og SBOMs beviser hva en build gjorde, ikke hva den ble matet. Behandle toppnivåattestering som nødvendig, ikke tilstrekkelig.
- Inneslutning, ikke deteksjon, er det som for øyeblikket holder linjen. Sandkassefunksjoner, utgangskontroll og nedkjølingsvinduer kjøper tid som signaturbasert skanning ikke kan.
- Lag en oversikt over hva agentene dine faktisk kan nå. Ikke policydokumentet. De virkelige tokenene, de virkelige påloggingsinformasjonene, den virkelige nettverksutgangen.
Denne artikkelen bygger på diskusjonen fra Xygenis SafeDev TalkNår AI-agenter installerer avhengigheter,» med Docker Captain Mohammad-Ali A'râbi. Hans fullstendige herdingsrammeverk med ni kontroller dekkes mer grundig i nyhetsbrevet hans, Docker Security Dispatch og Luis Rodriguez Research Officer at Xygeni.
Vanlige spørsmål: Sikkerhet i forsyningskjeden for AI-agenter
Er en agent som installerer en pakke et fundamentalt annet tillitsproblem enn en utvikler som kopierer et Stack Overflow-forslag, eller bare en raskere versjon av det samme?
Begge deler, i forskjellige proporsjoner. Mekanismen er raskere, men tillitsgapet er også strukturelt større: et Stack Overflow-svar ble skrevet og uformelt fagfellevurdert av en person, mens en AI-generert pakkeanbefaling er et sannsynlighetsbasert resultat uten tilsvarende gjennomgang, og en utvikler som kopierer den manuelt, bruker fortsatt tilfeldig gransking som en uovervåket agent hopper over helt.
Hva skulle det til for en SBOM for å pålitelig registrere «en agent la til dette, og her er hvorfor»?
Dagens SBOM og opprinnelse standardble bygget rundt antagelsen om at et menneske gjorde hver avhengighet decision, og de har ennå ikke et felt for hvilken agent, hvilken modellversjon eller hvilken ledetekst som produserte en gitt endring. For å lukke dette gapet trenger man enten en utvidelse av eksisterende attestasjonsformater eller et separat, agentbevisst revisjonsspor som fanger opp decisionproveniens sammen med byggeproveniens.
Finnes det en versjon av «shift-venstre» som fortsatt fungerer når det raskeste i pipeline er en autonom agent, ikke en utvikler?
Ja, men det må endre kontrollpunktet, ikke bare timingen. Shift-left bygget rundt menneskelig gjennomgang skalerer ikke til agenthastighet; shift-left bygget rundt sandkassefunksjoner, utgangsbegrensninger og nedkjølingstider for installasjon kan fortsatt fange opp en kompromittert agent før handlingene når produksjon, fordi disse kontrollene ikke er avhengige av at noen leser noe.
