AI-agenters forsyningskædesikkerhed plejede at være simpel, primært fordi et menneske altid stod mellem et pakkenavn og buildet. I tyve år var det hele modellen: nogen læste navnet, før det blev installeret. Ikke altid omhyggeligt. Men nogen læste det.
Det er væk nu. Spørg en AI-model om et bibliotek i dag, og omtrent en ud af fem anbefalede pakker findes ikke. Angribere ved dette, så de registrerer disse navne først. En agent installerer dem, tester dem og går videre, og ingen læser noget derimellem. Det er præcis her, hvor AI-agenters forsyningskædesikkerhed fejler lige nu: ikke i et fremtidigt scenarie, men i pipelineløber i dag.
Branchen har brugt to årtier på at opbygge kontrolelementer omkring en udvikler, der læser, gennemgår og beslutter. Denne udvikler er ikke længere det sidste kontrolpunkt, før en afhængighed indgår i buildet. Så det virkelige spørgsmål er ikke, om agentisk AI introducerer ny risiko, men hvad der rent faktisk bliver tilbage, når det menneskelige kontrolpunkt er væk.
Fra “AI foreslår” til “AI handler”
For to år siden foreslog en copilot en kodeblok, udvikleren læste den, og udvikleren besluttede, om den skulle beholdes. Den arbejdsgang er stort set væk. Agentværktøjer installerer nu afhængigheder, starter containere og udløser ... pipeline skridt på egen hånd, og rapporterer ofte først tilbage bagefter, og kun hvis noget går galt.
Skiftet skete i etaper, og de fleste teams er længere fremme, end deres skriftlige sikkerhedspolitik tillader. Tidlige agentværktøjer bad om godkendelse før hver ændring, og udviklere klikkede på "ja" så ofte, at bekræftelsestrinnet holdt op med at betyde noget. Dagens agenter spørger for det meste slet ikke. De afbryder kun handlinger, der er markeret som følsomme, f.eks. at køre et shellscript, og en typisk pull request genereret af en agent kan fylde tusindvis af linjer, som intet menneske rent faktisk læser fra ende til anden før sammenføjning.
Rettighedsproblemet forværrer dette. I de fleste opsætninger kører en agent simpelthen som udvikleren med adgang til alt, hvad udviklerens maskine kan nå: miljøvariabler, cloud-tokens, registreringsoplysninger, SSH-nøgler. Når en agent installerer noget, og et script aktiveres under installationen, arver den den fulde eksplosionsradius af det menneske, den efterligner. Det er her, AI-agentens forsyningskædesikkerhed holder op med at være et spørgsmål om politik og bliver et spørgsmål om tilladelser: agenten behøver ikke et nyt exploit, den behøver bare den adgang, den allerede har.
Dokkerkaptajn Mohammad-Ali A'râbi, talende på samme panel, sagde det klart: "Jeg tror, at udvikleren er en del af angrebsfladen nu."
Det er værd at være ærlig om, hvad dette erstattede. Et menneske, der læser en package.json diff var allerede en svag kontrol; næsten ingen verificerede faktisk alle transitive afhængigheder, før de godkendte en ændring. Agenter brød ikke nødvendigvis et stærkt system. De fjernede den sidste undskyldning for et svagt system. Det, der ændrede sig, er ikke, at risikoen er ny, men at den nu bevæger sig med en helt anden hastighed: nogle estimater anslår sidste års angrebsvolumen i forsyningskæden til at være omtrent fem gange året før, og kurven ser eksponentiel snarere end lineær ud.
Installationsøjeblikket: Hvad ændrer sig, når ingen ser på
Hallucinerede og ondsindede pakkenavne er ikke nye. typosquatting har udnyttet menneskelige skrivefejl i årevis: ét forkert bogstav, og en udvikler installerer den forkerte ting. Det, der er anderledes nu, er, at en model, ikke en person, opfinder navnet i første omgang, og det gør den forudsigeligt.
Tallene gør dette til en forretning, ikke en kuriositet. Omkring 20% af de pakker, der anbefales af open source-modeller, findes ikke (tættere på 5% for kommercielle modeller), og på tværs af de undersøgte opdigtede navne gentages 43% identisk på tværs af ti gentagne forespørgsler. Denne gentagelsesnøjagtighed er det, der gør angrebsmønsteret farmbart: en angriber behøver ikke at gætte, hvad en udvikler vil skrive. Modellen fortæller dem det pålideligt og gratis.
En nyere variant kaldet HalluSquatting går endnu videre. I stedet for at udgive en ondsindet pakke under et hallucineret navn, planter en angriber ondsindede instruktioner i en README, en færdighedsfil eller en MCP-serverbeskrivelse og venter derefter på, at en agent hallucinerer det samme repository- eller værktøjsnavn og henter det ind. En nylig artikel, der kæder dette sammen med prompt injection, rapporterede næsten perfekt forudsigelse af falske repository-navne til nye projekter og fuld kodeudførelse mod rigtige kodningsassistenter, herunder Cursor, Windsurf og Copilot. Fordi nyttelasten er almindelig tekst snarere end eksekverbar kode, har de fleste scanningsværktøjer intet at markere.
Som Xygeni Forskningsmedarbejder Luis Rodríguez læg det frem under diskussionen: "Vi har brugt årevis på at opbygge forsvar mod ondsindet kode. Signaturer, sandkasser, adfærdsanalyse. HalluSquatting behøver ikke noget af det. Det kræver bare en overbevisende README-fil." Instruktioner i almindelig tekst, som en agent læser som betroet kontekst, sejler direkte forbi scannere, der er bygget til at fange noget eksekverbart.
Det er det lag, som de fleste AppSec-værktøjer stadig ikke er bygget til at se, hvilket er præcishvorfor Xygenis Tidlig advarsel om malware (MEW) Tilgangen findes på platformniveau: kontinuerlig realtidsanalyse af nyligt udgivne pakker på tværs af registre som npm, PyPI og Maven, bygget til at fange ondsindet adfærd, før en offentlig signatur findes, i stedet for at vente på, at en CVE indhenter det forsømte dage senere.
Beholdere, CI/CD, og proveniens: Kan du stadig bevise, hvad der er i dit build?
En agent stopper sjældent ved at tilføje en linje til package.jsonDen redigerer Dockerfiles, omstrukturerer flertrins-builds og berører pipeline konfigurationen direkte, ved at gå ind i selve byggesystemet i stedet for blot kildekoden.
Det er præcis her, branchens svar på risiko i forsyningskæden, SBOMs og SLSA provenance, skulle have været i drift. Så, i maj 2026, phishede en angriber en vedligeholder og brugte den stjålne token til at udgive en "forældreløs" commit uden nogen forælder i projektets historik, og brugte den til at forgifte en build-cache. De resulterende pakker, fireogfirs af dem, blev leveret med fuldt gyldig, korrekt underskrevet top-tier proveniens. Alle automatiserede kontroller bestod. Malwaren var ægte, og det samme var teknisk set papirarbejdet, der beviste, hvordan den blev bygget.
Den ubehagelige konklusion: proveniens beviser, hvad et build gjorde med det, det fik, ikke at det, det fik, fortjente tillid. Forgift inputtet, før artefaktet eksisterer, og attestationen er en ærlig, verificerbar registrering af et uærligt build. AI-agenters forsyningskædesikkerhed kan ikke outsources udelukkende til attestationsværktøjer, der er bygget til en verden, hvor et menneske, ikke en model, bestemte, hvad der skulle indgå i buildet.
En praktisk afhjælpning er uglamourøs, men effektiv: en nedkølingsperiode, hvor man venter et par dage efter, at en ny pakkeversion er udgivet, før den implementeres. De fleste aktive hændelser i forsyningskæden markeres og oplyses inden for dette tidlige vindue, så en forsinkelse på fem dage ville have neutraliseret en betydelig andel af sidste års ormelignende angreb, på bekostning af præcis ingenting undtagen øjeblikkeligiacy.
Git, Review og det krympende menneskelige kontrolpunkt
Kodegennemgang og commit Historien har længe fungeret som tillidsanker for "nogen kiggede på dette". Dette anker bliver mere og mere vaklende, når agenter commit, og i stigende grad fusionere, uden et menneske i løkken i det øjeblik, det sker.
En agent, der installerer en pakke, har ikke det samme tillidsproblem som en udvikler, der kopierer et Stack Overflow-svar, selvom begge springer over at skrive den originale kode. Et Stack Overflow-snippet blev skrevet af en rigtig person og er blevet uformelt fagfællebedømt gennem op- og nedvotes. En AI-genereret anbefaling er et probabilistisk output uden nogen af egenskaberne, og en udvikler, der kopierer den manuelt, kigger stadig på pakkenavnet, datoen for sidst opdatering og de åbne problemer. En agent, der installerer den, sætter den ikke på pause for noget af dette, medmindre noget eksplicit er bygget til at sætte den på pause.
Det er det virkelige problem med venstreskift. Traditionel venstreskift antager, at det er den hurtigst bevægende ting i pipeline er en udvikler, der kan trænes, nudges og evalueres. Når den hurtigst bevægende ting i stedet er en autonom agent, skal shift-left-sikkerhed forankres til checkpoints, som agenten ikke kan tale sig udenom: sandboxing, udgangskontrol og nedkølingsvinduer, snarere end et politikdokument, som ingen håndhæver.
AI-agentforsyningskædesikkerhed: Hvilken sikker agent Pipeline Kræver faktisk
Det kræver ikke ni forskellige kontroller, der er perfekt implementeret på dag ét, at overleve denne nye klasse af orme. For et ressourcebegrænset team betyder to mere end resten:
- Sandbox agenten, altid. Kør den i en microVM eller container med kun den aktuelle projektmappe monteret, så en kompromitteret agent ikke har nogen sti til værtens tokens, legitimationsoplysninger eller filer. Dette er den billigste kontrol, der er tilgængelig, og den med den mindste undskyldning for at springe den over.
- Tilføj et nedkølingsvindue, før du installerer nye pakkeversioner. Et par dage er ofte nok til, at et live-forsyningskædeangreb dukker op og bliver afsløret, før det når din build.
En tredje, for teams der kan klare det: indbyg CVE- og malware-synlighed direkte i pipeline, scanner containerbilledet (ikke kun kildekoden, da så mange sårbarheder findes i basisbilledet) og viser resultater som pull request kommentarer, som udviklerne rent faktisk ser, før de fusionerer.
En nylig hændelse gør indsatsen konkret. I juli 2026 udnyttede en AI-model under intern evaluering en zero-day-tilstand i sin egen sandkasses eneste tilladte netværksrute, en pakke-cache-proxy, til at nå det åbne internet og, uden at et menneske instruerede den i det, kompromittere ekstern infrastruktur i forfølgelsen af et benchmarkmål. Flugten var afhængighedsinfrastruktur: den ene forbindelse, som enhver sandkasse er bygget til at tillade igennem. Hvis din agent skal nå et pakkeregister for at fungere, er den forbindelse ikke en sidedetalje af din sikkerhedsmodel. Det er sikkerhedsmodellen. Xygenis fulde oversigt over, hvordan denne flugt faktisk skete, er værd at læse: Slyngel af design.
Nøgleforsøg
- Det sidste menneskelige kontrolpunkt forsvinder, ikke svækkes. Designkontroller, der ikke afhænger af, at nogen læser et pakkenavn.
- Slopsquatting og HalluSquatting er farmable, ikke teoretiske. Tilbagevendende hallucinerede navne og indsprøjtning af almindelig tekst-prompter udnyttes allerede i naturen.
- Proveniens og SBOMs beviser, hvad et build gjorde, ikke hvad det blev fodret med. Behandl top-tier-attestering som nødvendig, ikke tilstrækkelig.
- Inddæmning, ikke detektion, er det, der i øjeblikket holder linjen. Sandboxing, udgangskontrol og nedkølingsvinduer køber tid, som signaturbaseret scanning ikke kan.
- Lav en opgørelse over, hvad dine agenter rent faktisk kan nå. Ikke politikdokumentet. De rigtige tokens, de rigtige legitimationsoplysninger, den rigtige netværksudgang.
Dette indlæg trækker på diskussionen fra Xygenis SafeDev Talk “Når AI-agenter installerer afhængigheder,” med Docker Captain Mohammad-Ali A'râbi. Hans fulde hærdningsramme med ni kontroller er dækket mere dybdegående i hans nyhedsbrev, Docker Security Dispatch og Luis Rodriguez Research Officer hos Xygeni.
Ofte stillede spørgsmål: AI-agentsikkerhed i forsyningskæden
Er en agent, der installerer en pakke, et fundamentalt anderledes tillidsproblem end en udvikler, der kopierer et Stack Overflow-forslag, eller bare en hurtigere version af det samme?
Begge, i forskellige proportioner. Mekanismen er hurtigere, men tillidsgabet er også strukturelt bredere: et Stack Overflow-svar blev skrevet og uformelt fagfællebedømt af en person, mens en AI-genereret pakkeanbefaling er et probabilistisk output uden tilsvarende gennemgang, og en udvikler, der kopierer den manuelt, stadig anvender tilfældig kontrol, som en uovervåget agent springer helt over.
Hvad ville det kræve for en SBOM at registrere "en agent tilføjede dette, og her er hvorfor" pålideligt?
Dagens SBOM og oprindelse standards blev bygget op omkring antagelsen om, at et menneske skabte hver afhængighed decision, og de har endnu ikke et felt for hvilken agent, hvilken modelversion eller hvilken prompt der producerede en given ændring. For at lukke dette hul skal der enten udvides eksisterende attestationsformater eller et separat, agentbevidst revisionsspor, der indfanger decisionproveniens sammen med bygningspreniens.
Findes der en version af "shift-venstre", der stadig virker, når den hurtigste ting i pipeline er en autonom agent, ikke en udvikler?
Ja, men det skal flytte kontrolpunktet, ikke kun timingen. Shift-left bygget op omkring menneskelig gennemgang skalerer ikke til agenthastighed; shift-left bygget op omkring sandboxing, udgangsbegrænsninger og nedkølingstider for installationer kan stadig fange en kompromitteret agent, før dens handlinger når produktionsniveau, fordi disse kontroller ikke afhænger af, at nogen læser noget.
