В Salesforce Agentforce препоръчителният начин агент да реагира на събития е чрез Flow: създава се запис или се обновява казус (case), след което Flow предава данни към системните указания (prompt) на агента. Отделно, функционалностите Email-to-Case и Web-to-Case превръщат входящите клиентски съобщения в записи на казуси — по този начин авиокомпаниите и хотелите организират приемането на клиентски запитвания. И двете функции са стандартни, документирани и работят според проектния си замисъл. Свързани заедно обаче, те създават следния път:
публичен интернет → имейл → запис на казус → указания към агента → действие на агента → коментар по казуса → изходящ отговор
По този начин неавтентикиран външен потребител получава директен достъп до инструкциите на вътрешен агент, а отговорът на агента излиза през същата врата. Нищо не е било конфигурирано неправилно. Констатацията, документирана от изследователи през август 2026 г., е ясен пример за това как агентите, внедрени в съществуващи платформи, се провалят: чрез заобикалящото ги приложение, а не поради самия модел в тях.
Рискът е в приложението, а приложението е нещото, което никой не е преразгледал
Кои входящи функции са активирани, кои тригери се задействат, кои обекти са достъпни за гост-потребители, коя автоматизация предава ненадеждни данни и къде, както и коя версия на модела агентът тихо извиква на заден план: това са променливите, които решават дали веригата в Agentforce е просто досада в опашката за поддръжка, или изтичане на данни. Оценката на риска от доставчика, извършена еднократно при покупката, не вижда нито един от тези фактори, защото агентът не е съществувал при покупката. Филтър за указания (prompt filter), наблюдаващ входящите данни на агента, не знае, че даден вход произхожда от непознат, тъй като филтрите за указания не разбират логиката на Email-to-Case.
Затова защитата на наследен агент означава хост приложението му да бъде разбрано на нивото, на което го разбират собствените му администратори. Тази дълбочина е единственото нещо, което липсва както на въпросниците, така и на скенерите. Кампанията City-Forum — активна глобална операция за кражба на данни срещу инстанции на Salesforce и ServiceNow, действаща от март 2025 г., беше открита точно в тази зона: пропастта между възможностите на платформите и конфигурациите, които предприятията реално използват.
Създателите се множат, а някои от тях са самите агенти
Платформите направиха създаването на агенти толкова достъпно, колкото правенето на презентация. Маркетинговият отдел създава агент за извличане на отчети за продажбения пайплайн. Финансовият отдел създава такъв за съпоставяне на фактури. Всеки от тях използва правата за достъп на своя създател, защото точно това го прави полезен. Докато нерегламентираният изкуствен интелект (Shadow AI) представляваше служител, поставящ данни в чатбот, то сенчестите агенти (Shadow agents) са правата за достъп на този служител, работещи автономно и мултиплицирани върху всичко, до което някога му е бил предоставен достъп.
Все по-често самите агенти създават други агенти. Агент за програмиране, включен в комуникационен канал, може да генерира структура и да внедри друг агент толкова лесно, колкото отваря pull request; оркестрационна платформа стартира подагенти за разпределяне на задача — всеки със собствени връзки и нито един със собствена проверка за сигурност. Всеки модел за управление, който предполага, че зад заявката за всеки агент стои човек, вече тихомълком е остарял.
Защо управлението продължава да произвежда само документи
Попитайте голямо предприятие за управлението на AI агенти и отговорът обикновено е документ: политика за приемлива употреба, ежемесечен комитет, набор от принципи, които никой не оспорва и нищо не налага. Задайте обаче оперативния въпрос — колко агента работят в момента, до какво имат достъп и кой е собственикът на всеки от тях — и документът няма да знае отговора.
Списъкът OWASP Agentic Skills Top 10 описва най-отчетливата форма на тази празнина в своята категория „Липса на управление“ (No Governance): умение (skill), внедрено и управлявано в платформа на трета страна, е недостижимо за външни скенери (OWASP Agentic Skills Top 10 whitepaper, ast10-top10-whitepaper-2, публикуван на owasp.github.io). Инструментите, които предприятието насочва към проблема отвън, не могат да видят средата, в която живеят повечето агенти. Управлението се проваля най-често, защото правилата се пишат преди екипът по сигурност да може да види активите, за които тези правила се отнасят.
Архитектурният стек отдолу нагоре с тест за всеки слой
Работният ред е отдолу нагоре и всеки слой е предварително условие за слоя над него. Практичен начин да проверите дали дадена програма работи реално е прилагането на оперативен тест на всяко ниво.
| Слой | Какво трябва да осигури | Оперативният тест |
|---|---|---|
| Откриване (Discovery) | Непрекъснато обновяван опис в конфигурациите на приложенията, предоставените OAuth права, мрежата, крайните точки, метаданните на имейлите и браузъра | Дали откритият брой надвишава в пъти списъка, поддържан от ИТ отдела? Ако не, процесът на откриване не достига до местата, където реално съществуват агентите. |
| Позиция на сигурността (Posture) | Свързаните с агенти настройки на всяка платформа, съпоставени с начина, по който трябва да бъдат конфигурирани | Може ли екипът да изброи входящите функции и експозициите към гост-потребители, свързани с тригери на агенти в трите си основни платформи? |
| Идентичност и собственост (Identity and ownership) | Идентичност и определен отговорен собственик за всеки агент, заедно с жизнен цикъл | Изберете агент на случаен принцип. Има ли човек, който да потвърди собственост в рамките на един ден при въпроса „чий е този агент?“ |
| Употреба (Usage) | Кой какво изгражда, през какъв интерфейс и с какви данни | Съществува ли одобрен път, който позволява внедряване на агент на бизнес екип със сигурни настройки по подразбиране, или съществува единствено забрана? |
| Контроли върху агентите (Agent controls) | Минимални привилегии според реалната необходимост, одобрение и поставяне под карантина на нови агенти, нива на риск според пълния контекст на всеки агент | Дали една и съща констатация за агент в изолирана среда за разработка и за агент с директен контакт с клиенти показва различна степен на критичност? |
| Среда за изпълнение (Runtime) | Инспекция и намеса в реално време | Захранва ли се от петте слоя по-горе, или е внедрена първа и прилага мерки „на сляпо“? |
Цената на съответствието само на хартия
Санкциите по Закона за изкуствения интелект на ЕС (EU AI Act) имат тежестта на тези по GDPR: до 35 милиона евро или 7% от глобалния годишен оборот за забранени практики и до 15 милиона евро или 3% за други нарушения. Всяка регулаторна рамка, свързана с него, предполага, че описаният по-горе стек вече съществува. GDPR вече показа какво се случва, когато това не е така. British Airways (20 милиона паунда) и Marriott (18,4 милиона паунда) не бяха глобени заради несъвършени политики — всеки има несъвършени политики. Те бяха глобени, защото съответствието съществуваше само на хартия и не можа да бъде доказано оперативно пред регулаторите. Практика на управление, изградена отдолу нагоре, генерира тези доказателства като страничен продукт: инвентара, собствениците, конфигурациите, историята на прегледите.
Някои платформи са проектирани да осигурят точно такъв отчет. Водещ пример е Reco, която открива агенти през множество гледни точки, включително такива, които никога не използват SSO, и присвоява рисков профил на всеки от тях, преди върху него да бъде приложена каквато и да е политика.
Веригата в Agentforce, описана в началото на тази статия, не е експлойт. Тя е конфигурация, а конфигурациите подлежат на управление, стига някой да може да ги види. Глави от 1 до 3 на „Into the Expanse“ разглеждат подробно тази промяна, трите вектора за стартиране и цялостната практика за управление: https://www.reco.ai/agent-ecosystem-security