Управљање алатом агента преко АИ АПИ капије: опсег, одобрења, буџети и трагови ревизије

<п>Ризик агента више није ограничен на упит модела. Продукцијски агент може претраживати интерне датотеке, испитивати податке о клијентима, позивати МЦП сервер, извршавати код, отварати претраживач, слати е-пошту, ажурирати ЦРМ или покренути ток рада наплате. Питање управљања постаје: ком кориснику, кључу, моделу, агенту и алату је било дозвољено да предузме коју радњу, са којим буџетом, ревизијским трагом и путањом враћања? <п>Ако сваки тим рукује приступом алатима унутар сопственог СДК кода, смернице постају расуте по променљивим окружења, контролним таблама добављача, међуверском софтверу апликације и недокументованим МЦП серверима. Сигурнији образац је третирати извршавање алата агента као проблем контролне равни и спроводити га преко АИ АПИ мрежног пролаза или стандардног омотача за извршавање алата који сваки агент мора да користи. <п>Овај чланак раздваја чињенице, препоруке и предвиђања. Чињенице су извучене из тренутних јавних смерница: ОВАСП-ова ЛЛМ апликација Топ 10 укључује ризике као што су откривање осетљивих информација, рањивости ланца снабдевања и прекомерно ангажовање; НИСТ-ов генеративни АИ профил за оквир за управљање АИ ризиком наглашава мапирање, мерење и управљање генеративним АИ ризицима; ОпенАИ упутства за агенте препоручују процену ризика алата приступом за читање/писање, реверзибилношћу, дозволама и финансијским утицајем; и МЦП упутства за ауторизацију користе концепте ауторизације са опсегом за осетљиве ресурсе и операције. Препоруке у наставку су обрасци имплементације, а не универзални захтеви. <х2>Проблем читача: бркају се приступ моделу и приступ алатима <п>У многим раним ЛЛМ апликацијама, АПИ кључ је одговорио на једно основно питање: може ли ова услуга позвати модел? Агенти то чине превише грубим. Кључ који може да шаље довршене ћаскања не би требало аутоматски да може да извози податке о клијентима, покреће команде љуске, поставља у Слацк, мења тикете, прегледа произвољне веб-сајтове или подноси промене плаћања. <п>Слој управљања треба да одговори на конкретнија питања: <ул> <ли>Који закупац, радни простор, корисник, налог услуге или клијент препродавца је покренуо покретање? <ли>Који модел, шаблон упита, верзија агента и шема алата су коришћени? <ли>Да ли је тражена алатка била само за читање, реверзибилна, неповратна, спољна, финансијска или привилегована? <ли>Да ли је подносилац захтева имао потребан опсег? <ли>Да ли је одобрење било потребно, дато, одбијено, истекло или заобиђено смерницама за хитне случајеве? <ли>Колико је коштала алатка, колико пута је позвана и који је кумулативни буџет остао? <ли>Који докази постоје за отклањање грешака, преглед усклађености и враћање? <п>Архитектура у наставку претпоставља да мрежни пролаз већ прима позиве модела. Извршавање алата се затим може усмерити кроз исти мрежни пролаз, кроз помоћну услугу или кроз стандардну библиотеку која извештава мрежни пролаз пре и после сваког позива алата. <х2>Референтна архитектура: слој управљања алатом на нивоу мрежног пролаза <п>Практични систем управљања агентима има седам компоненти: <ол> <ли><стронг>Регистар алата: ауторитативна листа одобрених алата, МЦП сервера, хостованих функција, локалних алата за извршавање и интерних АПИ-ја. <ли><стронг>Идентитет и слој кључева: кључеви пролаза, корисници, закупци, налози за услуге, тимови и клијенти препродаваца. <ли><стронг>Маин за опсег: провере смерница које одлучују да ли кључ или корисник могу да позову могућност одређене алатке. <ли><стронг>Класификатор ризика: метаподаци који описују радијус експлозије, осетљивост података, реверзибилност, спољни утицај и изложеност трошковима. <ли><стронг>Ток посла за одобрење: Одобрење људи или система за радње високог ризика пре извршења. <ли><стронг>Књига буџета и ограничења стопе: ограничења по алату и агенту, а не само ограничења токена по моделу. <ли><стронг>Складиштење ревизије и праћења: обједињене евиденције за позиве модела, позиве алата, одобрења, грешке и исходе. <п>Важна одлука о дизајну је да приступни пролаз постане тачка одлучивања о политици чак и ако се стварна алатка покреће негде другде. На пример, алатка претраживача може да се изврши у заштићеном радном окружењу, а ЦРМ уписивање може да се изврши унутар интерне услуге. Мрежни пролаз и даље процењује да ли је позив дозвољен, бележи одлуку, прати трошкове и враћа потписану одлуку о овлашћењу или одбијеницу. <х2>Корак 1: Направите централни регистар алата <п>Регистар алата је инвентар који спречава да „непозната способност агента“ постане подразумевана. Сваки алат треба да има власника, ниво ризика и оперативне метаподатке. Минимални запис регистра може изгледати овако: <пре><цоде>{ "тоол_ид": "црм.цреате_тицкет", "дисплаи_наме": "Креирај карту за ЦРМ подршку", "овнер_теам": "аутоматизација подршке", "екецутион_типе": "интерни_апи", "сервер_урл": "хттпс://тоолс.интернал.екампле/црм", "алловед_тенантс": ["предузеће", "подршка"],"алловед_моделс": ["опште-велико", "опште-брзо"], "риск_тиер": "реверсибле_врите", "дата_цлассифицатион": "цустомер_метадата", "рекуиред_сцопес": ["тоол:црм.цреате_тицкет"], "аппровал_полици": "нот_рекуиред_ундер_100_тицкетс_пер_даи", "дефаулт_тимеоут_мс": 8000, "мак_цост_пер_цалл_усд": 0,05, "мак_цаллс_пер_рун": 3, "роллбацк_овнер": "суппорт-опс-онцалл", "ретентион_полици": "редацтед_30_даис" } <п>За МЦП сервере, регистар такође треба да садржи УРЛ адресу сервера, оглашене алате, верзију шеме, метод ауторизације, датум последњег прегледа и да ли су нове алатке подразумевано онемогућене. МЦП побољшава интероперабилност, али компатибилност протокола није исто што и ауторизација производње. Осетљивим ресурсима и операцијама су и даље потребни експлицитни опсег, провере рута и изолација станара. <х3>Препоручена поља регистра <ул> <ли>Назив алата, канонски ИД, власник и контакт на позив. <ли>Локација извршења: алатка хостованог добављача, МЦП сервер, интерни АПИ, претраживач, покретач кода, задатак у реду чекања или локални СДК алат. <ли>Дозвољени закупци, тимови, корисници, верзије агената и профили модела. <ли>Класификација података: јавни, интерни, метаподаци о клијентима, садржај корисника, тајне, подаци о плаћању, акредитиви, регулисани подаци. <ли>Ниво ризика и реверзибилност. <ли>Потребни обим и смернице за одобрење. <ли>Временска ограничења, ограничења стопе, максимални број позива по покретању, кумулативни буџет покретања и максимална цена по позиву. <ли>Режим евидентирања: пун корисни терет је забрањен, редигован, хеширан, узорковано или експлицитно задржан. <ли>Упутства за враћање и ескалација. <х2>Корак 2: Одвојите опсеге модела од опсега алата <п>Кључ производног мрежног пролаза треба да изрази шта позивалац може да уради. Приступ моделу и приступ алатима треба да буду независни. На пример: <пре><цоде>модел:цхат модел: ембеддингс тоол:доцс.сеарцх_реадонли алат:црм.цреате_тицкет тоол:емаил.сенд_рекуирес_аппровал алат:биллинг.рефунд_блоцкед алат:цоде.екецуте_блоцкед <п>Ово спречава четбот са малим ризиком да постане случајни агент за аутоматизацију. Такође подржава шаблоне улога: <ул> <ли><стронг>Помоћник програмера: ћаскање о моделу, претрага документације, објашњење кода, без алата за писање у производњи. <ли><стронг>Бот за подршку: тражење клијената, прављење тикета, састављање одговора, потребно је одобрење за спољна слања. <ли><стронг>Агент аналитичара: упити складишта података само за читање са ограничењима редова, подразумевано нема извоза клијената. <ли><стронг>Администраторски агент: уске привилеговане операције, снажно одобрење, краткотрајни кључеви, потпуна ревизија. <ли><стронг>Агент закупца препродавача: приступ моделу закупца, алатке закупца, лимит буџета по клијенту. <п>Препорука је да се не затвори: непознате алатке су одбијене, недостајући опсег одбија извршење, новооглашени МЦП алати су неактивни док се не одобре, а локални алати морају да користе исти омотач смерница као хостовани алати. <х2>Корак 3: Класификујте алате према радијусу разбијања <п>Није за сваки позив алатки потребно људско одобрење. Управљање треба да буде пропорционално ризику. Користан модел класификације је: <табле> <тхеад> <тр><тх>Ниво ризика<тх>Примери<тх>Подразумевана контрола <тбоди> <тр><тд>Јавно само за читање<тд>Претрага јавних докумената, преузимање јавног веб-сајта<тд>Дозволи са ограничењима брзине <тр><тд>Интерни само за читање<тд>Интерни вики, документи производа<тд>Дозволи тимове са опсегом; редиговати дневнике <тр><тд>Подаци о клијентима само за читање<тд>Тражење налога, историја подршке<тд>Провере опсега закупаца и корисника; строга ревизија <тр><тд>Реверзибилно уписивање<тд>Креирај тикет, додај нацрт напомене<тд>Дозволи са ограничењима и власником враћања <тр><тд>Спољна комуникација<тд>Пошаљите е-пошту, поставите поруку, објавите садржај<тд>Одобрење или преглед за већину случајева употребе <тр><тд>Неповратно писање<тд>Избришите запис, пошаљите правни образац<тд>Одбијте подразумевано или захтевајте одобрење са високим поверењем <тр><тд>Финансијске радње<тд>Рефундирање, куповина, промена обрачуна<тд>Снажно одобрење, ниска ограничења, потпуна ревизија <тр><тд>Извршавање кода<тд>Покрените схелл, извршите Питхон, примените скрипту<тд>Заштићено окружење, мрежна ограничења, временска ограничења, одобрење где је потребно <тр><тд>Привилеговани администратор<тд>Креирај корисника, мењај улоге, ротирај акредитиве<тд>Одбиј подразумевано; само процес разбијања стакла <п>Ова класификација би требало да буде видљива у прегледу кода и у корисничком интерфејсу администратора. Сами описи алата нису довољни јер агенти могу третирати описе као упутства. Механизам за смернице треба да се ослања на метаподатке регистратора и опсеге, а не само на називе алата на природном језику. <х2>Корак 4: Додајте капије за одобрење за радње високог ризика<п>Одобрење треба да буде циљано. Ако сваки позив алата захтева особу, агент постаје неупотребљив. Ако ниједан позив алата не захтева одобрење, систем може да одобри прекомерну агенцију. <п>Уобичајени ток одобравања: <ол> <ли>Агент захтева позив алатке са структурираним аргументима. <ли>Гатеваи процењује идентитет, обим, ниво ризика, буџет и смернице. <ли>Ако је потребно одобрење, мрежни пролаз враћа догађај одобрења на чекању уместо да изврши алатку. <ли>Апликација приказује преглед кориснику или шаље оперативно обавештење каналу за одобрење. <ли>Одобравач може да одобри, одбије, измени аргументе ако смернице дозвољавају или да захтева појашњење. <ли>Гатеваи бележи одлуку и извршава само одобрену верзију. <п>Корисни терет за одобрење треба да приказује радњу у људским терминима, а не само необрађени ЈСОН: <пре><цоде>{ "аппровал_ид": "аппр_123", "агент_рун_ид": "рун_456", "рекуестед_би_усер": "усер_789", "тоол_ид": "емаил.сенд", "риск_тиер": "ектернал_цоммуницатион", "суммари": "Пошаљите одговор на цустомер@екампле.цом о тикету #4812", "редацтед_аргументс": { "за": "купац@екампле.цом", "субјецт": "Ажурирање тикета #4812", "боди_хасх": "сха256:..." }, "екпирес_ат": "2026-08-09Т12:30:00З" } <п>Одобрење је најкорисније за спољну комуникацију, финансијске акције, неповратно писање, привилеговану администрацију и широк извоз података. Обично није потребно за претрагу јавне документације малог обима. <х2>Корак 5: Пратите буџете по алатима и ограничења стопе <п>Буџет токена није довољан. Јефтин модел може покренути скупе претраге, сесије претраживача, покретање кода, позиве АПИ-ја трећих страна или дуге петље алата. Гејтвеј треба да прати најмање четири бројача: <ул> <ли><стронг>Број позива по алатки: максимални број позива по покретању, кориснику, закупцу и временском периоду. <ли><стронг>Трошкови по алату: директне накнаде треће стране, цена прегледача/времена извођења, цена претраге или интерна процена повраћаја средстава. <ли><стронг>Кумулативни трошак покретања агента: токени модела плус трошкови алата. <ли><стронг>Дубина петље: максималан број итерација модел-алатка-модел. <п>Када се достигне ограничење, мрежни пролаз треба да избегава тихи тешки квар када је то могуће. Безбеднији обрасци деградације укључују враћање резимеа напретка, тражење одобрења за наставак, смањење дубине преузимања, стављање позадинског посла у ред чекања или прелазак на режим само за читање. Чврсто порицање је и даље прикладно за блокиране алате, недостајуће опсеге, непознате МЦП могућности и опасне радње. <х2>Корак 6: Спојите телеметрију модела и алата у један запис ревизије <п>Отклањање грешака агента не успева када евиденције модела живе на једном месту, а евиденције алата живе негде другде. Запис ревизије треба да повеже цео ланац: <ул> <ли>Кључ закупца, радног простора, корисника, налога услуге и мрежног пролаза. <ли>ИД агента, верзија агента, верзија шаблона упита и ИД модела. <ли>Назив алата, верзија регистратора, УРЛ адреса сервера или окружење за извршавање и хеш шеме. <ли>Хеш за унос алата или редиговани унос, подразумевано никада необрађено осетљиво оптерећење. <ли>Статус одобрења, идентитет одобраваоца, временска ознака одобрења и хеш одобреног аргумента. <ли>Кашњење, поновни покушаји, грешке добављача, грешке алата, цена токена, цена алата и коначни исход. <ли>Референца за враћање, ако је радња променила стање. <п>ОпенАИ-јева Агентс СДК документација за праћење укључује трагове за ЛЛМ генерације, позиве алата, примопредаје, заштитне ограде и прилагођене догађаје, што подржава шири принцип уочљивости: трагови агента треба да укључују активност алата, а не само употребу токена и кашњење. Међутим, један СДК цевовод можда неће покривати сваки хостовани алат, локалну путању извршења или интерни АПИ. Ревизија на нивоу мрежног пролаза помаже у нормализацији записа међу добављачима и оквирима. <п>Приватност је важна. Детаљни записници побољшавају отклањање грешака и преглед усклађености, али необрађени промпт и задржавање корисног оптерећења алата могу створити нову безбедносну обавезу. Редигујте или хеширајте уносе који садрже тајне, акредитиве, податке о плаћању, личне податке или власничке документе. Чувајте необрађене корисне податке само под експлицитним смерницама задржавања, контролама приступа и правилима за брисање. <х2>Корак 7: Третирајте МЦП сервере и алате треће стране као зависности од ланца снабдевања <п>МЦП сервери и алати независних произвођача треба да прођу кроз исти процес прегледа као библиотеке, веб-хукови и инфраструктурне зависности. Препоручене контроле укључују: <ул> <ли>Одржавајте листу дозвољених одобрених МЦП сервера и порекла алата. <ли>Закачите верзије где је могуће и забележите хешове шеме. <ли>Захтева власника за сваки сервер и алатку високог ризика. <ли>Прегледајте називе алата, описе, шеме и захтеве за дозволе пре него што их омогућите. <ли>Онемогући новододате алатке док их не прегледамо.<ли>Провери потребне опсеге по рути или могућности. <ли>Одвојите акредитиве закупца и избегавајте дељене токене међу клијентима. <ли>Покрени непоуздане или високоризичне алатке у сандбоковима са ограничењима мреже и система датотека. <п>Чињеница да је алатка изложена путем стандардног протокола не чини га безбедном. Управљачком слоју је и даље потребно најмање привилегија, експлицитна овлашћења, контрола верзија и могућност ревизије. <х2>Контролна листа имплементације <х3>Дизајн политике <ул> <ли>Дефинишите шаблоне улога за уобичајене кориснике агената и налоге услуга. <ли>Креирајте засебне опсеге за позиве модела и позиве алата. <ли>Класификујте алате према осетљивости података, реверзибилности, спољном утицају, финансијском утицају и нивоу привилегија. <ли>Подесите понашање одбијања по подразумеваној вредности за непознате алате и недостајуће опсеге. <ли>Дефинишите правила одобравања само за радње високог ризика. <х3>Примена мрежног пролаза <ул> <ли>Захтевати од сваког агента да позове алате преко мрежног пролаза или потписаног омотача политике. <ли>Проверите закупца, корисника, кључ, агента, модел, алат, обим, буџет и статус одобрења пре извршења. <ли>Омогућите максималну дубину позивања алата и кумулативну цену рада. <ли>Снимите верзију регистра алата и хеш шеме за сваки позив. <ли>Неуспешно затварање када механизам за смернице не може да донесе одлуку. <х3>Ревизија и операције <ул> <ли>Придружи се позивима модела и позивима алата под једним ИД-ом праћења или покретања агента. <ли>Преправи или хеш осетљиве уносе алата подразумевано. <ли>Сачувајте доказе о одобрењу уз коначни записник о извршењу. <ли>Изложите администраторима анализу трошкова и ограничења стопе по алату. <ли>Документирајте власнике враћања докумената за алатке које мењају стање. <х2>Очекују се компромиси <п><стронг>Доследност наспрам напора интеграције. Управљање на нивоу мрежног пролаза даје доследну примену у моделима, пакетима за развој софтвера и тимовима. Цена је усвајање: програмери морају да усмере извршење алата кроз одобрену путању уместо да позивају алате директно из кода апликације. <п><стронг>Најмање привилегија у односу на сложеност политике. Фино-зрнасти опсег смањује радијус експлозије, али захтевају шаблоне, конвенције о именовању и редовно чишћење. Без шаблона, тимови могу да дају прекомерне дозволе за брже кретање. <п><стронг>Одобрење против аутономије. Људско одобрење смањује ризик од неповратних радњи, али додаје кашњење. Користите одобрења за високоризичне алате, а не за свако тражење или претрагу. <п><стронг>Проверљивост наспрам изложености подацима. Богати евиденције помажу у одговору на инциденте и отклањању грешака. Необрађено евидентирање корисног терета може открити тајне и личне податке. Редакција, хеширање, конфигурабилно задржавање и преглед приступа нису опциони детаљи. <п><стронг>Тврда ограничења у односу на завршетак задатка. Ограничења трошкова по алату спречавају агенте да одбегну. Они такође могу прекинути легитиман дуготрајан рад. Наведите путање за наставак као што су одобрење за наставак, позадински редови или сумирани делимични резултати. <х2>Предвиђања: куда иде овај образац <п>Предвиђање: управљање агентима ће постати више усредсређено на идентитет. Тимови ће ређе питати „који је модел користио овај модел?“ и чешће „која аутентификована особа или услуга је дозволила ову радњу алата?“ <п>Предвиђање: регистри алата ће постати нормални као регистри модела. Како се МЦП сервери, интерни АПИ-ји и хостовани алати множе, производним тимовима ће бити потребан инвентар дозвољених могућности, власника, шема и нивоа ризика. <п>Предвиђање: управљање трошковима ће прећи са извештавања само о токенима на извештавање на нивоу радње. Најскупљи део покретања агента може бити преузимање, аутоматизација прегледача, извршавање кода или АПИ-ји треће стране, а не сам позив модела. <х2>Закључак који се може применити <п>Почните са једним правилом: кључ модела није кључ алата. Затим изградите споља. Направите регистар одобрених алата, доделите власнике и нивое ризика, захтевајте експлицитне опсеге, додајте одобрења само тамо где радња има значајан радијус експлозије, примените буџете по алату и спојите догађаје модела и алата у један ревизијски траг.<п>Циљ није учинити агенте немоћним. Циљ је да њихова моћ буде читљива, обимна, реверзибилна где је то могуће и одговорна. То је практична основа за управљање тимским АПИ-јем док агенти прелазе са одговарања на питања на предузимање радњи.<х2>Повезано читање<ул><ли><а хреф="хттпс://модел-гате.цом/ен/блог/ллм-апи-кеи-манагемент-теамс-исолатион-ротатион-спенд-лимитс-4/">теам ротатион-лимитс-леак-респонсе праксе<ли><а хреф="хттпс://модел-гате.цом/ен/блог/ллм-обсервабилити-мулти-модел-апи-гатеваи-трацес-токен-ледгерс-сафе-промпт-логгинг-9/">придружених трагова, књига токена и безбедног брзог евидентирања<ли хреф="хттпс://модел-гате.цом/ен/блог/струцтуред-оутпутс-мулти-модел-апи-гатеваи-јсон-сцхема-тоол-цаллс-6/">структурирани резултати и обрасци валидације позива алата