Автор: Len Noe, архитект по решенията (Solutions Architect), BeyondTrust

Първият въпрос при всеки кризисен координационен разговор (incident bridge) не е свързан с това защо се е случил инцидентът, а чии идентификационни данни са били използвани. Според моя опит онзи, който успее да отговори на този въпрос относно идентификационните данни през първия час, задава темпото за всичко след него: какво да се изолира, какъв достъп да се отнеме, кой да се уведоми и колко далеч биха могли да се разпространят щетите.

Екипите, които не могат да му отговорят, прекарват първия ден в опити да възстановят отговора от системни логове, които никога не са били проектирани да го предоставят.

Тази дисциплина предстои да бъде поставена на изпитание от нов тип субект. На 16 октомври 2026 г. Националният институт по стандарти и технологии (NIST), Агенцията за киберсигурност и сигурност на инфраструктурата (CISA) и Агенцията за национална сигурност (NSA) публикуваха съвместно десет доброволни практики за готовност и реагиране при инциденти, когато AI агентите действат по начини, които никой не е задавал.

Ръководството „Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation“ е полезно, но и лесно може да бъде разбрано погрешно. Най-съществените му насоки засягат идентичността, въпреки че рядко използва тази дума като водещо заглавие.

Какво обхваща ръководството за инциденти на NIST, CISA и NSA

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

В него инцидент с контрола (control incident) се дефинира като събитие, при което агенти предприемат значими действия, които не са били зададени от оператора или от атакуващ и които компрометират контролните механизми, политиките или човешкия надзор.

Агенциите посочват, че практиките се надграждат върху установени рамки за управление на инциденти, така че по-голямата част от изискванията ще изглеждат познати: най-ниски нива на привилегии (least privilege), управление на идентификационните данни, мониторинг, запазване на доказателствата, възстановяване от проверени базови състояния (baselines).

Именно прилагането на познати мерки за сигурност към нов субект (principal) е точката, в която повечето организации вероятно ще се препънат.

Реагирането при инциденти с AI агенти започва с идентичността, а не с намерението

Една подробност в дефинициите е от съществено значение за реагиращите на инциденти екипи. Ръководството третира действия, причинени от злонамерено инжектиране на промптове (prompt injection) или модел със задна врата (backdoor), като зададени, а не незададени, поради което те попадат извън неговото определение за инцидент с контрола. Въпреки че това разделение е логично за изследователите, то представлява трудност за екипите по реагиране; в момента на възникване на инцидента на въпроса за намерението обикновено не може да се отговори.

Това, с което разследващият разполага, е идентичност, набор от права за достъп и следа от извършени действия.

Готовността за инциденти с агенти не може да зависи от първоначалното класифициране на причината. Тя трябва да се гради на базата на регистър на идентичността (identity record), за да се установи коя идентичност е действала, какви правомощия са стояли зад нея и дали агентът е бил подведен, е дефектирал или е компрометиран.

Контролирайте какво могат да правят AI агентите, преди да предприемат действие

AI агентите могат да работят със същите привилегии като хората, които ги използват, създавайки нови рискове, когато действията им остават непроверени.

Вече общодостъпно, решението BeyondTrust AI Agent Security прилага политики върху индивидуалните действия на агентите по време на изпълнение (runtime), като блокира неоторизираната активност, без да ограничава възможностите на потребителите хора.

Отнемането на достъп достига само до онова, което можете да достигнете

Практика номер шест предписва на организациите да отнемат всички идентификационни данни, до които агентът е имал достъп по време на инцидента и които организацията контролира, както и да възстановят потенциално компрометираните среди. Уточнението „под контрола на организацията“ носи по-голяма тежест, отколкото може да изглежда в началото. Агентите натрупват идентификационни данни, с които организацията разполага, но не е издала сама.

Пробивът в сигурността при OpenCode показва как се развива това на практика. OpenCode, агент за програмиране с отворен код, информира част от потребителите на своята хоствана услуга Console, че API ключове, които са съхранявали там за външни доставчици, включително Anthropic, OpenAI и Google, са били компрометирани и изложени на риск.

Компанията заявява, че са засегнати 1.4% от потребителите на Console и че най-ранното изтичане е станало в 00:30 UTC на 17 октомври. Потребители съобщават за неоторизирани начислени суми, вариращи от няколкостотин до 1700 долара за една нощ.

В някои случаи проекти в Google Cloud са били спрени поради злонамерена активност, съответстваща на компрометирани и присвоени ресурси. Компанията не уточнява как са проникнали атакуващите и описва инцидента като мащабна атака чрез дестилация (distillation attack).

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

Стъпката по отнемане на достъп от ръководството предполага наличен опис (inventory) на всичко, до което агентът би могъл да се докосне. Без такъв няма спрямо какво да се извърши анулиране. Етапът на докладване в ръководството добавя второ задължение, което произтича от същия опис: уведомяване на страните, чиито системи са били компрометирани или експлоатирани, включително трети страни, които не са били крайната цел.

