Сигурност за AI агенти: Защо CISO лидерите настояват за предпазни огради, а не за догадки
Изображение: Svetni.me AI чрез собствена разработка
Навлизането на автономни изкуствени интелекти (AI агенти) в софтуерната разработка изправя лидерите по сигурност пред безпрецедентни предизвикателства. В скорошна панелна дискусия, организирана от Docker, водещи експерти по киберсигурност обсъдиха как организациите могат безопасно да отключат продуктивността на агентния изкуствен интелект [1]. Участие в разговора взеха Марк Лехнер, главен директор по сигурността (CISO) на Docker, Зак Лойд, основател и изпълнителен директор на Warp, и Гавриел Коен, съосновател на NanoCo. Дискусията беше модерирана от Мориа Хара, основател на CISO общност с над 3000 членове.
Дилемата пред CISO: Неконтролирана скорост срещу управление на риска
Внедряването на AI агенти в предприятието поставя CISO лидерите в изключително неудобна позиция. От една страна, бизнесът настоява за внедряване на иновациите с цел постигане на революционна производителност. От друга страна, пускането на автономни агенти да пишат и изпълняват код без стриктни рамки за сигурност създава сериозни уязвимости. Според Мориа Хара разработчиците често използват тези инструменти без официално одобрение или съгласуване със сигурността [1].
В резултат на това мениджърите по сигурност са принудени да толерират нерегламентиран софтуер и да се надяват, че нищо няма да се счупи. Те се опитват да купят време, докато успеят да въведат реално управление и видимост, които надхвърлят простото деклариране на политики. Проблемът не е в самата скорост на агентите, която всъщност е желателна, а в нейната липса на регурация. Когато агентите работят бързо, но без контрол, балансът между скорост и безопасност се превръща в невъзможен компромис.
Всички участници в панела се съгласиха, че безопасното управление на ИИ изисква изграждане на изолирани среди с ясни контролни граници. За Зак Лойд от Warp решението се крие в платформата Warp Oz, която осигурява централизирано управление и видимост върху дейността на агентите в цялата компания [1][2]. Това дава възможност на CISO да виждат по всяко време какви инструменти инсталират и изпълняват разработчиците, предотвратявайки хаотичното и неконтролирано използване на външни модели.
Къде трябва да се изпълняват агентите: Локално или в облака?
Един от основните дебати в панела се фокусира върху физическото местоположение на изпълнение на агентите. Лаптопът на разработчика днес е най-мощната, но и най-изложена на атаки точка в корпоративната мрежа. Поради бума на локалното генериране на код (vibe coding), работната станция на програмиста на практика се превръща в нова производствена среда. Тези среди трябва да се управляват по същия строг начин, по който се управлява реалното производство (production) [1].
Зак Лойд подчерта необходимостта агентите да бъдат премахнати от лаптопите и прехвърлени в контролирана, базирана на облак среда. Това би позволило на CISO да виждат действията на всеки агент в реално време, като елиминира риска от индивидуални инсталации. В момента има ситуации, при които служители в маркетинга изпълняват Cloud Code, а в продажбите — Codex, без знанието на сигурността [1].
Марк Лехнер от Docker изрази различна позиция, твърдейки, че физическото местоположение на машината е без значение, стига да е налице стабилна изолирана среда [1][3]. Ако агентите се изпълняват в пясъчник (Docker Sandboxes) с установена граница на доверие и ясен контрол на входящия и изходящия трафик, рискът е минимизиран. Това позволява бързо прототипиране, експериментиране и иновации директно върху машината на разработчика, DevOps инженера или облачния администратор.
Този подход напълно съвпада с дългосрочната визия на Docker за преносимост на приложенията. Технологията започва в локалната дев среда, след което лесно се пренася в разпределени облачни среди, Kubernetes клъстери или публични облаци. По същия начин AI агентите в бъдеще ще се отделят от човешките оператори и ще работят напълно автономно в същите тези преносими контейнери [1].
Интеграцията на NanoClaw с Docker Sandboxes
За постигане на максимално ниво на сигурност при локално изпълнение, Docker обяви интеграция на своята технология с NanoClaw, разработена от NanoCo [1][4]. Тази интеграция позволява на всеки агент на NanoClaw да се изпълнява в отделна MicroVM (микро-виртуална машина), осигуряваща изолация на ниво операционна система. Този модел минимизира повърхността за атака чрез пълна одитна проследимост на кода с отворен код [1].
Гавриел Коен препоръчва разработчиците да започнат с „тренировъчни колела“ при първите си експерименти с агенти. Това включва използване на нечувствителни и неоторизирани данни за изграждане на базови умения у служителите. Развиването на умения за съвместна работа с ИИ е от критично значение, тъй като технологичният напредък през следващите месеци ще надхвърли сегашните ни представи [1].
Рисковете в автономната верига за доставки
Съвременната софтуерна верига за доставки е постоянна цел за киберпрестъпни групи като ShinyHunters и TeamPCP [1]. Тези нападатели се възползват от транзитивни зависимости и уязвимости в пакетите, като се нуждаят от съвсем кратък прозорец, за да откраднат идентификационни данни. Когато AI агентите автономно избират библиотеки, изтеглят базови изображения и сглобяват код, традиционните методи за сканиране след компилация стават неефективни. Налага се внедряването на нови, превантивни защитни мерки на ранен етап [1].
Участниците в дискусията споделиха следните добри практики за защита на веригата за доставки:
Зак Лойд препоръчва задължително участие на човек в процеса (human-in-the-loop) при избора на външни библиотеки и изграждането на списъци с одобрени (blessed) изображения за агентите [1].
Гавриел Коен съветва да се задава минимална възраст от 7 дни за новопубликувани изображения и да се минимизира броят на използваните зависимости, дори те да изглеждат напълно безопасни.
Марк Лехнер настоява за прилагане на многослойна сигурност за ограничаване на радиуса на поражение, включително използване на SBOM (криптографски спецификации на компонентите), имутабелни тагове и силно ограничени привилегии [1][6].
Марк Лехнер също така съветва разработчиците да приемат, че атаките срещу веригата за доставки ще продължат, и да делегират риска на доверени среди за изграждане, осигуряващи изчистени изображения [1].
MCP (Model Context Protocol) и централизираното управление
Въвеждането на Model Context Protocol (MCP) позволява на големите езикови модели (LLM) да взаимодействат директно с външни бази данни и софтуерни инструменти. Това обаче изисква строги правила и контрол на достъпа с цел управление на рисковете [1]. Гавриел Коен подчерта нуждата от версионен контрол, управление на пароли и изграждане на „златни хранилища“ с проверени инструменти.
Зак Лойд от своя страна се застъпи за централизирано управление на MCP сървърите, за да се избегнат индивидуални зависимости от инструменти и да се гарантира принципът на минимални привилегии.
За да реши този проблем, Docker предостави с отворен код инструмента Docker MCP Gateway [1][5]. Той служи като централен контролен пункт (chokepoint) между ИИ агентите и външните API системи. Всяка заявка се автентифицира, оторизира и записва в системния лог, преди да достигне до крайната цел. Това прави правилата за сигурност задължителни за изпълнение, а не просто препоръчителни, давайки на CISO пълен контрол [1].
Вградено или насадено управление
Дискусията завърши с важно предупреждение от Мориа Хара. В рамките на следващите шест месеца почти всяка компания ще внедри AI агенти в мащаб в своите ежедневни процеси. Ключовият фактор за успех ще бъде дали управлението е заложено от самото начало на процеса (by design), или ще бъде добавено впоследствие като палиативна мярка след първия голям инцидент [1].
Лидерите по сигурност трябва да направят ясен избор още днес дали да изградят здрава основа за растеж, или да се изправят пред неизбежните последствия на неконтролираната разработка.
Източници:
[1]: Agentic AI Needs Guardrails, Not Guesswork - Docker Blog
[2]: Warp Oz Platform - Secure Coding Agents
[3]: Docker Sandboxes Product Page
[4]: Secure Agent Execution: Integrating NanoClaw with Docker Sandboxes - Docker Blog
[5]: Docker MCP Gateway Open Source Secure Infrastructure - LinkedIn Pulse