Агентен AI , AI стратегия , Софтуерна разработка Юни 16, 2026

Агентите с изкуствен интелект се нуждаят от самоличност, разрешения и одитни следи: Инженерната архитектура, която повечето екипи пропускат

VECTOR Labs Team

Последна промяна: Юни 23, 2026

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

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

Защо човешката IAM се проваля за нечовешки агенти

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

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

Идентичността на агента като първокласен архитектурен проблем

Правилната отправна точка е всяка отделна роля на агент - не всеки екземпляр на модела, а всяка функционална роля в работния процес - да се третира като отделна, изрично осигурена идентичност със собствени идентификационни данни, собствен обхват на права и собствен жизнен цикъл. Това означава преминаване от модела „услуга-акаунт-за-разполагане“ към целенасочено изградена рамка за нечовешка идентичност (NHI). На практика това включва издаване на краткотрайни идентификационни данни (обикновено JWT или OAuth 2.0 токени с времеви интервали на изтичане, измерени в минути, а не в дни), обвързване на тези идентификационни данни с конкретни роли на агенти, дефинирани в централен регистър на идентичности, и автоматичното им завъртане при завършване на задачата или изтичане на времето, а не по календарен график. Моделът с краткотрайни идентификационни данни е важен, защото ограничава прозореца на експозиция, ако дадено идентификационно данни бъдат откраднати - идентификационни данни, които изтичат след петнадесет минути, са съществено по-малко опасни от статичния API ключ, който се запазва в продължение на месеци.

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

Модели с най-ниски привилегии за агентни работни потоци

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

По-защитимият модел е контрол на достъпа, базиран на атрибути (ABAC), комбиниран с издаване на токени в обхвата на задачата. При този модел оркестраторът на агента изисква токен при всеки фазов преход, като посочва действието, което трябва да извърши, и ресурса, върху който трябва да го извърши. Услугата за оторизация оценява заявката спрямо политика, която кодира декларираната роля на агента, текущия контекст на работния процес и класификацията на данните на целевия ресурс, и издава токен, обхванат само от това конкретно действие върху този конкретен ресурс, с срок на валидност, обвързан с очакваната продължителност на тази фаза. Оперативните разходи на този подход са реални - той изисква процес на създаване на политики, услуга за издаване на токени, способна да обработва пропускателната способност на многоагентен работен процес, и оркестрационен слой, който знае как да изисква и представя токени на всяка стъпка. Тези разходи са цената за това да се направи най-малко привилегированите права приложими, а не желателни.

Дизайн на одитна пътека за действия на агенти

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

Структурираните, непроменими лог файлове за действия трябва да се записват на нивото по време на изпълнение на агента, а не да се реконструират от системни лог файлове надолу по веригата. Всеки запис в лога трябва да включва самоличността на агента, идентификатора на идентификационните данни и неговия срок на валидност, конкретния извикан инструмент или API, входните параметри (в зависимост от ограниченията за класификация на данните относно това, което може да се регистрира), решението за политиката, което е разрешило повикването, и състоянието на отговора. Непроменимостта е важна, защото одитните лог файлове, които могат да бъдат променяни след това, не предоставят доказателствена стойност в регулаторен или правен контекст - те трябва да бъдат записани в хранилище само за добавяне с проверка на криптографската цялост. За предприятия, работещи съгласно GDPR, HIPAA или разпоредби за финансови услуги като MiFID II или SOX, възможността за създаване на пълен, защитен от несанкционирана промяна запис на действията на агентите не е приятна; това е изискване за съответствие, което регулаторните органи започват да проверяват изрично, тъй като внедряването на агенти става все по-често срещано.

Верификационни портали и контроли „човек в цикъла“

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

Прилагането на това на практика изисква оркестрационният слой да класифицира действията по обратимост и последствие преди изпълнение, да насочва действията с висок риск към опашка за одобрение от човек с достатъчен контекст, за да може проверяващият да вземе информирано решение в разумен срок, и да прилага политика за изчакване, която води до безопасен неуспех (обикновено като не се продължава), вместо да се преминава към автономно изпълнение по подразбиране, когато не се получи отговор. Опашката за одобрение трябва да показва не само предложеното действие, но и веригата от разсъждения на агента - последователността от стъпки и извиквания на инструменти, довели до решението - така че проверяващият да оценява логиката, а не само резултата. Без веригата от разсъждения, прегледът с участието на човек се превръща в печат, а не в смислен контрол.

Автоматизирано отстраняване и откриване на отклонения

Управлението на идентичността на агентите не е еднократно упражнение за осигуряване. Агентите се модифицират, преназначават и премахват; работните потоци, с които работят, се променят; данните, до които имат достъп, се развиват в класификацията. Без активно наблюдение, разликата между това, което агентът е оторизиран да прави, и това, което всъщност прави в производствения процес, се разширява с течение на времето. Дрейфът на правата - където агентите натрупват разрешения извън текущите си функционални изисквания, или чрез ръчно разширяване по време на отстраняване на грешки, или чрез наследен обхват от промени в работния процес - е агентният еквивалент на нарастването на привилегиите в човешката IAM и носи същите рискове.

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

Управленският дълг се натрупва нелинейно

