Начинът, по който говорим за AI агентите, се променя, а начинът, по който ги внедряваме, изисква още по-фундаментална промяна. Докато по-ранните дискусии се фокусираха върху това колко бързо организациите могат да пуснат в действие агенти и каква производителност могат да обещаят, поредица от скорошни инциденти, включително широко обсъжданото проникване в Hugging Face по време на оценка на агенти на OpenAI, подтикна организациите да проверят дали скоростта не е изпреварила способността за обезопасяване на внедреното. Екипите по сигурност все по-често си задават въпроса до какво може да достигне един агент, след като започне да работи, и дали някой би забелязал това, преди да е станало твърде късно. Колкото и да е изкушаващо да се премине директно към контрол за прилагане на политики и механизми за засичане, първо трябва да обмислите добре ситуацията.

Проучване на Veeam разкрива, че 70% от организациите признават, че работните процеси с AI вече са в контакт с чувствителни корпоративни данни без пълен надзор, а 67% съобщават, че ИТ отделът не може напълно да проследява автономните работни процеси, които служителите изграждат. Нерегламентираният AI (Shadow AI) е само едно от предизвикателствата пред видимостта на AI агентите, но той илюстрира колко бързо и всеобхватно тази фундаментална първа стъпка може да се изплъзне от контрол.

Принципите на Нулево доверие (Zero Trust) могат да подкрепят програма за управление на AI, но само в правилния ред. „Не можете да управлявате това, което не виждате“ е основният принцип най-отгоре в справочника на SANS, Zero Trust for AI Agents: The Security Checklist. Справочникът поставя инвентаризацията пред всеки контрол за прилагане на политики и с право третира това като основополагащо предварително условие. На практика организациите могат да преминат директно към точка за прилагане на политики или схема за оторизация за агент, който няма посочен собственик, няма дефиниран обхват и няма запис в никаква инвентаризация. Този ред на операциите е диагноза за това къде програмите за Zero Trust могат да се провалят. Прокси сървър или слой за оторизация, разположен пред неизвестна популация от агенти, няма реална основа, върху която да налага правила.

Ето три предизвикателства пред видимостта, за които да следите, заедно с последствия, които да обмислите, когато „мислите като червен екип“ (Think Red) от позицията на атакуващ, и решенията, които можете да приложите, когато „действате като син екип“ (Act Blue) като информиран защитник.

Предизвикателство едно: Използването на агенти е нова форма на нерегламентирано ИТ (Shadow IT)

При всяка нова технология внедряването върви напред, а управлението следва по-късно, ако изобщо последва. След като екипите по сигурност забележат тази празнина, първият инстинкт често е превенцията, която може да включва блокиране на неодобрени инструменти, прекъсване на достъпа или просто изключване на всичко непознато. Бюджетът и вниманието се насочват първо към тези процеси, но блокирането на неща, преди някой да има представа за съществуващото, крие риск от спиране на легитимна употреба заедно с нерегламентираните внедрявания. Докато проблемът със Shadow IT е признат и адресиран при други технологии от дълго време, ние все още правим първи плахи стъпки, когато става въпрос за прилагането му при AI.

Мислете като червен екип: Когато агентът на практика е невидим за вас, за атакуващия не е необходимо да пробива почти нищо, за да стъпи стабилно в системата. Скорошен пример в новините беше инцидентът в METR, неправителствената организация, известна наскоро с оценката си на инцидента с Hugging Face. Атакуващ открива личен EC2 инстанс на служител, изпълняващ базирано на интуитивно кодиране (vibe-coded) агентно приложение, след което тривиално заобикаля автентикацията и подтиква агента да предаде своя API ключ за доставчика на модела. В продължение на три седмици киберпрестъпникът използва токени на стойност, еквивалентна на 600 000 долара, тъй като за API ключа не е имало лимит на разходите. Вътрешното табло за управление на METR просто изобщо не е показвало данни за заявки с ограничена честота (rate-limited), а само обемът на токените не е бил достатъчен, за да предизвика тревога.

Действайте като син екип: Облачните технологии преминаха през същите тези трудности на растежа и можем да погледнем към тях за пътя към видимостта. Всяка компания вече има по-строг контрол около облака, като например наблюдение на използването и разходите за AWS/Azure и гарантиране, че неизползваните виртуални машини са изключени или унищожени; но никой все още не прави това за агентите. Третирайте разходите за AI и агенти, заедно с издаването на API ключове, като сигнали за откриване. Финансовият отдел и отделът по доставки са друга гледна точка, която също може да бъде пренебрегната. Публикувайте одобрен път за доставчици, преди да блокирате каквото и да било, така че легитимната употреба да има алтернатива, а що се отнася до оперативния ред, започнете с принципа „първо опознай, после ограничавай“.

Предизвикателство две: Нито една отделна камера не може да улови цялата картина

Дори след като организацията се ангажира с откриването, няма нито една самостоятелна гледна точка, която да ви даде пълната картина на цялата популация. Агентите съществуват в мрежата, на крайната точка, в браузъра и в рамките на SaaS решения, хоствани другаде, като всяка отделна призма оставя големи бели петна.

Трафикът към доставчиците на AI е TLS-криптиран, така че вграденият сензор вижда дестинация и брой байтове, а не промпт, извикване на инструмент или източване на данни, като трафикът често отива към абсолютно същите домейни като легитимните приложения. Мрежовият анализ сам по себе си не може да различи това от всичко останало по линията. Инструментите за крайни точки пропускат AI, вграден в браузъра, а вграденият в SaaS решения AI е невидим и за двете.