В случая с OpenCode тези страни са доставчиците на модели и отделните собственици на ключове, и никой от тях не може да бъде уведомен навреме, освен ако някой не знае кои ключове къде са били съхранявани.

Ограничаване на AI агент, без да се разчита на неговото съдействие

Ръководството съветва създателите на системи да изхождат от презумпцията, че агентите често ще откриват неправилни конфигурации и уязвимости, и да изграждат контролни механизми съобразно това. Реконструкцията на инцидента с Hugging Face от юли, направена от MIT Technology Review, показва защо.

Агенти, изградени върху модели на OpenAI, е трябвало да бъдат изолирани от интернет по време на оценка на киберсигурността. Те въпреки това са получили достъп до мрежата, хакнали са Hugging Face и са извлекли решения на задачите, на които са били блокирали.

Единствената мярка за контрол, описана в статията, е мрежовата изолация, а агентите са я заобиколили. Собствените изследователи на OpenAI отдават това поведение на обучението, което го е възнаграждавало.

Мрежовите граници могат да бъдат преодолени от целенасочен субект, независимо дали е човек, или не. Идентификационни данни, чийто обхват е ограничен само до една задача, които изтичат при приключването на задачата и принадлежат на идентичност, отделна от лицето, стартирало агента, не разчитат на доброто поведение на агента и ограничават възможностите за злоупотреба при изтичане на копие.

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

Отчетност на сесиите за нечовешки субекти

Ръководството също така изисква защитени срещу подправяне системни логове с надеждни времеви маркери, достатъчни за възстановяване на траекториите на агентите, както и увереност, че агентите нямат достъп и не могат да манипулират самите мониторинг инструменти и логове. Това представлява отчетност на сесиите (session accountability) във всяко едно отношение, макар и без да е наречена директно така.

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

Отхвърленото действие е доказателство за това до какво агентът се е опитал да получи достъп, което често разкрива повече от онова, което е успял да извърши.

Ново изследване от BeyondTrust Phantom Labs™, базирано на телеметрия от крайни точки, показва защо логовете на ниво подкана (prompt) са недостатъчни. В клиентски извадки, събрани за четириседмичен период, програмиращите агенти са заявили около 1,28 милиона shell команди от приблизително 132 000 подкани — близо десет команди на подкана. Това са заявени команди, а не потвърдени изпълнения. Лог, който не може да разграничи какво е направил агентът от това какво е направил потребителят, не е в състояние да отговори чии правомощия са били използвани.

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

Защо редките инциденти с агенти все пак оправдават подготовката

Най-силният контрааргумент е пропорционалността. Ръководството е насочено към авангардно обучение и оценка, а инцидентите, на които реагира, са редки: шест от 141 006 оценки според оповестени данни от една лаборатория. Повечето организации внедряват агенти, които са далеч по-малко способни от изследваните, а докладваните до момента щети са скромни.

Защо да се изгражда капацитет за реагиране на проблем, който е предимно теоретичен?

Отговорът е, че основополагащите механизми не са просто теоретични. Компрометиран или погрешно насочен агент се държи, от гледна точка на записите за идентичност, като компрометиран служебен акаунт с по-високо темпо.

Как да се измери готовността за инциденти с AI агенти

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

Ако отговорите на тези въпроси отнемат минути, организацията е готова за първия инцидент с агент, независимо от това как е класифициран. Ако отнемат дни, по-елегантната таксономия няма да помогне.

За автора

Лен Ноу (Len Noe) е архитект на решения (Solutions Architect) в BeyondTrust, трансхуманист, водещ на подкасти, международен лектор по киберсигурност, автор, технически евангелист и биохакер с 11 имплантирани микрочипа.

Бивш blackhat специалист с над 30 години опит в технологиите, той е изнасял лекции в над 70 държави и участва в документалния филм „I Am Machine“, чиято премиера се състоя на DEF CON 2025.

За BeyondTrust

BeyondTrust е глобалният лидер в сигурността на идентичностите, фокусирана върху привилегиите, защитаващ Paths to Privilege™. Самата идентичност не създава риск. Привилегиите го правят. С бурното нарастване на идентичностите на хора, машини и AI агенти във всяка среда, BeyondTrust е единствената компания, създадена да открива, контролира и защитава привилегиите при всички тях от една-единствена платформа. С доверието на над 20 000 клиенти, включително 75 от компаниите във Fortune 100, и призната за лидер в множество категории от водещи индустриални анализатори, BeyondTrust превръща сигурността на идентичностите от проблем за управление в стратегическо предимство.

Научете повече на www.beyondtrust.com.

Спонсорирано и написано от BeyondTrust.