Управлението на жизнения цикъл на идентичностите не е създадено за ИИ агенти

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

За да разберете защо управлението на жизнения цикъл на идентичностите се срива при ИИ агентите, трябва да разберете за какво е изградено да работи добре и за кого е създадено. Цялата архитектура почива на едно единствено фундаментално предположение: всяка идентичност съответства на човешко същество, чийто организационен статус се променя чрез документирани, управлявани от отдел "Човешки ресурси" (HR) събития.

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

HR платформата, независимо дали е Workday, SAP SuccessFactors или ServiceNow HR, функционира като водеща система (system of record), която задвижва целия жизнен цикъл на управлението на идентичностите и достъпа. Записът за нов служител задейства автоматизирано предоставяне на права в Active Directory или Azure AD, което разпространява правомощията към следващите приложения чрез IGA конектори. Прехвърлянето в друг отдел актуализира атрибутите на ролята и преизчислява подходящия набор от права. Събитието за прекратяване на трудовия договор задейства работни процеси за отнемане на правата (deprovisioning) във всички свързани системи.

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

Управлението на идентичностите (identity governance) изгражда отчетност върху тази структура. Кампаниите за сертифициране на достъпа се насочват към мениджъра на идентичността или собственика на приложението за потвърждение. Контролите за разделяне на задълженията (separation-of-duties) откриват конфликтни разрешения. Одитните логове свързват всяко действие по предоставяне на права обратно с първоначалното HR събитие и одобряващия орган, който го е оторизирал, предоставяйки доказателства за съответствие (compliance), изисквани от рамки като SOX, HIPAA и PCI DSS.

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

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

Моделът е кохерентен, подлежи на одит и е добре поддържан от десетилетия развитие на IGA инструменти. Той надеждно управлява човешките идентичности. Проблемът започва точно в периферията му, където субектите, натрупващи достъп в корпоративните среди, вече нямат трудови досиета, мениджъри или дати на напускане.

ИИ агентите не пристигат чрез отдел "Човешки ресурси". Те нямат трудови досиета, йерархични структури за отчитане или дефинирани профили на роли, които се картографират към набори от права. Те се създават от инженери, оркестрационни рамки или автоматизирани тръбопроводи за внедряване (deployment pipelines) и попадат в производствена среда с каквито разрешения разработчикът е определил при създаването им или каквито платформата е предоставила по подразбиране.

Тази история на произход нарушава всяко предположение, от което зависи моделът за управление на жизнения цикъл на идентичностите.

Стандартните контроли за жизнения цикъл на управлението на идентичностите и достъпа изискват авторитетен източник за иницииране на предоставянето на права. За хората този източник е HR системата. За ИИ агентите предоставянето на права обикновено се случва чрез разработчик, който ангажира конфигурационен файл, извикване на API на платформа, което инстанцира нова среда за изпълнение на агента, или оркестрационен слой като LangChain, AutoGen или AWS Bedrock Agents, стартиращ нов контекст за изпълнение. Никое от тези събития не засяга IGA платформата. Никое не генерира запис за предоставяне на права, свързан с дефиниран собственик на идентичността.

Агентът пристига с вече прикрепени акаунти за достъп (credentials): ръчно създаден служебен акаунт, API ключ, генериран и съхраняван в променлива на средата, или OAuth разрешение, издадено чрез поток за съгласие на разработчика. IGA платформата, о...