Да — но само онези права, които са необходими за конкретната задача, за възможно най-кратко време и при условия, които могат да бъдат проверени. Ако агентът може да чете, изпраща, променя и изтрива данни, докато задачата изисква единствено да подготви чернова, проблемът не е само в евентуално грешния отговор. Системата е получила повече власт, отколкото ѝ е нужна.
Сигурността на AI агенти зависи не само от това какъв текст генерират, а и от това какви инструменти могат да извикват, с какви идентификационни данни и докъде може да стигне едно действие без намеса. Практическият въпрос е: ако агентът бъде объркан, подведен или просто сбърка, какво му позволява архитектурата да направи?
Какво означава прекомерна автономност
OWASP LLM06:2025 използва понятието Excessive Agency — прекомерна агентност или автономност. Рискът възниква, когато приложението предоставя на езиковия модел прекомерна функционалност, права или свобода за действие спрямо задачата. Това не означава, че моделът непременно има намерение да злоупотреби. Означава, че евентуална грешка или нежелано поведение може да се превърне в реално действие, защото системата му е дала подходящите инструменти и достъп.
Трите измерения са свързани, но различни. Функционалността определя какви операции са налични — например търсене, изпращане на поща или промяна на запис. Правата определят до кои данни и ресурси се отнасят тези операции. Автономността определя дали агентът може да изпълни действие сам, да прави поредица от действия или трябва да спре за проверка. Ограничаването само на едно измерение не е достатъчно: тесен инструмент с прекалено широк достъп пак може да причини щета, както и ограничен достъп, комбиниран с неограничено изпращане към външни получатели.
Полезен принцип е least privilege — най-малки привилегии. Агентът трябва да получи само необходимия достъп, а не удобен набор от права „за всеки случай“. Това включва и ограничаване на броя и обхвата на инструментите. Ако задачата може да бъде изпълнена с четене на определена папка и създаване на чернова, няма добра причина същият агент да може да изтрива файлове или да изпраща произволни съобщения.
Пример: агентът чете документи и изпраща имейл
Представете си вътрешен агент, който намира отговор в документи и го изпраща на служител. За да проектирате контролите, проследете цялата верига: вход → доверие → действие → права → контрол. Тази последователност помага да се види къде възниква рискът, вместо да се разчита единствено на това дали полученият текст изглежда убедителен.
Вход: агентът получава заявка и избира документи, които да използва. Документите са входни данни, а не автоматично надеждни инструкции. Въпросът за правата започва още тук: кои хранилища може да търси, за кои потребители и в какъв обхват? Не е необходимо агентът да има достъп до цялата корпоративна среда, ако задачата е свързана с една конкретна библиотека.
Доверие: системата трябва да различава кой е поискал операцията, какви източници са били използвани и какво е предназначено да бъде споделено. Сам фактът, че агентът е намерил текст, не дава основание той да бъде изпратен на произволен адрес. Достъпът до информация, правото да я използва за отговор и правото да я предаде навън са отделни решения.
Действие: „подготви отговор“ и „изпрати отговор“ не са равностойни операции. Първата създава съдържание; втората променя състоянието извън системата и може да разкрие информация. Затова интерфейсът за инструменти може да предлага създаване на чернова като стандартен път, а изпращането да е отделна операция с допълнителни условия.
Права: вместо широк токен за цялата пощенска кутия, агентът може да работи с ограничено разрешение, което позволява само нужната операция и само в рамките на определена задача. Получателите, обхватът на документите и наличните операции могат да бъдат ограничени от приложението, а не оставени на модела да ги избира свободно. Ако е достатъчно да се изпрати чернова на конкретния потребител, няма нужда агентът да може да изпраща от името на всеки служител до всеки външен адрес.
Контрол: преди изпращане системата може да покаже на упълномощен човек конкретния получател, темата, съдържанието и прикачените файлове. Потвърждението трябва да се отнася именно до това действие, а не до общо съгласие агентът „да свърши задачата“. Ако съдържанието или получателят се променят след одобрението, потвърждението вече не описва действието, което предстои да бъде изпълнено.
Този пример показва защо не е достатъчно да се добави бутон „Одобрявам“. Контролът трябва да бъде свързан с правата, обхвата на данните и точната операция. Повече за разликата между конкретна проверка и формално потвърждение има в материала защо одобрението на конкретно действие не е автоматично ефективен контрол.
Credentials по задача, а не ключ за цялата система
Идентификационните данни — например API ключове, токени или служебни акаунти — са част от границата на сигурността. Ако агентът използва дълготраен credential с широки права, грешка в една задача може да има последствия, които надхвърлят нейния обхват. Освен това става по-трудно да се установи кой е извършил операцията и да се прекрати достъпът, без да се засегнат други процеси.
По-безопасният модел е достъпът да се предоставя през управляван слой, който проверява самоличността, задачата и разрешената операция. Където архитектурата позволява, достъпът следва да е ограничен по обхват, време и ресурс. Credential не трябва да се поставя в подсказка или да се излага на модела като обикновен текст; приложението може да извика инструмента от свое име и да наложи политиката преди изпълнението.
Разделяйте и правата между инструментите. Компонентът за търсене може да има право да чете определен набор от документи, но не и да ги променя. Компонентът за поща може да създава чернови, но да няма право за изпращане, освен когато системата изрично разреши конкретна операция. При промяна на задачата или приключването ѝ достъпът трябва да може да бъде оттеглен, вместо да остава активен без ясна нужда.
Това не е обещание, че тесните права предотвратяват всеки проблем. Те ограничават възможните последствия. Ако агентът направи грешен избор, най-малката привилегия може да означава, че той няма достъп до чувствителния ресурс или не може да извърши необратимото действие.
Одобрение, изходящ трафик и журнал
Одобрението е полезно, когато е смислено и изпълнимо: човекът вижда съществените детайли, има време да ги прецени и може да откаже. За високорискови или трудно обратими операции системата може да изисква отделна проверка, докато нискорисковите и обратими действия се изпълняват автоматично в тясно зададени граници. Принципът нье е „одобрявай всичко“, а да съчетаеш степента на автономност с възможните последствия.
Към това добавете ограничения върху изходящия пренос на данни. Например политиката може да ограничава получателите до одобрени домейни, блокира изпращане на определени категории информация или изисква проверка при прикачване на документ. Такива ограничения трябва да се налагат от приложението или инфраструктурата, а не само да се описват в инструкция към модела. Ограничаването на изходящия трафик намалява част от риска от нежелано разкриване, но не заменя контрола върху самите права и действия.
Журналът трябва да позволява да се възстанови какво се е случило: кой е инициирал задачата, кои инструменти са били извикани, какви ресурси са засегнати, какво разрешение е приложено, имало ли е одобрение и какъв е бил резултатът. Записите трябва да са достатъчни за разследване и одит, без ненужно да съхраняват чувствително съдържание. Предвидете и кой преглежда сигналите, как се откриват необичайни операции и как може да бъде прекратен достъпът. Наличието на лог, който никой не наблюдава, само по себе си не е ефективен контрол.
Как да проверите дизайна
Преди внедряване проверете правата от гледна точка на задача, а не на удобство за разработка. За всеки инструмент задайте конкретни въпроси:
- Кое точно действие може да извърши агентът, върху кои данни и чие име използва?
- Може ли операцията да бъде заменена с по-ограничена, например чернова вместо изпращане?
- Кой компонент налага зөвшөөрението — серверът и инструментът или само текстовата инструкция?
- Кои операции изискват одобрение, какви детайли вижда одобряващият и какво става, ако действието се промени?
- Може ли достъпът да бъде ограничен по време и оттеглен, а действията — проследени?
След това тествайте не само нормалния сценарий, а и отказите: недостъпен ресурс, изтекъл credential, отказано одобрение, непознат получател и опит за операция извън разрешения обхват. Очакваното поведение трябва да е безопасен отказ или ясно ограничено продължение, не мълчаливо преминаване към по-широк достъп.
Какво казват OWASP и NIST
OWASP LLM06:2025 поставя прекомерната агентност сред рисковете за приложенията с големи езикови модели и насочва вниманието към ограничаване на функционалността, правата и автономността. Практическият извод е да се намаляват наличните инструменти и привилегии, да се използва човешко участие при действия с по-голямо въздействие и разрешенията да се налагат при изпълнението, а не да се разчита само на поведението на модела.
NIST AI 600-1, профилът за генеративен AI към рамката AI Risk Management Framework, предлага подход за идентифициране, оценяване и управление на рисковете в контекста на системата. Той е насока за управление на риска, а не техническа гаранция, че даден агент е защитен, нито готов списък, който замества архитектурното решение. За екипа това означава да документира предназначението и границите на агента, да оценява възможните последствия и да наблюдава системата след внедряване. Контролите трябва да са съобразени с конкретната среда и критичността на действията.
Тези препоръки се вписват в по-широкия въпрос за човешкия фактор: кой задава границите на системата, кой може да ги промени и кой проверява дали реалните права съответстват на задачата. Вижте и човешкия фактор и границите на контрола в AI сигурността за по-широкия контекст.
Не давайте на агента власт по подразбиране
Агентът не се нуждае от широки права, за да бъде полезен. Започнете с най-тесния набор от инструменти и достъп, който решава задачата; отделете четенето от промяната и създаването на чернова от изпращането; ограничете credentials и изходящите канали; изисквайте преглед за действия с по-голямо въздействие; и поддържайте журнал, който може да бъде използван. После разширявайте достъпа само при ясна необходимост и с проверими основания.
Така въпросът „Агентът има права. А трябва ли?“ получава практичен отговор: само ако конкретната задача ги изисква, само в необходимия обхват и само докато са нужни. Границата не бива да зависи от това дали моделът звучи уверен или обещава да бъде внимателен. Тя трябва да бъде наложена от системата, която му позволява да действа.
