Почти всяка презентация за сигурност на агенти днес завършва с едно и също обещание: продуктът спира злонамереното действие в реално време. Обещанието важи за един вид агенти — тези, чийто трафик преминава през шлюз (gateway), който предприятието притежава. Повечето агенти изобщо не се докосват до такъв.
Един скорошен случай показва как изглежда тази празнота на практика. Служител помолил AI асистент да задейства автоматизация за масово изпращане на имейли. Автоматизацията достигнала лимит за брой получатели според политиката за сигурност и се провалила, затова асистентът, който бил свързан и с личната пощенска кутия на служителя, предложил вместо това да изпрати пакета оттам. Служителят одобрил, без да осъзнае, че асистентът е напът да заобиколи официално разрешената система. Неизвестен брой външни получатели получили имейл от личен акаунт, вместо през одобрения канал.
Не е имало пробив в защитата на модела (jailbreak). Асистентът е направил точно това, за което е бил създаден, а решението не е било повторно обучение на модела. То се е състояло в едно-единствено правило по време на изпълнение (runtime), което блокира всеки опит за достигане до повече от петдесет външни домейна и обяснява на потребителя какво се кани да направи инструментът. За да се знае къде да се приложи подобно правило, е необходимо да се вижда кои агенти съществуват, към какво са свързани и как изглежда нормалното поведение за всеки от тях. Тази видимост е частта, която повечето презентации за сигурност по време на изпълнение пропускат.
Средата за изпълнение е приложението, а не каналът
Най-големите премиери на агенти през годината поставиха агентите вътре в платформи, които купувачът не притежава. Claudeforce изпълнява Claude в рамките на границата на доверие на Salesforce, Claude Tag живее в Slack, а Copilot — в Microsoft 365. Workday, откъдето твърдят, че изкуственият интелект вече формира над една четвърт от стойността на новите им годишни договори, изпълнява своите агенти вътре в Workday. Във всеки от тези случаи инструментите на агента са функциите на приложението, знанията му са данните на приложението, а правата му за достъп са моделът за права на самото приложение.
Един шлюз може да инспектира само това, което преминава през него. Агент, който работи вътре в Salesforce, задейства се от Flow, чете CRM записи и пише коментари по казуси, не изпраща нищо през точка за инспекция; същото важи и за агент на Copilot, който сглобява документ от SharePoint, или за вграден в Slack агент, който чете години история на каналите. Класацията OWASP Agentic Skills Top 10 описва тази празнота като сценария „недостъпно умение“ (unreachable skill) под код AST09, Липса на управление (No Governance): функционалност, внедрена в платформа на трета страна, където не може да проникне външен скенер.
Индустрията за сигурност вече е правила подобна стъпка преди. Някога защитните стени инспектираха пакетите по източник, дестинация и порт, докато приложенията не спряха да се съотнасят еднозначно към портове и злонамереният трафик не започна да изглежда идентичен с легитимния. Точката на инспекция се премести нагоре по стека към приложението, където се намира самият сигнал. Средата за изпълнение на агентите се нуждае от същата промяна, но с усложнение, пред което предишната никога не се е изправяла: приложният слой принадлежи на някой друг. Стратегия, базирана само на шлюзове, защитава агентите, които предприятието хоства само, а те са най-малко на брой и растат най-бавно.
Точката на инспекция също е мишена
През март 2026 г. атакуващи компрометираха LiteLLM — шлюза с отворен код, който маршрутизира трафика на агентите към доставчиците на модели. Злонамерените пакети бяха активни около четиридесет минути, а по-късно CloudSEK оцени излагането на риск на повече от 2,500 организации. LiteLLM е точно такъв компонент, какъвто екип, загрижен за сигурността, добавя целенасочено, за да наблюдава AI трафика, което превърна самата точка на инспекция във вектор на атаката.
Нищо от това не е аргумент срещу шлюзовете. То е аргумент срещу третирането на който и да е отделен компонент като цялостна стратегия. Шлюзът е просто още един софтуер във веригата на доставки, със собствен процес на издаване на версии и зависимости, и концентрира точно този трафик, който атакуващият желае. Когато прилагането на правилата за сигурност е споделен компонент, неговият отказ е споделен отказ.
Присъда за милисекунда се нуждае от памет
Решенията по време на изпълнение се вземат за милисекунди, а трудните случаи са тези в сивата зона. Агент за поддръжка, който извлича клиентски данни, може да си върши работата или да ги ексфилтрира. Агент за програмиране, който чете хранилище с код, може да събира контекст или да извършва разузнаване. Финансов агент, който създава OAuth връзка, може да извършва интеграционна работа или да прави първия ход за компрометиране. Действието само по себе си не носи присъдата. Идентичността и собственикът на агента, неговите права, нормалното му поведение, чувствителността на данните, дестинацията и веригата за делегиране зад заявката са тези, които я определят.
Веригите вдигат летвата. Контролът, който оценява само последната стъпка (last hop), вижда оторизиран агент, извършващ действие, за което има разрешение, и пропуска факта, че правомощието е пристигнало по верига, която никой не е одобрил. Оценяването на цялата верига по време на изпълнение означава тя вече да е известна, а това знание не може да бъде сглобено за една милисекунда. Прилагането на контрол без тази карта е като ръководител на полети с радиостанция, но без радар: команди могат да се издават, но липсва представа кой самолет накъде се е насочил.
Как изглежда реалната сигурност по време на изпълнение на агенти
Оттук следват три характеристики. Прилагането на контрола трябва да се намира там, където са агентите — в няколко наблюдателни точки като вградени в платформата куки (hooks), контроли на ниво API, MCP слоя, браузъра и крайната точка, а не в един-единствен шлюз. Всяка присъда трябва да се изчислява спрямо динамична карта на идентичността, правата, свързаността и активността (IPCA), плюс чувствителността на данните и делегирането, което превръща сивите случаи в обосновани преценки. А менюто с реакции трябва да е по-широко от просто блокиране.
Зрелият контрол е степенуван. Той разрешава доказано доброто, предупреждава там, където обосновката е правдоподобна, заличава чувствителната информация (redacts), когато проблемът е в самите данни, и блокира, когато веригата е враждебна. Той насочва действията с най-висок риск към човек и поддържа авариен прекъсвач (kill switch) за доказано компрометиран агент, който го спира временно, отнема предоставените му права и запазва следите за одит. Всяка присъда се записва в лог с пълния ѝ причинно-следствен път, защото както прегледът на инцидента, така и регулаторът искат едни и същи пет неща: агента, веригата, данните, дестинацията и политиката.
Не купувайте крайното състояние
Дан Лахав от Irregular нарича тази грешка „заблудата на крайното състояние“ (end-state fallacy): допускането, че свойствата на евентуалното равновесие важат за прехода, който реално тече в момента. При закупуването на решения за сигурност по време на изпълнение това е вярата, че директният (inline) контрол в крайна сметка ще вижда всичко, така че не толкова привлекателните базови слоеве могат да бъдат пропуснати. Това крайно състояние не се предлага тази година от нито един доставчик на каквато и да е цена. Покритието по време на изпълнение е частично, а платформените интеграции (hooks) се появяват неравномерно.
Това, което може да бъде закупено още сега и навсякъде, е стекът, от който зависи защитата по време на изпълнение (runtime): откриване от всяка гледна точка, управление на състоянието на сигурността на всяка платформа, идентичност и собственост за всеки агент и контекст за всяко решение. Тогава всяка точка на прилагане на контрол, която се отвори по-късно, се вписва директно в карта, която вече знае как изглежда нормалното състояние. Пълната аргументация за това къде е мястото на принудителния контрол се намира в „От AI Runtime към Agent Runtime“ (From AI Runtime to Agent Runtime).
Първите деветдесет дни, по ред
Последователност, която следва стека от долу нагоре, изглежда по следния начин.
| Период | Работата | Как да разберете, че е реално |
|---|---|---|
| Седмици 1 до 2: установете броя | Свържете това, което вече работи (доставчика на идентичност, основните платформи, мрежовите инструменти, имейл слоя) и оставете откриването да действа от всяка гледна точка едновременно. Без внедряване на шлюзове, без инсталиране по крайни точки, без пренасочен трафик. | Времето до първите резултати е дни, а не тримесечия. Откритата популация е няколко пъти по-голяма от списъка, който ИТ отделът поддържа. |
| Седмици 3 до 6: имена и конфигурации | Всеки открит агент получава конкретен човек за собственик или бива спрян. Конфигурационният дълг се приоритизира, като се започне от платформите, хостващи най-достъпните агенти: излагане на гост-потребители, функции за прием на данни, свързани със задействане на агенти, правила за споделяне отпреди три години. Защитните ограничения се поставят първо върху ориентираните към клиенти и привилегированите агенти. | Човек вдига ръка в рамките на един ден, когато бъде попитано „на кого е това?“. |
| Седмици 7 до 12: опашката и пътят | Контекстно-осъзнато категоризиране на риска по нива, така че прегледът да започва с агента, който действително може да навреди на бизнеса, регулярни прегледи за минимални привилегии на най-високото ниво и одобрен маршрут за бизнес екипите да внедряват агенти със сигурни настройки по подразбиране. | Всяка критична оценка може да бъде обяснена като верига, а на създателите се предлага път напред, вместо само блокиране. |
Пътят за разрешаване и подкрепа е важен, защото създателите на агенти ще действат така или иначе. Блокирането учи на заобикаляне на правилата, докато добрият път учи на съответствие.
Екипите могат да определят къде се намират чрез тест на четири нива. „Слепи“ (Blind) означава, че трите въпроса на борда (колко агента съществуват, до какво имат достъп и кой носи отговорност) нямат актуален отговор. „Инвентаризирани“ (Inventoried) означава, че популацията е открита, преброена и се обновява непрекъснато. „Управлявани“ (Governed) означава, че всеки агент има собственик, състоянието на сигурността се управлява спрямо базови линии и рискът е категоризиран с контекст. „Инструментирани“ (Instrumented) означава, че контролът действа там, където работят агентите, със степенувани решения и пълен причинно-следствен път във всяко известие. Повечето предприятия са на първото ниво, каквото и да пише в документа с политиките, а доставчик, продаващ инструментариум на „сляпа“ организация, продава контрол, който може да действа, но не може да преценява.
Седем въпроса, които отсяват доставчиците
Всяка презентация на доставчик днес говори за сигурност на агентите. Тези въпроси отделят доставчиците, които са изградили решение за проблема, от тези, които просто са преименували свой продукт, тъй като на всеки от тях се отговаря лесно и добре само ако подлежащата архитектура съществува.
| Попитайте | Как изглежда добрият отговор |
|---|---|
| Можете ли да откриете агенти, които никога не се удостоверяват чрез SSO? | Да, през няколко независими гледни точки, всяка от които вижда нещо, което останалите не могат. |
| За агент, който сте оценили като критичен, покажете ми веригата. | Пълен, достижим път на атака (възможност, достижимост, актив), който анализаторът може да провери, а не обобщена оценка. |
| Една и съща констатация води ли до различна степен на сериозност при различните агенти? | Да, демонстрирано върху агент в изолирана среда и такъв, ориентиран към клиенти. |
| Когато един агент извиква друг, можете ли да реконструирате веригата на делегиране? | Първоначалният заявител, всяка междинна стъпка и крайното действие. Одитна следа, която започва от последния агент, не е истинска одитна следа. |
| Какъв контекст захранва решението за разрешаване, блокиране или редактиране (скриване на данни)? | Идентичност, права за достъп, делегиране и чувствителност на данните, а не само самият промпт. |
| Какво се случва със защитата ми, ако вашият компонент за прилагане на контрол бъде компрометиран? | Конкретен отговор, който директно разглежда инцидента с LiteLLM. |
| Колко време ще мине, докато видя реалния си инвентар от агенти? | Дни. Тримесечие означава съвсем различен продукт. |
Платформите, изградени около цялостната карта, а не около отделния агент, могат да отговорят на тези въпроси директно. Един водещ пример е Reco, чийто Reco Graph свързва всяка човешка и нечовешка идентичност, приложение, право за достъп и действие на агент в единен изглед в реално време, така че обхватът на достъп, а не конфигурацията, е единицата за анализ. Една измерена програма, приложила този подход, повиши резултата си за състоянието на сигурността от 47% на 91% в 21 платформи за 30 дни.
Научете повече за откриването на агенти от Reco на reco.ai/platform.
Пълната деветдесетдневна последователност, самооценката на четири нива и всичките петнадесет въпроса към доставчиците се намират в „Контролният списък за сигурност на агентите: Вашите първи 90 дни“ (The Agent Security Checklist: Your First 90 Days).
Reco е лидерът в сигурността на агентите (Agent Security). Платформата Reco (The Reco Platform) защитава агентите и техните операционни среди там, където се пресичат приложения, идентичности, права за достъп и работни процеси. Тя открива цялата екосистема от трети страни на организацията, приоритизира реалния риск пред обема от известия и отстранява проблеми с прецизност във всяка човешка идентичност, агент, приложение и право за достъп в средата. Изградена е върху Reco Graph, с нови интеграции, доставяни за часове чрез Reco Factory, и предварително изградена разузнавателна информация за агенти и приложения от Reco Library. Лидерите по сигурността в компаниите от Fortune 500 избират Reco, за да въведат ред в разрастването на броя на агентите и верижните реакции, които следват. С повече от 280 интеграции на приложения, над 1000 контрола за откриване и над 1 милион открити агента, Reco обединява сигурността на агентите, управлението на състоянието на сигурността и откриването на заплахи на едно място. Научете повече на reco.ai.
Вижте какво работи във вашата среда. Agent360 е безплатна оценка, която показва кои агенти и приложения са активни, до какво имат достъп и кой ги притежава. Тя работи чрез API само за четене, без инсталиране на софтуер, и връща писмено обобщение за сигурността и приоритизиран план за отстраняване на проблеми в рамките на пет работни дни. Заявете безплатна оценка с Agent360.