Автор: Идо Шломо, съосновател и главен технологичен директор на Token Security
AI агентите трябва да извършват повече действия самостоятелно. Кой разполага с времето или вниманието да одобрява всяка команда? А и наблюдението как агентите вършат поставената им работа е безумно скучно.
Но агентите наистина се нуждаят от граници, особено в корпоративна среда. Без ясни ограничения за това какво могат да правят, работните процеси с агенти са склонни да използват целия наличен достъп.
Ето един реален пример: Разработчик моли своя агент да разбере защо нощната задача за експортиране се проваля. Правилото на екипа за агентите е просто: те работят чрез роли с достъп само за четене (read-only). Разработчикът обаче притежава и администраторски права (admin) за дежурства, като и двата профила се намират в един и същ файл ~/.aws/config.
Агентът получава грешка AccessDenied, когато се опитва да стартира отново задачата, затова превключва към администраторския профил, приема ролята и първо изпълнява aws s3 rm срещу производствения контейнер (production bucket), за да изчисти частично записания експорт.
Идентификационните данни са валидни. Разработчикът има право да използва администраторски привилегии, а администраторът може да изтрива S3 обекти. AWS проверява подписа, а не кой държи ключа, така че, доколкото е известно на AWS, това е извършено от разработчика. Нарушението се състои в това, че агентът е използвал роля, която агентите нямат право да използват. За разлика от намерението, това може да бъде проверено при всяка заявка.
Кой е виновен? Разработчикът, който не е трябвало да предава своите данни за достъп на агента и да му позволява автоматично да одобрява действия? Или създателят на рамката (harness)? Това е грешният въпрос. Отново, агентите трябва да вършат повече неща самостоятелно, като казвам това и като разработчик, и като мениджър на разработчици, които работят с изкуствен интелект.
Вместо да търсим виновни, трябва да знаем къде всъщност може да бъде спрян този опит за изтриване. Съществуват няколко възможни точки за прилагане на контрол, като всяка зависи от това какво може да види контролният механизъм, какво може да блокира и дали агентът има друг път за достигане до същото действие.
Искаме автономия с ограничения, които наистина можем да прилагаме
Първо трябва да дефинираме обхвата на проблема. Налице е Sustained натиск за разширяване на достъпа на агентите и обикновено причината изглежда логична сама по себе си. Например някоя задача блокира. Или има нова интеграция за услуга, съдържаща част от организационния контекст.
Резултатът винаги е един и същ: следващата задача започва с повече достъп от предишната.
Втори източник на натиск е самият агент. Агентите търсят нови данни за достъп, когато наличните са блокирани, без да питат отговорния човек дали могат да получат такъв достъп.
Това поведение не зависи от източника на инструкциите. Злонамерено инжектиране на подкана (prompt injection) може да предизвика опити за превишаване на правата, но същото може да се случи и при погрешни предположения по време на оторизирана задача.
Валиден ключ, грешни ръце
AWS проверява подписа, а не кой държи ключа. Когато агентът прихване администраторски профил, заявката изглежда така, сякаш идва от разработчика.
Token Security съпоставя всеки агент с неговия собственик, самоличности и права за достъп, така че вашите контроли да блокират действия извън поставената задача и да позволяват изпълнението на останалите.
Бъдете конкретни относно това какво прилагате
Агентите използват извиквания на инструменти (tool calls), за да извличат данни или да предприемат действия, така че именно там прилагането на контрол е най-важно. Въпреки това „контролирането на извикванията на инструменти“ е твърде общо правило. Какво става, ако инструментът е командна обвивка (shell), която може да стартира SDK? Може да бъде и браузър с автентикирана сесия. Когато разрешите инструмента, разрешавате и това, което stoi зад него.
За да разберем правилно какво се случва, са ни необходими операцията, нейните аргументи, достъпеният акаунт и ресурс, както и използваната самоличност. За операции с данни трябва също така да разберем какъв е изходният резултат и накъде се пренасочва този резултат.
Има много фактори, които участват в вземането на правилно решение относно валидността на дадено действие.
В повечето рамки за агенти локалните команди, операциите с файлове, уменията и делегирането също представляват извиквания на инструменти. Те са важни поради това до какво водят. Например четенето на ~/.aws/config е начинът, по който агентът намира администраторски профил, който да използва.
Така че прилагането на контрол при извикването на инструмента е от критично значение, както и вземането на решение за действието вътре в него.
Къде може да се прилага контрол
Част от щетите могат да бъдат предотвратени чрез проверки на логиката (reasoning checks), които оценяват плана или действието спрямо текущата задача. Но това е вероятностен контрол и някои злонамерени инструкции ще преминат през него. Няма добра алтернатива на наличието на подходящи контроли за смекчаване на риска, които да могат да спрат дадено действие.
| Метод | За какво е полезен | Какво бих проверил, преди да разчитам на него | Риск, който премахва | Цена за автономията |
|---|---|---|---|---|
| Управлявани настройки на агента | Ограничаване на инструменти, права, режими на одобрение и разрешени интеграции близо до агента. | Кои клиенти спазват настройките? Може ли потребител, проект или агент да ги отмени? Настройките за модел и усилие могат да се опитат да ограничат достъпа, но по своята същност са поведенчески избор. | Широк, когато приложението го прилага; малък при поведенчески настройки | Ниска, с изключение на режимите на одобрение, които струват най-много |
| Хукове във време на изпълнение (Runtime hooks) | Проверка на поддържана операция, преди да се изпълни, с контекст от сесията на агента. | Може ли потребителят или агентът да ги промени или изключи? Покриват ли алтернативни инструменти и подагенти? Блокират ли преди изпълнението, включително при грешки и изтичане на времето за изчакване? | За отделна операция, за събитията, които вижда | Ниска, ако е автоматизирано; висока, ако иска потвърждение от човек |
| Мрежови шлюзове (Gateways) | Инспектиране и блокиране на заявките, пренасочени през тях, със споделена политика за свързаните агенти. | Кой трафик всъщност виждат: заявки към модела, MCP инструменти, директни API или мрежов трафик? Може ли агентът да достигне до същата система по друг начин? | Висок за пренасочения трафик, никакъв за останалия | Ниска, тъй като спира само блокираната викане/заявка |
| Изолирани среди (Sandboxes) | Ограничаване на файловете, процесите, мрежовите маршрути и идентификационните данни, достъпни за агента. | Какво все още може да прави агентът в тези граници? Ограничени ли са достъпните услуги до правилния акаунт и операции, или просто до позволенโดмейн? | Ограничава обхвата, а не случващото се вътре | Средна, тъй като задачи, изискващи външен достъп, прекъсват |
| Прилагане на контрол върху крайните точки (Endpoint enforcement) | Управление на използването на локалния агент чрез софтуер за крайни точки или вече внедрен EDR. | Може ли да спре конкретна операция, или само процес или хост? Какво се вижда вътре в контейнерите или виртуалните машини? Кои хоствани агенти остават извън неговия обхват? | Само за локални агенти | Висока, ако прекрати процес или хост |
| Авторизация на идентификационните данни и целевите услуги | Намаляване на правомощията, предоставени на агента, и прилагане на достъп в системата, която държи ресурса. | Специфични ли са идентификационните данни за агента и задачата? Има ли алтернативни идентификационни данни? Може ли услугата да разграничи агента от човека или споделения акаунт зад него? | Висок, откъдето и да идва заявката | Средна, тъй като тесният достъп спира задачите и кара агентите да търсят още права |
| Управление, базирано на API | Промяна на настройките на агента, премахване на права, отменяне на идентификационни данни или сесии и деактивиране на достъпа, където платформите предоставят тези действия. | Кога промяната влиза в сила? Какво се случва със съществуващите сесии и кешираните токени? Предотвратяване на бъдещ достъп ли е, или реакция след действието? | Предимно след действието | Никаква, докато не се задейства |
Тези методи се застъпват и допълват взаимно. Хук, който извиква услуга за политики, и шлюз, който се консултира с граф на идентичността, вършат по-добра работа, защото точките за прилагане и вземане на решения са на местата, които са най-подходящи за тях.
Тази таблица далеч не е изчерпателна и има още съображения за някои от тези методи. Вземете например управляваните настройки. Настройките за модел и усилие са поведенчески по естество, но при някои среди (harnesses) правата са много повече от подкана, казваща „моля, не се самозабравяй“.
В Claude Code например правилата за достъп се прилагат от самото приложение, а управляваните настройки могат да ограничат отменянето им от потребителя. В такъв случай контролът се намира във файл с настройки, но това не го прави по-малко ефективен.
При хуковете основната предпоставка зависи изцяло от тяхното разположение във веригата на изпълнение. Не можете да спрете събитие, което вече се е случило, а поведението при грешка варира според видовете хукове и събития.
Шлюзовете имат свои собствени сложности, тъй като трябва да базират решенията си за авторизация върху това, което виждат. Разгледайте AWS AgentCore, който демонстрира проверки на политики за свързани инструменти. Обърнете внимание кои извиквания вижда той.
Изолираните среди и ограниченото право за достъп чрез идентификационни данни решават различни проблеми. Правилната изолация може да премахне възможностите за достъп, докато ограниченото право за достъп определя какво се случва, след като достъпът вече е предоставен. Вижте дизайна за автентификация в изолирана среда на Cloudflare, който показва начин за добавяне на идентификационни данни извън изолираната среда, така че агентът да не трябва да притежава тайния ключ. Неговите операции обаче все пак ще изискват авторизация.
Прилагане на същата политика към хостван агент
Рагледайте агент за поддръжка, от когото е поискано да обобщи отворени казуси. Неговият конектор използва сервизен акаунт, създаден за агенти, които редактират и затварят казуси. Агентът решава, че някои казуси изглеждат разрешени, и се опитва да ги затвори.
Отново, възможността идва с идентификационните данни и агентът е в рамките на предоставените му права. Мястото, където действието не е позволено, е одобрената политика на агента за достъп само за четене.
За да се приложи, политиката трябва да бъде нещо, което даден механизъм за контрол може да провери, като например: „Този агент може да чете казуси и всяко извикване, което редактира или затваря казус, се отказва, независимо от сервизния акаунт, с който разполага.“
Ако този агент живее в хоствана среда, контролът на крайната точка върху лаптопа на служителя може да няма възможност да спре действието, тъй като всичко се случва от страната на сървъра.
Тук ще ви трябва съдействие от контролите на самата SaaS платформа, да разчитате на шлюз за инструменти или да разполагате с по-тясно дефинирана идентичност на услугата. И отново, това зависи от това какво предоставя платформата и къде се изпълняват извикванията.
Което ни довежда до пропуските в покритието на нашите контроли. Тук няма един-единствен перфектен контрол. Хуковете не са по-добри от контрола на крайните точки, който пък не е по-добър от изолираната среда. Всичко зависи от това какво внедрявате и къде.
| Метод | Агент за програмиране на лаптоп | Агент за поддръжка в SaaS платформа |
|---|---|---|
| Управлявани настройки на агента | Работи, ако клиентът ги спазва | Само това, което доставчикът предоставя |
| Хукове във време на изпълнение (Runtime hooks) | Върху събитията, които средата за изпълнение предоставя | Само ако платформата предлага хукове |
| Изолирани среди (Sandboxes) | Ограничават файлове, мрежа и идентификационни данни | Агентът работи върху сървърите на доставчика |
| Прилагане на контрол върху крайните точки (Endpoint enforcement) | В обхват | Извън обхват |
| Мрежови шлюзове (Gateways) | Прихващат администраторските извиквания, ако трафикът към AWS преминава през тях | Шлюз за инструменти пред конектора |
| Авторизация на идентификационните данни и целевите услуги | Държат администраторския достъп извън обхвата на агента | Сервизен акаунт само за четене за целите на обобщаването |
| Управление, базирано на API | Отменяне на сесията последващо (след събитието) | Деактивиране на конектора последващо (след събитието) |
Два метода могат да спрат и двата примера, преди действие да достигне до целта: шлюз (gateway), който вижда съответния трафик, и ограничаване на обхвата на идентификационните данни (credential scoping) при целта. Другите методи зависят в по-голяма степен от това къде се изпълнява агентът и какво разкрива средата за изпълнение (runtime).
Преди всичко, искате агентът да продължи да работи в рамките на одобрените за него политики. Достъпът само за четене не е пълно решение. той все още може да разкрие чувствителни данни в зависимост от това къде отива изходният резултат. Анализът на ограничаването (containment analysis) на Anthropic обяснява защо.
3>Изберете това, което е практично, след което тествайте начините за заобикаляне на вашия контролВероятно ще решавате какво е практично въз основа на внедряването ви. Управляваните настройки изискват поддържани клиенти и централна администрация, например. И няма да имате прихващачи (hooks) без среда за изпълнение, която да разкрива правилните събития. Шлюзовете ви принуждават да пренасочвате трафика през тях, а контролите на крайните точки изискват инсталиране и поддръжка на софтуер.
Никой от тези методи не е безплатен. Контролите въвеждат компромиси, изискват поддръжка и трябва да отчитат постоянно нарастващия обем работа, управлявана от изкуствен интелект.
Да вземем примера с AWS от началото на статията. Блокирането на буквалната команда е начало, но какво ще стане, ако същата заявка дойде чрез SDK? С различни идентификационни данни? Чрез делегиране?
Изискването за сигурност за блокиране на изтриването остава същото, но има много различни пътища до него.
След това идва въпросът за стойността и трябва да го вземете предвид толкова, колкото и възможностите за контрол. Колко забавяне добавят контролите? Колко често някой трябва да деблокира фалшиво положително съвпадение (false positive)? Намаляваме ли риска, или създаваме проблеми?
Докладът ARISE на SACR се фокусира върху интервенция по време на изпълнение, делегирани правомощия и решения на ниво действие. Това трябва да се сведе до конкретна заявка, политика и доказателство за това какво се е случило, когато агентът е опитал действието.
Кратко ръководство въз основа на това къде се изпълняват вашите агенти и какво контролирате там:
| Къде се изпълняват вашите агенти | Какво обикновено контролирате | Започнете с | След това добавете |
|---|---|---|---|
| Лаптопи на разработчици и IDE-та | Крайната точка, настройките на агента, локалните файлове с идентификационни данни | Управлявани настройки, плюс прихващачи (hooks), където клиентът ги поддържа | Шлюз за API трафика към облака и прилагане на контрол на крайните точки за клиенти, които не можете да конфигурирате |
| Вашият собствен облак, CI или контейнери | Средата за изпълнение, изходящият мрежов трафик (egress) и идентичността на работното натоварване (workload identity) | Изолирана среда (sandbox) и идентификационни данни за работното натоварване за всеки агент | Шлюз на изходящия трафик |
| SaaS платформи | Идентификационни данни за конектори и администраторските настройки на платформата | Ограничена идентичност на услугата (service identity) за всеки агент | Контроли на платформата чрез API и шлюз за инструменти пред конекторите, където платформата го позволява |
Вероятно не се свежда само до едното или другото. Вместо това повечето организации разполагат с всичко изброено по-горе, смесено заедно, с контроли, разпределени между различни екипи. Във всички тези среди единственият общ знаменател е идентичността. Така че започнете с ограничаване на обхвата на идентификационните данни при целта, тъй като това определя обхвата, където и да се изпълнява агентът. След това добавете един източник на политики, от който всяка точка за прилагане да чете.
Направете това и ще имате добра начална позиция.
Къде се вписва Token
В Token Security изграждаме решения около графа на интелигентността за идентичност (identity intelligence graph) и решенията, които той може да поддържа в различните точки за прилагане. Нашият настоящ фокус обхваща настройки на агенти, шлюзове, прилагане на контрол на крайни точки и API към платформи за идентичност и агенти.
По-широката визия е да изградим или да се свържем с възможността за прилагане на контрол, от която клиентът се нуждае. Не е необходимо да изграждаме всичко сами.
Графът свързва агента с неговия собственик, идентичностите, които той използва, разрешенията, свързани с тези идентичности, и ресурсите, до които той има достъп. Това е видът контекст, който механизмите за политики (policy engines) могат да използват, за да решат какво може да прави даден агент, вместо да предполагат, че пълните правомощия на идентификационните данни са подходящи.
В скорошна демонстрация на шлюза показахме точно тази идея: един и същ разработчик, една и съща сесия, а извикването на агента е отказано за администраторски права и е разрешено за достъп само за четене (readonly). Други контроли също могат да наложат достъп само за четене.
Осигуряването на правилния контекст на идентичността и прилагането на политиката на различните места, където работят агентите, е от първостепенно значение, но и сложно, тъй като този процес изисква надеждна атрибуция. Ако не можем да разграничим заявката на агента от човек, използващ същите идентификационни данни, графът не го решава магически.
А какво ще кажете за базовите линии (baselines)? Имайте предвид, че миналото поведение може да се използва само като входящи данни, а не като самата политика. Фактът, че даден агент обикновено само чете данни, не доказва, че записът е забранен. Това е работа на правилото, което фиксира агентите до достъп само за четене (readonly). Липсващият или остарял контекст също изисква изрично решение, както е при изтичането на времето за изчакване на прихващачите (hook timeouts).
Искам даден агент да завърши разследването или обобщението за поддръжка, без да се изисква одобрение за всяка стъпка. Също така искам да знам точно къде ще спре действие извън тази задача. Това е, което бих поискал от всеки метод за прилагане на контрол, включително Token Security.
Вижте какво предлагаме или резервирайте демонстрация, ако във вашата организация също решавате тези проблеми със сигурността на изкуствения интелект.
Спонсорирано и написано от Token Security.