NIST тражи „личну карту“ за AI агенте — стигло је више од 600 одговора

Амерички Национални институт за стандарде и технологију (NIST) објавио је 29. септембра 2026. резиме јавних коментара о идентитету софтверских и AI агената. Одазвало се више од 600 учесника из привреде, државних институција и академске заједнице, а NIST-ов Национални центар за изврсност у сајбер безбедности (NCCoE) изабрао је DevSecOps као први случај примене: у развоју софтвера приказаће како се агенти идентификују, аутентификују и овлашћују.

У резимеу више од 600 одговора један учесник је захтев сажeо речима: „The identity anchor should be stable“. Иза тога стоји питање које развојни тим мора да реши за сваку агентску радњу: чије овлашћење агент користи, где се оно завршава и који запис омогућава да се одлука касније испита. Следећа планирана публикација је нацрт описа пројекта, са предложеним обимом, архитектуром и стандардима.

Зашто је развој софтвера први случај примене

У коментарима се развој софтвера издвојио као окружење у којем агент може да чита код, предлаже измену, покреће алат и затражи приступ систему за испоруку. Сваки прелаз отвара засебно питање дозволе. То је посебно видљиво када се задатак прошири са локалног репозиторијума на аутоматизовану испоруку или инфраструктуру.

Учесници су предложили да се развој и постављање софтвера разматрају одвојено, јер измена предложеног кода и пуштање те измене у рад имају различите последице. Међу наведеним примерима су токови у којима агент сме да припреми предлог измене, као и управљање приступом тајнама и кључевима. Та разлика даје пројекту конкретан тест: дозвола за предлагање кода не сме сама по себи да постане дозвола за његово постављање.

Inside Cybersecurity је 30. септембра известио да су за предстојећи пројекат предвиђена два случаја употребе. Први је рад агената у пословном развоју софтвера; каснија фаза треба да обухвати агенте које поседују или контролишу потрошачи. Детаљнији обим тек треба да буде утврђен у нацрту пројекта.

Идентитет агента и дозвола за задатак

Коментатори су углавном тражили да агент има засебан, проверљив идентитет, различит од идентитета човека који му задаје посао. За процену приступа важни су и конкретна инстанца агента, окружење у којем ради, организација или особа која га је овластила и право које има у том тренутку. Сама успешна пријава зато не одговара на питање сме ли агент да изврши следећу радњу.

Трајни ослонац поверења може бити везан за организацију и софтвер из којег агент потиче, док овлашћење за појединачни задатак може кратко да траје и да истекне по његовом завршетку. Ако агент део посла преда другом агенту, нова дозвола треба да буде ужа од оне коју је добио први. Тако се може пратити порекло овлашћења без давања истих права сваком учеснику у ланцу.

Одлука о приступу доноси се у контексту радње: који алат агент позива, који ресурс жели да промени и да ли делегација покрива баш тај захтев. У коментарима постоји снажно противљење томе да језички модел буде једини арбитар дозволе. Правило које штити ресурс мора да се спроведе и провери одвојено од моделовог тумачења задатка.

Једна измена кода кроз ланац човек–агент–алат–ресурс

Условни пример показује шта би први случај примене морао да повеже. Инжењер задаје агенту да предложи исправку у репозиторијуму; агент позива развојни алат, а алат затим тражи приступ коду. Ако исправка треба да буде постављена у рад, настаје нова одлука о дозволи и могућем људском одобрењу. Ово је илустрација захтева из коментара, а не опис већ изграђеног NIST-овог решења.

• Човек → агент. Бележе се идентитет онога ко је задао посао, идентитет агента и границе делегираног задатка. Агент тиме добија право да припреми одређену измену, а не сва права инжењеровог налога.
• Агент → алат. Алат проверава засебан идентитет агента и да ли добијено овлашћење покрива тражени позив. Ако посао преузме подагент, запис повезује нову инстанцу са претходном делегацијом и бележи њен ужи опсег.
• Алат → ресурс. Репозиторијум одлучује да ли је дозвољено читање или предлагање измене за конкретан пројекат. Идентитет алата, захтев, примењено правило и исход одлуке остају повезани, тако да се каснија промена не приписује само техничком налогу.
• Одобрење → извршење. Ако постављање измене захтева човека, одобрење се везује за ту радњу и њен обим пре извршења. Ревизија потом може да повеже одобриоца, агента, употребљени алат и стварну измену ресурса.

Овај ланац раздваја аутентикацију од ауторизације. Потврда да је алат заиста позвао познати агент не значи да тај агент сме да мења сваки репозиторијум или да изврши каснији корак испоруке. Управо на таквим прелазима постаје важно да се дозвола поново процени, уместо да се једном издато широко овлашћење преноси до краја процеса.

Ревизијски траг има и границу приватности

Дневник који бележи само позив алата не показује зашто је измена била дозвољена. Учесници траже да траг обухвати разматрани захтев, враћену одлуку, релевантне идентитете и делегације, као и податак о људском одобрењу. За спорну измену то омогућава реконструкцију пута од првобитног налога до извршене радње, укључујући правило које је дозволило приступ.

Детаљнији траг носи и ризик прекомерног прикупљања. Трајни идентификатор човека који прати агента кроз више услуга може омогућити профилисање, док дневници могу задржати осетљив садржај задатка или податке које је агент користио. Зато су у коментарима заједно разматрани доказива одговорност, ограничење података који се деле и контрола њиховог чувања. Обим записа мораће да буде довољан за ревизију, али сразмеран ризику радње.

Шта следи после објављеног резимеа

Нацрт описа пројекта треба да изложи предложени обим, случајеве употребе, архитектуру и стандарде, па да отвори нови круг повратних информација. Прва демонстрација у DevSecOps окружењу показаће да ли се идентитет агента, ограничена делегација и одлука о приступу могу повезати кроз стварни ток развоја софтвера. За тимове који агентима већ дају приступ коду, кључно питање биће где се у том току раздваја право да агент предложи измену од права да она буде извршена.

Прочитајте и:

• Дуг контекст или RAG: више токена не значи увек бољи одговор
• OBS Studio или StreamYard: лакши пренос тражи месечну претплату
• APEC тражи заштиту радника: AI мења и социјалну сигурност