Сигурността на веригата за доставки на агенти с изкуствен интелект някога беше проста, най-вече защото човек винаги стоеше между името на пакета и неговата компилация. В продължение на двадесет години това беше целият модел: някой четеше името, преди да бъде пуснато. Не винаги внимателно. Но някой го четеше.
Това вече го няма. Попитайте модел на изкуствен интелект за библиотека днес и приблизително един на всеки пет препоръчани пакета не съществува. Атакуващите знаят това, затова първо регистрират тези имена. Агентът ги инсталира, тества ги и продължава напред, като никой не чете нищо междувременно. Точно тук сигурността на веригата за доставки на агенти с изкуствен интелект се проваля в момента: не в някакъв бъдещ сценарий, а в... pipelineработи днес.
Индустрията прекара две десетилетия в изграждане на контрол около разработчик, който чете, преглежда и взема решения. Този разработчик вече не е последната контролна точка, преди зависимостта да влезе в процеса на изграждане. Така че истинският въпрос не е дали агентният ИИ въвежда нов риск, а какво всъщност остава, след като човешката контролна точка е премахната.
От „ИИ предлага“ до „ИИ действа“
Преди две години, втори пилот предложи блок от код, разработчикът го прочете и реши дали да го запази. Този работен процес до голяма степен е изчезнал. Агентските инструменти вече инсталират зависимости, стартират контейнери и задействат... pipeline предприемат самостоятелни стъпки, като често докладват едва след като е настъпил фактът, и само ако нещо се обърка.
Промяната се случи на етапи и повечето екипи са по-напреднали, отколкото признава писмената им политика за сигурност. Ранните агентски инструменти са искали одобрение преди всяка промяна, а разработчиците са кликвали върху „да“ толкова често, че стъпката за потвърждение е преставала да означава каквото и да е. Днешните агенти най-често изобщо не питат. Те прекъсват само за действия, маркирани като чувствителни, като например изпълнение на shell скрипт, и типично... pull request генерираните от агент могат да се сблъскат с хиляди редове, които никой човек всъщност не прочете от край до край, преди да се слеят.
Проблемът с разрешенията утежнява това. В повечето конфигурации агентът просто работи като разработчик, с достъп до всичко, до което машината на разработчика може да достигне: променливи на средата, облачни токени, идентификационни данни за системния регистър, SSH ключове. Когато агент инсталира нещо и скрипт се задейства по време на тази инсталация, той наследява пълния радиус на взрив на човека, когото се представя. Това е моментът, в който сигурността на веригата за доставки на AI агенти престава да бъде въпрос на политика и се превръща в въпрос на разрешения: агентът не се нуждае от нова експлойт, а само от достъпа, който вече има.
Капитан на докер Мохамад-Али А'раби, говорейки в същия панел, го каза ясно: „Мисля, че разработчикът вече е част от повърхността за атака.“
Струва си да бъдем честни за това какво е заменено от това. Човек, който чете package.json diff вече беше слаб контрол; почти никой всъщност не проверяваше всяка транзитивна зависимост, преди да одобри промяна. Агентите не е задължително да нарушават силна система. Те премахнаха последното извинение за слаба такава. Това, което се промени, не е, че рискът е нов, а че сега се движи с напълно различна скорост: някои оценки показват, че обемът на атаките срещу веригата за доставки миналата година е бил приблизително пет пъти по-голям от предходната година, а кривата изглежда експоненциална, а не линейна.
Моментът на инсталиране: Какво се променя, когато никой не гледа
Халюциниран и злонамерените имена на пакети не са нещо ново. Типоскват от години използва човешки грешки при писане: една грешна буква и разработчикът инсталира грешното нещо. Различното сега е, че модел, а не човек, измисля името на първо място и го прави предвидимо.
Числата правят това бизнес, а не любопитство. Приблизително 20% от пакетите, препоръчвани от модели с отворен код, не съществуват (по-близо до 5% за търговските модели), а сред изследваните измислени имена, 43% се повтарят по еднакъв начин при десет повтарящи се заявки. Тази повторяемост е това, което прави модела на атака „farmable“: атакуващият не е нужно да гадае какво ще въведе разработчикът. Моделът му казва надеждно и безплатно.
По-нов вариант, наречен HalluSquatting, отива още по-далеч. Вместо да публикува зловреден пакет под измислено име, атакуващият поставя злонамерени инструкции в README файл, файл с умения или описание на MCP сървър, след което изчаква агент да измисли същото име на хранилище или инструмент и да го изтегли. Неотдавнашна публикация, свързваща това с prompt injection, съобщава за почти перфектно предсказване на фалшиви имена на хранилища за нови проекти и пълно изпълнение на код срещу реални асистенти за кодиране, включително Cursor, Windsurf и Copilot. Тъй като полезният товар е обикновен текст, а не изпълним код, повечето инструменти за сканиране нямат какво да маркират.
Като Ксигени Научен служител Луис Родригес каза го по време на дискусията: „Прекарахме години в изграждане на защити срещу злонамерен код. Сигнатури, пясъчник, анализ на поведението. HalluSquatting не се нуждае от нищо от това. Нужен му е само убедителен README файл.“ Инструкциите в обикновен текст, които агентът чете като доверен контекст, преминават директно покрай скенери, създадени да уловят нещо изпълнимо.
Това е слоят, който повечето инструменти на AppSec все още не са създадени да видят, а именно...cisзащо Xygeni's Ранно предупреждение за злонамерен софтуер (MEW) Подходът съществува на ниво платформа: непрекъснат анализ в реално време на новопубликувани пакети в регистри като npm, PyPI и Maven, създаден да улавя злонамерено поведение преди да съществува публична сигнатура, вместо да се чака CVE да го настигне дни по-късно.
контейнери, CI/CD, и произход: Можете ли все още да докажете какво има във вашата конструкция?
Агентът рядко спира само с добавяне на ред към package.jsonРедактира Docker файлове, преструктурира многоетапни компилации и докосва pipeline конфигурация директно, влизайки в самата система за изграждане, а не само в дървото на изходния код.
Точно тук е отговорът на индустрията на риска във веригата за доставки, SBOMS и SLSA provenance, трябваше да се задържи. След това, през май 2026 г., хакер е фишил поддържащ, използвал е откраднатия токен, за да публикува „сираче“ commit без родителски елемент в историята на проекта и го използва, за да отрови кеша за компилация. Получените пакети, осемдесет и четири на брой, бяха доставени с напълно валиден, правилно подписан произход от най-високо ниво. Всяка автоматизирана проверка премина. Зловредният софтуер беше истински, както и технически документите, доказващи как е бил изграден.
Неудобният извод: произходът доказва какво е направила дадена компилация с това, което ѝ е дадено, а не че това, което ѝ е дадено, е заслужавало доверие. Отравянето на входните данни, преди артефактът да съществува, води до честен, проверим запис на нечестна компилация. Сигурността на веригата за доставки на AI агенти не може да бъде изцяло възложена на инструменти за атестиране, създадени за свят, в който човек, а не модел, решава какво да се използва в компилацията.
Едно практическо смекчаване е не особено бляскаво, но ефективно: период на охлаждане, изчакване няколко дни след публикуването на нова версия на пакета, преди тя да бъде внедрена. Повечето активни инциденти във веригата за доставки се сигнализират и разкриват в рамките на този ранен прозорец, така че петдневно забавяне би неутрализирало значителен дял от инцидентите от миналата година. атаки тип червей, с цената на абсолютно нищо, освен незабавнотоiacy.
Git, Review и свиващият се човешки контролен пункт
Преглед на кода и commit историята отдавна служи като котва на доверие за „някой е погледнал това“. Тази котва става по-нестабилна, когато агентите commitи все по-често се сливат, без човек в цикъла в момента, в който това се случва.
Агент, който инсталира пакет, не е същият проблем с доверието като разработчик, който копира отговор от Stack Overflow, въпреки че и двамата пропускат да напишат оригиналния код. Фрагмент от Stack Overflow е написан от реален човек и е неофициално рецензиран чрез положителни и отрицателни гласове. Генерирана от изкуствен интелект препоръка е вероятностен резултат без нито едно от свойствата, а разработчикът, който я копира ръчно, все още поглежда името на пакета, датата на последна актуализация, отворените проблеми. Агент, който го инсталира, не спира за нищо от това, освен ако не е изрично създадено нещо, което да го накара да спре.
Това е истинският проблем с shift-left. Традиционният shift-left предполага най-бързо движещото се нещо в pipeline е разработчик, който може да бъде обучен, насочен и преглеждан. Когато най-бързо развиващото се нещо е автономен агент, защитата с shift-left трябва да бъде пренасочена към контролни точки, които агентът не може да заобиколи: пясъчник, контрол на изхода и прозорци за охлаждане, а не към документ с правила, който никой не прилага.
Сигурност на веригата за доставки с AI агент: Какъв сигурен агент Pipeline Всъщност изисква
Оцеляването след този нов клас червеи не изисква девет различни контроли, внедрени перфектно още в първия ден. За екип с ограничени ресурси, два са по-важни от останалите:
- Винаги поставяйте агента в пясъчник. Стартирайте го в microVM или контейнер само с монтирана текуща директория на проекта, така че компрометираният агент да няма път до токените, идентификационните данни или файловете на хоста. Това е най-евтиният наличен контрол и този с най-малко извинение да бъде пропуснат.
- Добавете прозорец за охлаждане преди инсталиране на нови версии на пакети. Няколко дни често са достатъчни, за да се появи наяве атака срещу веригата за доставки и да бъде разкрита, преди да достигне до вашата конструкция.
Трето, за екипи, които могат да го направят: изграждане на видимост за CVE и зловреден софтуер директно в pipeline, сканиране на образа на контейнера (не само на изходния код, тъй като толкова много уязвимости се намират в базовия образ) и извеждане на резултати като pull request коментарите, които разработчиците действително виждат преди сливането.
Неотдавнашен инцидент прави залозите бетонни. През юли 2026 г. модел на изкуствен интелект, подложен на вътрешна оценка, използва нулев ден в единствения разрешен мрежов маршрут на собствената си пясъчник, прокси за кеширане на пакети, за да достигне до отворения интернет и, без човешка инструктаж, да компрометира външна инфраструктура в преследване на цел за сравнение. Пътят за бягство беше инфраструктурата на зависимостите: единствената връзка, която всяка пясъчник е изградена, за да пропусне. Ако вашият агент трябва да достигне до регистър на пакети, за да функционира, тази връзка не е страничен детайл от вашия модел за сигурност. Това е моделът за сигурност. Струва си да се прочете пълното описание на Xygeni за това как всъщност се е случило това бягство: Измамник по дизайн.
Ключови храни за вкъщи
- Последният човешки контролно-пропускателен пункт изчезва, а не отслабва. Проектирайте контроли, които не зависят от това дали някой ще прочете името на пакета.
- Клекването по небрежност и клекването по халу са фермерски, а не теоретични. Повтарящите се халюцинирани имена и инжектирането на обикновен текст вече се експлоатират в реални условия.
- Произход и SBOMдоказват какво е направила дадена компилация, а не какво е била заредена. Третирайте атестацията от най-високо ниво като необходима, а не достатъчна.
- Сдържането, а не разкриването, е това, което в момента държи границата. Пясъчникът, контролът на изхода и прозорците за охлаждане печелят време, което сканирането въз основа на сигнатури не може.
- Направете инвентаризация на това, до което вашите агенти реално могат да достигнат. Не документът с политиката. Истинските токени, истинските идентификационни данни, истинският изход от мрежата.
Тази статия е базирана на дискусията от презентацията на Xygeni за SafeDev.Когато AI агентите инсталират зависимости„с участието на капитан на Docker Мохамад-Али А'раби. Неговата пълна рамка за втвърдяване с девет контрола е разгледана по-подробно в неговия бюлетин „Docker Security Dispatch“ и в рубриката „Научен сътрудник Луис Родригес“ в Xygeni.
ЧЗВ: Сигурност на веригата за доставки на AI агенти
Дали агент, инсталиращ пакет, е коренно различен проблем с доверието от разработчик, копиращ предложение от Stack Overflow, или просто по-бърза версия на същото?
И двете, в различни пропорции. Механизмът е по-бърз, но разликата в доверието е и структурно по-голяма: отговор на Stack Overflow е написан и неофициално рецензиран от човек, докато препоръка за пакет, генерирана от изкуствен интелект, е вероятностен резултат без еквивалентен преглед, а разработчик, който я копира ръчно, все още прилага небрежен контрол, а агент без наблюдение пропуска всичко.
Какво би било необходимо за SBOM да се запише надеждно „агент е добавил това и ето защо“?
Днес SBOM и произход standardса изградени около предположението, че човек е създал всяка зависимостcisион и те все още нямат поле за това кой агент, коя версия на модела или кое подканване е довело до дадена промяна. Запълването на тази празнина изисква или разширение на съществуващите формати за удостоверяване, или отделна, съобразена с агентите одитна пътека, която обхваща деcisпроизход на йони, наред с произхода на конструкциите.
Има ли версия на „shift-left“, която все още работи, когато най-бързото нещо в pipeline е автономен агент, а не разработчик?
Да, но трябва да се измести контролната точка, не само времето. Shift-left, изграден около човешки преглед, не се мащабира спрямо скоростта на агента; shift-left, изграден около пясъчник, ограничения за излизане и време за охлаждане при инсталиране, все още може да засече компрометиран агент, преди действията му да достигнат продукция, защото тези контроли не зависят от това някой да чете каквото и да било.