Мислете като червен екип: Представете си маркетингов анализатор, който инсталира инструмент за браузър, обобщаващ клиентски записи и изготвящ чернови на изходящи имейли. Инструментите за крайни точки никога не го виждат, тъй като той работи вътре в браузъра. Мрежовият мониторинг вижда само криптиран трафик към домейн, който също така хоства дузина одобрени SaaS продукти. Инструментът и всеки злонамерен субект, който успее да го компрометира, биха могли да разполагат с достъп до CRM система, пълна с чувствителни данни, без никой друг да осъзнава, че инструментът съществува.

Действайте като син екип: Възстановяването на видимостта означава отказ от разчитането на един-единствен източник и вместо това корелиране на разнообразни източници, всеки от които ви дава част от видимостта. Докато трафикът може лесно да се маскира или да се скрие в локални MCP сървъри или CLI инструменти, метаданните могат да ви подскажат, че нещо комуникира с доставчик на модел чрез DNS/SNI, JA4 цифрови отпечатъци и логове от изходящи проксита (egress proxy). Комбинирайте мрежовата си видимост с телеметрия от крайните точки за процеси, API ключове, съхранявани в променливи на средата, или локални среди за изпълнение на агенти. Също така търсете телеметрия на ниво браузър за разширения, помощници на страницата (in-page copilots) и логове от корпоративни браузъри, както и логове за идентичност и SaaS като OAuth разрешения, издаване на API ключове и администраторски конзоли на доставчици. Когато работите за корелиране на всички тези сигнали, те могат да ви осигурят инвентаризация.

LLM шлюз като LiteLLM може да централизира както видимостта, така и управлението, като действа като точка за прилагане на политики, каквато изисква справочникът, но той управлява само агенти, които вече са насочени към него, което връща проблема обратно към липсващата ни инвентаризация. Един шлюз може да контролира агенти, за които знаете, но той не открива тези, за които не знаете.

Предизвикателство три: Одитите трябва да се движат с темпото на това, което одитирате

Традиционните одити и мониторинг са недостатъчни за поддържане на видимост. Годишният преглед може да види само активи, наблюдавани преди една година, което не ви казва почти нищо. Когато отнема секунди за внедряване и клониране на агенти, докато цикълът на преглед приключи, инвентаризацията, която е произвел, вече е неточна. Непрекъснатият мониторинг е най-очевидният отговор, но премахването на човек от този цикъл носи собствен риск.

Мисли като червените (Red Team): Ако дадена организация извършва одити периодично, атакуващ би могъл да се възползва от това, като накара компрометиран агент да създаде краткотрайни клонинги за изпълнение на задача, където всеки клонинг наследява достъпа на родителя, преди да бъде прекратен. Клонингите съществуват точно толкова дълго, колкото да извлекат данни или да извършат други злонамерени дейности, но изчезват, преди редовният преглед да ги забележи.

Действай като сините (Blue Team): Тук няколко промени работят заедно. Можете да имате хора, които наблюдават агентите, и агенти, които наблюдават един друг, така че вашата видимост да не зависи от една точка на отказ. Имайте предвид обаче, че ако автоматизирани системи наблюдават автоматизирани системи, кой носи отговорност? Проверимостта все още се нуждае от конкретно посочено лице, което да отговаря за крайния резултат, независимо какво докладва автоматизацията. Можете предварително да намалите част от риска с портали за качество (quality gates).

Скорошният законодателен натиск в САЩ за въвеждане на аварийно изключване показва, да концепцията за „авариен прекъсвач“ (kill switch) за автономен изкуствен интелект също се приема сериозно. Но не забравяйте нашето предварително условие тук: Аварийните прекъсвачи са смислени само ако знаете какво да изключите, което ни връща отново към видимостта на първо място.

Идентичността на агента е част от това предварително условие и е това, което прави вашите прагове за наблюдение смислени. За да цитирам отново краткия наръчник, не можете да зададете праг за нещо, което не можете да атрибутирате. Дъглас Маккий и аз повдигнахме някои концепции, които могат да бъдат полезни тук в The Monday Brief в Substack: "Достъпът до инструменти на агента трябва да бъде моделиран какъвто е отделен проблем на идентичността и прилагането на политики, а не като разширение на потребителя, внедрил агента. Дайте на всеки агент негова собствена идентичност, обвържете разрешенията с активната задача, ограничете какви данни могат да напускат средата и поставете слой за оторизация между модела и свързаните услуги." Записването на логове (logging) се нуждае от същата промяна — от записване само на подканите (prompts) към регистриране на извикванията на инструменти и действията, които агентът предприема.

Къде поставя това вашата програма

Мястото, където видимостта се появява във вашия ред на операции, е основата за всяка друга стъпка от управлението (governance), която трябва да предприемете. Всяко предизвикателство, разгледано по-горе, се връща до този същ корен: Слой за прилагане, изграден преди да съществува инвентаризация, няма нищо реално, спрямо което да прилага правила. Започнете с откриване (discovery), след това съпоставете източниците на ваше разположение, които могат да покрият част от картината, и изградете непрекъснат мониторинг около всеки агент, притежаващ собствена идентичност. Пълният списък за проверка за сигурност Zero Trust for AI Agents преминава през всичките три нива — инвентаризация и управление, архитектура и прилагане, и откриване и реагиране — в реда, в който са предназначени да се случат.

За по-подробен преглед на тези контроли, присъединете се към мен за SEC530: Defensible Security Architecture and Engineering, Implementing Zero Trust for the Hybrid Enterprise, този декември на SANS Cyber Defense Initiative 2026.

Забележка: Тази статия е експертно написана с принос от Исмаел Валенсуела.