Оперативният риск от ad-hoc управление на идентичността на агентите не се мащабира линейно с броя на разположените агенти. Той се мащабира с броя на агентите, умножен по броя на системите, до които всеки агент може да достигне, умножен по непрозрачността на модела на идентификационни данни и разрешения - което означава, че организация, работеща с двадесет агента на споделени акаунти за услуги с широки разрешения и без структурирана одитна следа, не е два пъти по-изложена на риск от такава, работеща с десет агента в една и съща конфигурация; тя е значително по-изложена на риск, защото взаимодействията между агентите, споделените идентификационни данни и припокриващите се набори от разрешения създават комбинаторно по-голяма повърхност за атака и пропорционално по-труден криминалистичен проблем, когато нещо се обърка. Цената за отстраняване на преоборудването на инфраструктурата за идентичност на агентите върху зряло многоагентно внедряване - пренастройване на обхвата на разрешенията, преинструментиране на регистрирането, възстановяване на регистъра на идентичността от непълни записи - е постоянно по-висока от цената за правилното й изграждане в началото. Описаните тук архитектурни решения не са сложни спрямо системите, които защитават, но изискват съзнателно приоритизиране, преди имуществото на агентите да достигне мащаба, при който дългът за управление става структурно труден за изплащане.

Където се вписва Vector Labs

Ние проектираме и изграждаме производствени агентни системи с изкуствен интелект, включително инфраструктура за идентичност, разрешения и одит, която ги прави управляеми в корпоративен мащаб. Нашата работа по агентни архитектури обхваща оркестрационен дизайн, интеграция на инструменти и оперативния контрол, който регулираните индустрии изискват - както е описано подробно в нашата статия „ Агентен изкуствен интелект във фармацевтиката: от откриване на лекарства до подаване на регулаторни документи“ , която разглежда как изискванията за одит и контрол на достъпа оформят дизайна на агентни системи в област с интензивно съответствие. Ако изграждате инфраструктура за идентичност на агенти или оценявате риска за управление в съществуващо внедряване, свържете се с нас на vector-labs.ai/contacts .

Често задавани въпроси

Можем ли да използваме съществуващата ни IAM система за самоличност на агенти или ни е необходимо отделно решение?

Съществуващите IAM системи могат да осигурят инфраструктура за издаване на удостоверения и прилагане на политики, но обикновено се нуждаят от разширение, а не от подмяна. Пропуските обикновено са в три области: поддръжка за краткотрайни, динамично ограничени токени, издавани на етапи на задача, а не на етапи на сесия; модел на метаданни за нечовешки идентичности, който улавя ролята на агента, контекста на работния процес и обхвата на инструмента; и интеграция на журнал за одит, който записва решението за политиката заедно с действието. Някои организации разширяват съществуващите си инструменти за PAM (управление на привилегирован достъп), за да обхванат агентите; други изграждат лек NHI регистър, който се намира редом със съществуващия IAM стек и обработва жизнения цикъл на специфичните за агента удостоверения. Правилният подход зависи от това какво поддържа вашият съществуващ IAM доставчик и каква част от специфичния за агента модел на метаданни трябва да поддържате.

Как да определим обхвата на разрешенията за агент, чието използване на инструменти е наистина динамично и трудно за предвиждане предварително?

Честният отговор е, че наистина непредсказуемото използване на инструменти е сигнал, че обхватът на задачите на агента е твърде широк, а не че минималните привилегии са непрактични. Повечето производствени работни потоци, когато се разложат внимателно, имат краен и изброим набор от извиквания на инструменти за всяка фаза - непредсказуемостта често е артефакт от това, че на агента е възложена една голяма задача, а не структуриран работен процес с дефинирани фази. Когато е наистина необходим динамичен избор на инструменти, моделът ABAC с издаване на токени „точно навреме“ позволява на агента да поиска достъп до инструмент в момента на нужда, като услугата за оторизация оценява заявката спрямо текущия контекст на работния процес. Тази оценка може да включва проверка спрямо предварително деклариран списък с инструменти, които агентът има право да поиска - така динамичният елемент е ограничен, а не отворен.

Какво всъщност трябва да съдържа дневникът за одит на агенти и с какво ниво на детайлност?

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

Как се справяме с идентичността на агентите в многоагентни архитектури, където един агент поражда други?

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

Кои регулаторни рамки са най-пряко свързани с изискванията за самоличност и одит на агентите?

Най-непосредствено релевантните рамки зависят от областта, но няколко имат директни последици за одитираемостта на агентите. Член 5(2) от GDPR изисква доказуема отчетност за решенията за обработка на данни - агент, който обработва лични данни, се нуждае от проследим запис за това до какво е осъществил достъп, защо и под какво правомощие. Изискванията за контрол на одита на HIPAA (45 CFR § 164.312(b)) се прилагат за всеки агент, работещ с електронна защитена здравна информация. Раздел 404 от SOX изисква документиран контрол върху процесите на финансово отчитане, което все повече включва автоматизирани агенти във финансовите работни потоци. Изискванията на Закона за изкуствения интелект на ЕС за високорискови системи с изкуствен интелект включват задължения за регистриране и разпоредби за човешки надзор, които се свързват директно с архитектурата на портала за проверка и одитната следа, описана в тази статия. Общата нишка между всички тях е, че регулаторите се насочват към третиране на агентските системи като отговорни участници, чиито решения трябва да бъдат проследими, а не като автоматизация на черна кутия, която е извън обхвата на съществуващите рамки за съответствие.

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

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

В кой момент от жизнения цикъл на внедряването трябва да внедрим инфраструктура за идентичност на агенти, преди първият агент да влезе в производство, или след като имаме достатъчно агенти, за да оправдаем инвестицията?

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

Екип който Ви разбира

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

Консултирайте се с AI експерт