Ограничени идентификационни данни, краткотрайни токени и достъп по време на изпълнение: Архитектурата за сигурност, от която агентите с изкуствен интелект всъщност се нуждаят

Когато на AI агент е предоставен достъп до финансов API, хранилище за код или комуникационна платформа, въпросът за сигурност, който повечето екипи задават, е дали тези идентификационни данни се съхраняват безопасно. По-важният въпрос е какво се случва, когато не са. Съхранението в хранилище, политиките за ротация на секретни данни и хигиената на променливите на средата са необходими контроли, но те адресират грешния модел на заплаха за агентните системи. Действителният риск в производствен агент, който е свързан със Stripe, GitHub или Slack, не е, че идентификационните данни ще бъдат извлечени от хранилището: а е, че веднъж издадени, идентификационните данни носят разрешения, които далеч надвишават това, което изисква всяка отделна задача. Тази статия разглежда защо радиусът на взривяване, а не сигурността на съхранението, е основният проблем и как изглежда на практика архитектурата за идентификационни данни по време на изпълнение, която го адресира.

Допълнителна част към по-широката ни работа върху управлението на идентичността на агентите и достъпа. Вижте „Агентите с изкуствен интелект се нуждаят от идентичност, разрешения и одитни следи: Инженерната архитектура, която повечето екипи липсват“ за подробно разглеждане на управлението на нечовешка идентичност, моделите за предоставяне на най-малко привилегии и дизайна на одитните следи за агентни системи в производство.

Проблемът с радиуса на взрива при дълготрайни токени

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

Защо самото съхранение в трезор не решава този проблем

Платформи за управление на тайни данни като HashiCorp Vault, AWS Secrets Manager и Azure Key Vault намаляват вероятността от излагане на идентификационни данни в покой. Те не намаляват повърхността на разрешенията за идентификационните данни, след като бъдат извлечени. Агент, който извлича GitHub токен от Vault при стартиране на задача и го държи в паметта за времето на многоетапен работен процес, все още носи токен, който, ако бъде прихванат във всеки момент от този работен процес, би могъл да предостави достъп за запис до всяко хранилище, за което е бил предоставен токенът. Трезорът решава проблема със съхранението; не решава проблема с обхвата. Разграничението е важно, защото повърхността за атака в агентните системи не е предимно съхранението: това е средата на изпълнение, където агентът активно извършва API повиквания, обработва външни входни данни и потенциално получава враждебни инструкции чрез съдържанието, което извлича.

Обмен на идентификационни данни по време на изпълнение като архитектурен примитив

Алтернативата е издаването на идентификационни данни да се третира като събитие по време на изпълнение, което е ограничено във времето до конкретна задача и се прекратява, когато задачата завърши. Вместо да извлича широк токен при стартиране на агента, агентът изисква идентификационни данни в момента, в който трябва да извърши конкретно действие, като посочва необходимия ресурс и операция. Органът за идентификационни данни, независимо дали това е сървър за оторизация на OAuth 2.0, вътрешен механизъм за политики или платформено-ориентиран конектор, издава токен, чийто обхват е точно съобразен с тази заявка и с срок на валидност, измерен в минути, а не в дни. Ако този токен бъде компрометиран по време на задачата, атакуващият получава идентификационни данни, чийто срок на валидност е почти изтичащ и е ограничен до една операция върху един ресурс. Радиусът на взрива се свива от целия обхват на разрешенията на агента до площта на една единствена задача.

Какво прави възможно регистрацията на конектори

За да работи този модел на практика, агентите се нуждаят от структуриран начин за деклариране на своите изисквания за интеграция по време на регистрация, вместо да придобиват идентификационни данни опортюнистично по време на изпълнение. Архитектурата Connect на Vercel илюстрира един подход: интеграциите се регистрират като първокласни конектори с дефинирани обхвати, а платформата посредничи при обмена на идентификационни данни от името на агента, вместо да предава сурови токени директно на агента. Агентът никога не държи базовите идентификационни данни за услугата; той държи препратка с обхват на сесията, която платформата разрешава към действителния токен в точката на API извикването. Това разделяне означава, че отнемането на достъп до низходяща услуга не изисква търсене на токени в конфигурациите на агентите: регистрацията на конектора е единствената точка на контрол. За инженерните екипи, управляващи агенти, които имат достъп до множество външни услуги, този архитектурен модел намалява оперативната тежест от ротацията на идентификационните данни и прави повърхността за интеграция на агента одитируема от един регистър.

Определяне на обхвата на всяка задача във финансовата инфраструктура

Продуктът Command на Mercury предлага конкретна илюстрация на определяне на обхвата за всяка задача в домейн, където последиците от свръхразрешения достъп са директно измерими в долари. Вместо да издава на агент общи банкови API идентификационни данни, Command издава специфични за задачата оторизации: агент, помолен да плати на доставчик, получава идентификационни данни, обхванати от този получател, тази сума и този прозорец за транзакция. Агент, помолен да извлече баланс, получава идентификационни данни само за четене, без възможност за иницииране на плащане. Оторизацията е ограничена не само във времето, но и в операцията, което означава, че компрометирани идентификационни данни от задача за проверка на баланс не могат да бъдат използвани за иницииране на превод. Това е практическото прилагане на най-ниските привилегии на ниво задача, а не на ниво приложение, и това е моделът, който финансовата инфраструктура изисква, когато агентите работят автономно от името на потребители.

Одитните следи като следствие от определянето на обхвата по време на изпълнение

Едно недооценено предимство на обмена на идентификационни данни по време на изпълнение е, че той създава естествен дневник за одит без допълнителна инструментариум. Тъй като всяка заявка за идентификационни данни е отделно събитие, органът за идентификационни данни записва какво е било поискано, от коя идентичност на агента, за кой ресурс, по кое време и дали заявката е била удовлетворена. Това е структурно различно от одита на дълготраен токен, където дневникът записва, че е издаден токен и по-късно, че е бил използван, но не може надеждно да припише отделни API извиквания на конкретни задачи на агента. За екипи, работещи по SOC 2, PCI DSS или разпоредби за финансови услуги, които изискват демонстрируем контрол на достъпа, издаването на идентификационни данни за всяка задача измества одитните доказателства от проблем с криминалистичната реконструкция към запис в реално време. Последиците за съответствие не са незначителни: регулаторните органи все повече очакват организациите да демонстрират, че достъпът е бил подходящ по време на всяка операция, а не само че идентификационните данни са били съхранени правилно.

Съображения за внедряване за инженерни екипи

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