Екип по сигурност на приложенията (AppSec) може да насочи ИИ агент, работещ с модел с общо предназначение, към собствените си уеб приложения с минимална първоначална настройка. Вярно е, че моделът генерира атаките. Но всичко, което прави тези атаки безопасни за изпълнение срещу производствена среда и реално полезни за предприемане на действия след това, се намира в рамката за контрол и изпълнение (harness) около модела. Именно в тази рамка се крие същинското инженерно предизвикателство при пентестването с ИИ. Инцидентът със сигурността в Hugging Face, оповестен от OpenAI през юли, показа какво се случва, когато тази рамка се пропука, дори в рамките на среда за оценка на OpenAI, създадена специално за изолиране на агентите.

Защо всяка мярка за контрол изисква прецизно инженерство

Нека разгледаме по-подробно различните етапи на атаката и ролята, която ИИ агентите могат да поемат в тях

Обхват (Scope)

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

Идентификационни данни

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

Инжектиране на подкани (Prompt Injection)

Всяка страница и всеки отговор от API, които агентът чете – включително скрити полета, метаданни и коментари, които обикновеният потребител никога не вижда – могат да носят съдържание, въведено от всеки, който има право да публикува в приложението. Един-единствен потребителски отзив за продукт е достатъчен за внедряване на злонамерени инструкции. OWASP определя инжектирането на подкани като водещ риск за приложения с големи езикови модели (LLM) и отбелязва, че към днешна дата не съществува надеждна превенция. Архитектурният въпрос не е дали моделът ще бъде подведен, а колко щети може да нанесе, ако и когато това се случи. Това опира до две неща: колко строго е ограничено всяко действие и кои действия изискват допълнителен преглед и одобрение от човек. Нито едно от двете не е просто за реализация. OWASP предупреждава, че умората от постоянни одобрения влошава преценката на проверяващите при големи обеми, така че пренасочването на всичко към човешка намеса просто премества точката на срив по-нататък по веригата.

Доказателство за уязвимост

През октомври 2026 г. Google спря да приема доклади за продуктови уязвимости в програмата си за възнаграждаване на открити бъгове в отворен код след рязък скок на автоматизирани подавания, мнозинството от които според компанията са били невалидни. Констатация, която разработчикът не може да възпроизведе, е просто поредният билет за затваряне. Създаването на доклад, по който си струва да се работи, изисква изпълнение на експлойта, регистриране на засегнатите ресурси и пакетиране на резултата така, че всеки да може да го възпроизведе повторно – всичко това в границите на зададените останали мерки за контрол.

Нищо от това не се изгражда еднократно. Всяко обновяване на модела може да промени поведението на агента, а всяка нова версия променя приложението, чиято сигурност се тества. А около контролните механизми функционират системите, от които зависи един агент в реална среда: автоматично тестване при промени в кода, насочване на констатациите към отговорните разработчици, строг контрол върху данните на клиентите, изпращани към доставчика на модела, както и свързване на откритията на агента в приложението с останалата част от ИТ инфраструктурата.

Във всички тези аспекти моделът е един и същ: ИИ моделът разсъждава какво да опита, а детерминистичен код решава какво реално да се изпълни, записва го и го спира при необходимост.

Как Pentera Apps внедрява рамката за контрол

Това разделение между логическо разсъждение и изпълнение е подходът, възприет при изграждането на Pentera Apps. Вместо да се позволи на ИИ моделът да изпраща заявки директно към дадено приложение, Pentera Apps съчетава изкуствен интелект, който решава какво да тества, с детерминирана рамка за контрол, управляваща изпълнението. Всяко действие се записва в системните журнали и всеки тест може да бъде поставен на пауза или прекратен по всяко време. Това е същата дисциплина за безопасност, която Pentera прилага при тестове в реални производствени среди от близо десетилетие за хиляди глобални клиенти.

Рамката осигурява и доказателствената част. Всяка констатация се предоставя с възпроизводим скрипт за експлойт, оценка по CVSS 3.1 и съпоставка с CWE, така че разработчиците сами да могат да възпроизведат атаката, вместо да разчитат единствено на доверие. След като бъде инсталирана корекция за сигурност, същата атака може да бъде изпълнена отново, за да се потвърди отстраняването на уязвимостта. Тестовете се изпълняват при поискване или по график, като предстои въвеждане на тестове, задействани от промени в CI/CD процесите, така че верификацията да върви паралелно с разработката.

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

При тестването за проникване с ИИ агенти рамката за контрол определя крайните резултати. Pentera Apps я предлага вградена, така че екипите по сигурност да получават валидирани констатации, без да се налага сами да изграждат подобна среда.

Бележка: Тази статия е компетентно съставена и предоставена от Асаф Регев, вицепрезидент по продуктов маркетинг в Pentera. Екипите по сигурност могат да заявят ранен достъп до Pentera Apps за автономно тестване за проникване в уеб приложения.