Aģenta rīka pārvaldība, izmantojot AI API vārteju: jomas, apstiprinājumi, budžeti un audita pēdas
Praktiska atsauces arhitektūra aģentu rīku pārvaldībai, izmantojot AI API vārteju: rīku reģistri, aptvertās atslēgas, apstiprināšanas vārti, katra rīka budžeti, MCP atļauju saraksti un apvienotās modeļa/rīka audita pēdas.
Aģenta risks vairs neaprobežojas tikai ar modeļa uzvedni. Ražošanas aģents var meklēt iekšējos failos, pieprasīt klientu ierakstus, izsaukt MCP serveri, izpildīt kodu, atvērt pārlūkprogrammu, sūtīt e-pastu, atjaunināt CRM vai aktivizēt norēķinu darbplūsmu. Pārvaldības jautājums ir šāds: kuram lietotājam, atslēgai, modelim, aģentam un rīkam bija atļauts veikt kādu darbību, ar kādu budžetu, audita izsekojamību un atcelšanas ceļu?
Ja katra komanda nodrošina piekļuvi rīkiem savā SDK kodā, politika tiek izkaisīta pa vides mainīgajiem, nodrošinātāja informācijas paneļiem, lietojumprogrammu starpprogrammatūru un nedokumentētiem MCP serveriem. Drošāks modelis ir aģenta rīka izpildi uzskatīt par vadības plaknes problēmu un ieviest to, izmantojot AI API vārteju vai standarta rīka izpildes ietvaru, kas jāizmanto katram aģentam.
Šajā rakstā ir izdalīti fakti, ieteikumi un prognozes. Fakti ir iegūti no pašreizējām publiskajām vadlīnijām: OWASP LLM lietojumprogrammu top 10 ietver tādus riskus kā sensitīvas informācijas izpaušana, piegādes ķēdes ievainojamība un pārmērīga rīcības brīvība; NIST ģeneratīvais AI profils AI riska pārvaldības sistēmai uzsver ģeneratīvo AI risku kartēšanu, mērīšanu un pārvaldību; OpenAI aģenta norādījumi iesaka novērtēt rīka risku pēc lasīšanas/rakstīšanas piekļuves, atgriezeniskuma, atļaujām un finansiālās ietekmes; un MCP autorizācijas vadlīnijās tiek izmantotas tvēruma autorizācijas koncepcijas sensitīviem resursiem un darbībām. Tālāk sniegtie ieteikumi ir ieviešanas modeļi, nevis universālas prasības.
Lasītāja problēma: tiek sajaukta piekļuve modelim un rīka piekļuve
Daudzās sākotnējās LLM lietojumprogrammās API atslēga atbildēja uz vienu pamatjautājumu: vai šis pakalpojums var izsaukt modeli? Aģenti to padara pārāk rupju. Atslēgai, kas var nosūtīt tērzēšanas pabeigšanas datus, nevajadzētu automātiski eksportēt klientu datus, palaist čaulas komandas, publicēt Slack, modificēt biļetes, pārlūkot patvaļīgas vietnes vai iesniegt maksājumu izmaiņas.
Pārvaldības slānim ir jāatbild uz konkrētākiem jautājumiem:
- Kurs nomnieks, darbvieta, lietotājs, pakalpojuma konts vai tālākpārdevēja klients uzsāka izpildi?
- Kurs modelis, uzvednes veidne, aģenta versija un rīka shēma tika izmantota?
- Vai pieprasītais rīks bija tikai lasāms, atgriezenisks, neatgriezenisks, ārējs, finansiāls vai priviliģēts?
- Vai pieprasītājam bija nepieciešamais apjoms?
- Vai apstiprinājums bija vajadzīgs, piešķirts, noraidīts, beidzies derīguma termiņš vai apiets saskaņā ar ārkārtas situāciju politiku?
- Cik rīks maksāja, cik reižu tas tika izsaukts un kāds kumulatīvs budžets palika?
- Kādi pierādījumi pastāv par atkļūdošanu, atbilstības pārskatīšanu un atcelšanu?
Tālāk redzamā arhitektūra pieņem, ka vārteja jau saņem modeļa zvanus. Pēc tam rīka izpildi var novirzīt caur to pašu vārteju, izmantojot blakusvāģa pakalpojumu vai standarta bibliotēku, kas ziņo vārtejai pirms un pēc katra rīka izsaukuma.
Atsauces arhitektūra: vārtejas līmeņa rīku pārvaldības slānis
Praktiskajai aģentu pārvaldības sistēmai ir septiņi komponenti:
- Rīku reģistrs: autoritatīvs apstiprināto rīku, MCP serveru, mitināto funkciju, vietējo izpildes rīku un iekšējo API saraksts.
- Identitāte un atslēgu slānis: vārtejas atslēgas, lietotāji, nomnieki, pakalpojumu konti, komandas un tālākpārdevēju klienti.
- Tvēruma programma: politikas pārbaudes, kas nosaka, vai atslēga vai lietotājs var izsaukt konkrētu rīka iespēju.
- Riska klasifikators: metadati, kas apraksta sprādziena rādiusu, datu jutīgumu, atgriezeniskumu, ārējo ietekmi un izmaksu ietekmi.
- Apstiprināšanas darbplūsma: cilvēka vai sistēmas apstiprinājums augsta riska darbībām pirms izpildes.
- Budžeta un likmju ierobežojumu virsgrāmata: ierobežojumi katram rīkam un aģentam, ne tikai katra modeļa pilnvaras ierobežojumi.
- Pārbaudes un izsekošanas krātuve: apvienotie ieraksti modeļu izsaukumiem, rīku izsaukumiem, apstiprinājumiem, kļūdām un rezultātiem.
Svarīgs dizaina lēmums ir padarīt vārteju par politikas lēmuma pieņemšanas punktu, pat ja faktiskais rīks darbojas citur. Piemēram, pārlūkprogrammas rīks var tikt izpildīts smilškastes darbiniekā, un CRM rakstīšana var tikt izpildīta iekšējā pakalpojumā. Vārteja joprojām novērtē, vai zvans ir atļauts, reģistrē lēmumu, izseko izmaksas un atgriež parakstītu pilnvarošanas lēmumu vai atteikumu.
1. darbība. Izveidojiet centrālo rīku reģistru
Rīku reģistrs ir krājums, kas neļauj “nezināma aģenta iespējai” kļūt par noklusēto. Katram rīkam ir jābūt īpašniekam, riska līmenim un darbības metadatiem. Minimālais reģistra ieraksts var izskatīties šādi:
{
"tool_id": "crm.create_ticket",
"display_name": "Izveidot CRM atbalsta biļeti",
"owner_team": "atbalsta automatizācija",
"execution_type": "internal_api",
"servera_url": "https://tools.internal.example/crm",
"allowed_tenants": ["uzņēmums", "atbalsts"],"allowed_models": ["vispārīgi liels", "vispārīgi ātri"],
"risk_tier": "reversible_write",
"data_classification": "customer_metadata",
"required_scopes": ["tool:crm.create_ticket"],
"approval_policy": "not_required_under_100_tickets_per_day",
"default_timeout_ms": 8000,
"max_cost_per_call_usd": 0,05,
"max_calls_per_run": 3,
"rollback_owner": "support-ops-oncall",
"retention_policy": "redacted_30_days"
}MCP serveriem reģistrā jāiekļauj arī servera URL, reklamētie rīki, shēmas versija, autorizācijas metode, pēdējās pārskatīšanas datums un tas, vai jaunie rīki pēc noklusējuma ir atspējoti. MCP uzlabo sadarbspēju, taču protokolu saderība nav tas pats, kas ražošanas atļauja. Sensitīviem resursiem un darbībām joprojām ir nepieciešamas precīzas darbības jomas, maršruta pārbaudes un nomnieka izolācija.
Ieteicamie reģistra lauki
- Rīka nosaukums, kanoniskais ID, īpašnieks un dežūrkontaktpersona.
- Izpildes vieta: mitināts nodrošinātāja rīks, MCP serveris, iekšējais API, pārlūkprogrammas darbinieks, koda izpildītājs, rindas uzdevums vai lokālais SDK rīks.
- Atļautie nomnieki, komandas, lietotāji, aģentu versijas un modeļu profili.
- Datu klasifikācija: publiskie, iekšējie, klientu metadati, klientu saturs, noslēpumi, maksājumu dati, akreditācijas dati, regulētie dati.
- Riska līmenis un atgriezeniskums.
- Nepieciešamās darbības jomas un apstiprināšanas politika.
- Noildze, tarifu ierobežojumi, maksimālais zvanu skaits vienā skrējienā, kumulatīvais izpildes budžets un maksimālā maksa par zvanu.
- Reģistrācijas režīms: pilna lietderīgā slodze ir aizliegta, rediģēta, jaukta, atlasīta vai nepārprotami saglabāta.
- Atcelšanas norādījumi un eskalācijas ceļš.
2. darbība. Atdaliet modeļa tvērumus no rīku tvērumiem
Ražošanas vārtejas atslēgai ir jānorāda, ko zvanītājs var darīt. Piekļuvei modeļiem un rīkiem jābūt neatkarīgām. Piemēram:
modelis:tērzēšana
modelis: iegulumi
rīks:docs.search_readonly
rīks:crm.create_ticket
tool:email.send_requires_approval
tool:billing.refund_blocked
tool:code.execute_blockedTādējādi zema riska tērzēšanas robots nekļūs par nejaušu automatizācijas aģentu. Tā atbalsta arī lomu veidnes:
- Izstrādātāja palīgs: modeļa tērzēšana, dokumentācijas meklēšana, koda skaidrojums, nav ražošanas rakstīšanas rīku.
- Atbalsta robots: klientu meklēšana, biļešu izveide, atbildes sastādīšana, ārējai sūtīšanai nepieciešama apstiprināšana.
- Analītiķis: tikai lasāmi datu noliktavas vaicājumi ar rindu ierobežojumiem, pēc noklusējuma neveic klientu eksportēšanu.
- Administratora aģents: šauras priviliģētas darbības, stingrs apstiprinājums, īslaicīgas atslēgas, pilnīga pārbaude.
- Tālākpārdevēja nomnieka aģents: nomnieka piekļuve modelim, nomnieka rīki, katra klienta budžeta griesti.
Ieteikums ir nesekmīgs aizvērts: nezināmi rīki tiek liegti, trūkstošie tvērumi liedz izpildi, tikko reklamētie MCP rīki ir neaktīvi līdz apstiprināšanai, un vietējiem rīkiem ir jāizmanto tas pats politikas ietvars kā mitinātajiem rīkiem.
3. darbība: klasificējiet rīkus pēc sprādziena rādiusa
Ne katram rīku izsaukumam ir nepieciešams cilvēka apstiprinājums. Pārvaldībai jābūt proporcionālai riskam. Noderīgs klasifikācijas modelis ir:
Šai klasifikācijai ir jābūt redzamai koda pārskatīšanā un administratora lietotāja saskarnē. Ar rīku aprakstiem vien nepietiek, jo aģenti aprakstus var uzskatīt par norādījumiem. Politikas programmai ir jāpaļaujas uz reģistra metadatiem un tvērumiem, nevis tikai uz rīku nosaukumiem dabiskajā valodā.
4. darbība. Pievienojiet apstiprinājuma vārtus augsta riska darbībām
Apstiprināšanai jābūt mērķtiecīgai. Ja katram instrumenta izsaukumam ir nepieciešama persona, aģents kļūst nelietojams. Ja nevienam rīka izsaukumam nav nepieciešams apstiprinājums, sistēma var piešķirt pārmērīgu pilnvarojumu.
Izplatīta apstiprināšanas plūsma:
- Aģents pieprasa rīka izsaukumu ar strukturētiem argumentiem.
- Vārteja novērtē identitāti, darbības jomu, riska līmeni, budžetu un politiku.
- Ja ir nepieciešams apstiprinājums, vārteja atgriež gaidošu apstiprinājuma notikumu, nevis izpilda rīku.
- Lietojumprogramma rāda lietotājam priekšskatījumu vai nosūta darbības paziņojumu apstiprināšanas kanālam.
- Apstiprinātājs var apstiprināt, noraidīt, rediģēt argumentus, ja politika atļauj, vai pieprasīt paskaidrojumus.
- Vārteja reģistrē lēmumu un izpilda tikai apstiprināto versiju.
Apstiprinājuma slodzei ir jāparāda darbība cilvēka izteiksmē, nevis tikai neapstrādātā JSON:
{
"approval_id": "apr_123",
"agent_run_id": "run_456",
"requested_by_user": "user_789",
"tool_id": "email.send",
"risk_tier": "external_communication",
"kopsavilkums": "Sūtīt atbildi uz [email protected] par biļeti #4812",
"redacted_arguments": {
"kam": "[email protected]",
"subject": "Atjauninājums par biļeti #4812",
"body_hash": "sha256:..."
},
"expires_at": "2026-08-09T12:30:00Z"
}Apstiprināšana ir visnoderīgākā ārējai saziņai, finanšu darbībām, neatgriezeniskām rakstībām, priviliģētai administrācijai un plašai datu eksportēšanai. Parasti tas nav nepieciešams neliela apjoma publiskas dokumentācijas meklēšanai.
5. darbība. Izsekojiet katra rīka budžetu un ātruma ierobežojumus
Ar marķiera budžetu nepietiek. Lēts modelis var izraisīt dārgu meklēšanu, pārlūkprogrammas sesijas, koda palaišanu, trešās puses API izsaukumus vai garas rīku cilpas. Vārtejai ir jāseko vismaz četriem skaitītājiem:
- Rīka zvanu skaits: maksimālais zvanu skaits vienā izpildē, lietotājs, nomnieks un laika periods.
- Maksa par vienu rīku: tiešās trešās puses izmaksas, pārlūkprogrammas/izpildlaika izmaksas, meklēšanas izmaksas vai iekšējā atmaksas aprēķins.
- Kumulatīvās aģenta darbības izmaksas: modeļa marķieri plus rīku izmaksas.
- Cilpas dziļums: maksimālais modeļa-rīka-modeļa iterāciju skaits.
Kad ir sasniegts ierobežojums, vārtejai, ja iespējams, ir jāizvairās no klusas cietas atteices. Drošāki degradācijas modeļi ietver progresa kopsavilkuma atgriešanu, apstiprinājuma pieprasīšanu turpināšanai, izguves dziļuma samazināšanu, fona darba iestatīšanu rindā vai pārslēgšanos uz tikai lasīšanas režīmu. Stingrs noliegums joprojām ir piemērots bloķētiem rīkiem, trūkstošiem tvērumiem, nezināmām MCP iespējām un bīstamām darbībām.
6. darbība. Modeļa un rīka telemetrijas apvienošana vienā audita ierakstā
Aģenta atkļūdošana neizdodas, ja modeļu žurnāli atrodas vienā vietā un rīku žurnāli atrodas citur. Audita ierakstam ir jāsavieno visa ķēde:
- Īrnieks, darbvieta, lietotājs, pakalpojuma konts un vārtejas atslēga.
- Aģenta ID, aģenta versija, uzvednes veidnes versija un modeļa ID.
- Rīka nosaukums, reģistra versija, servera URL vai izpildes vide un shēmas jaucējvārds.
- Rīka ievades jauktais vai rediģēta ievade, pēc noklusējuma nekad neapstrādātas sensitīvas slodzes.
- Apstiprinājuma statuss, apstiprinātāja identitāte, apstiprinājuma laikspiedols un apstiprinātā argumenta jaukšana.
- Latentums, mēģinājumi, pakalpojumu sniedzēja kļūdas, rīku kļūdas, pilnvaras izmaksas, instrumenta izmaksas un gala rezultāts.
- Atcelšanas atsauce, ja darbības statuss ir mainīts.
OpenAI aģentu SDK izsekošanas dokumentācijā ir iekļautas LLM paaudžu izsekošanas, rīku izsaukšanas, nodošanas, aizsargmargas un pielāgotu notikumu pēdas, kas atbalsta plašāku novērojamības principu: aģenta izsekošanas dokumentācijā ir jāietver rīka darbība, ne tikai marķiera lietojums un latentums. Tomēr viens SDK konveijers var neaptvert katru mitināto rīku, vietējo izpildes ceļu vai iekšējo API. Vārtejas līmeņa audits palīdz normalizēt ierakstus starp nodrošinātājiem un ietvariem.
Privātums ir svarīgs. Detalizēti žurnāli uzlabo atkļūdošanu un atbilstības pārskatīšanu, taču neapstrādāta uzvedne un rīka lietderīgās slodzes saglabāšana var radīt jaunas drošības saistības. Rediģēt vai jaukt ievades datus, kas satur noslēpumus, akreditācijas datus, maksājumu datus, personas datus vai patentētus dokumentus. Saglabājiet neapstrādātas lietderīgās slodzes tikai saskaņā ar nepārprotamu saglabāšanas politiku, piekļuves vadīklām un dzēšanas noteikumiem.
7. darbība. Uztveriet MCP serverus un trešo pušu rīkus kā piegādes ķēdes atkarības
MCP serveriem un trešo pušu rīkiem ir jāveic tāds pats pārskatīšanas process kā bibliotēkām, tīmekļa aizķerēm un infrastruktūras atkarībām. Ieteicamās vadīklas ir šādas:
- Uzturiet apstiprināto MCP serveru un rīku izcelsmes atļaušanas sarakstu.
- Piespraust versijas, ja iespējams, un ierakstīt shēmu jaucējvārdus.
- Pieprasiet īpašnieku katram serverim un augsta riska rīkam.
- Pirms to iespējošanas pārskatiet rīku nosaukumus, aprakstus, shēmas un atļaujas.
- Atspējojiet tikko pievienotos rīkus, līdz tie tiks pārskatīti.
- Pārbaudiet nepieciešamo tvērumu katram maršrutam vai iespējām.
- Atdaliet nomnieka akreditācijas datus un izvairieties no koplietotiem marķieriem starp klientiem.
- Palaidiet neuzticamus vai augsta riska rīkus smilšu kastēs ar tīkla un failu sistēmas ierobežojumiem.
Fakts, ka rīks ir pakļauts standarta protokolam, nepadara to drošu. Pārvaldības slānim joprojām ir vajadzīgas vismazākās privilēģijas, skaidra autorizācija, versiju kontrole un pārbaudāmība.
Ieviešanas kontrolsaraksts
Politikas dizains
- Definējiet lomu veidnes parastajiem aģentu lietotājiem un pakalpojumu kontiem.
- Izveidojiet atsevišķus tvērumus modeļu izsaukumiem un rīku izsaukumiem.
- Klasificējiet rīkus pēc datu jutīguma, atgriezeniskuma, ārējās ietekmes, finansiālās ietekmes un privilēģiju līmeņa.
- Iestatiet aizliegumu pēc noklusējuma nezināmiem rīkiem un trūkstošajiem tvērumiem.
- Definējiet apstiprināšanas noteikumus tikai augsta riska darbībām.
Vārtejas izpilde
- Pieprasiet, lai katrs aģents izsauktu rīkus, izmantojot vārteju vai parakstītu politikas iesaiņojumu.
- Pirms izpildes pārbaudiet nomnieku, lietotāju, atslēgu, aģentu, modeli, rīku, darbības jomu, budžetu un apstiprinājuma statusu.
- Ieviesiet maksimālo rīku izsaukšanas dziļumu un kumulatīvās darbības izmaksas.
- Ierakstiet rīka reģistra versiju un shēmas jaucējkodu katram zvanam.
- Neizdevās aizvērt, ja politikas programma nevar pieņemt lēmumu.
Audits un darbības
- Savienojiet modeļu izsaukumus un rīku izsaukumus ar vienu trasēšanas vai aģenta izpildes ID.
- Pēc noklusējuma rediģējiet vai jaukšanas jutīgās rīka ievades.
- Saglabājiet apstiprinājuma pierādījumus kopā ar galīgo izpildes ierakstu.
- Atklājiet administratoriem informāciju par katra rīka izmaksām un ātruma ierobežojumu analīzi.
- Dokumentu atcelšanas īpašniekiem rīkiem, kuru statuss mainās.
Sagaidāmi kompromisi
Konsekvence salīdzinājumā ar integrācijas centieniem. Vārtejas līmeņa pārvaldība nodrošina konsekventu izpildi visos modeļos, SDK un komandās. Izmaksas ir pieņemšana: izstrādātājiem ir jānovirza rīka izpilde pa apstiprināto ceļu, nevis jāizsauc rīki tieši no lietojumprogrammas koda.
Mazākās privilēģijas salīdzinājumā ar politikas sarežģītību. Precīzi tvērumi samazina sprādziena rādiusu, taču tiem ir nepieciešamas veidnes, nosaukumu piešķiršanas metodes un regulāra tīrīšana. Ja nav veidņu, komandas var piešķirt pārāk lielas atļaujas, lai pārvietotos ātrāk.
Apstiprinājums pret autonomiju. Cilvēka apstiprinājums samazina neatgriezenisku darbību risku, taču palielina latentumu. Izmantojiet apstiprinājumus augsta riska rīkiem, nevis katru meklēšanu vai meklēšanu.
Auditējamība salīdzinājumā ar datu ekspozīciju. Bagātīgi žurnāli palīdz reaģēt uz incidentiem un atkļūdot. Neapstrādāta kravas reģistrēšana var atklāt noslēpumus un personas datus. Rediģēšana, jaukšana, konfigurējama saglabāšana un piekļuves pārskatīšana nav obligāta informācija.
Stingri ierobežojumi salīdzinājumā ar uzdevuma pabeigšanu. Katra instrumenta izmaksu ierobežojumi neļauj bēgt aģentiem. Tie var arī pārtraukt likumīgu ilgstošu darbu. Norādiet turpināšanas ceļus, piemēram, apstiprinājumu, lai turpinātu, fona rindas vai apkopotus daļējos rezultātus.
Prognozes: kur virzās šis modelis
Prognoze: aģentu pārvaldība kļūs vairāk orientēta uz identitāti. Komandas retāk jautās “kurš modelis tika izmantots?” un biežāk “kura autentificēta persona vai pakalpojums atļāva veikt šo rīku?”
Paredze: rīku reģistri kļūs tikpat normāli kā modeļu reģistri. MCP serveriem, iekšējiem API un mitinātajiem rīkiem vairojoties, ražošanas komandām būs nepieciešams atļauto iespēju, īpašnieku, shēmu un riska līmeņu inventārs.
Paredzēšana: izmaksu pārvaldība pāries no ziņošanas tikai ar marķieri uz darbības līmeņa ziņošanu. Aģenta darbības dārgākā daļa var būt izguve, pārlūkprogrammas automatizācija, koda izpilde vai trešās puses API, nevis pats modeļa izsaukums.
Lietojams secinājums
Sāciet ar vienu noteikumu: modeļa atslēga nav rīka atslēga. Pēc tam veidojiet uz āru. Izveidojiet apstiprināto rīku reģistru, piešķiriet īpašniekus un riska līmeņus, pieprasiet precīzas darbības jomas, pievienojiet apstiprinājumus tikai tad, ja darbībai ir nozīmīgs sprādziena rādiuss, ieviesiet katra rīka budžetus un apvienojiet modeļu un rīku notikumus vienā audita izsekojamībā.
Mērķis nav padarīt aģentus bezspēcīgus. Mērķis ir padarīt to spēku salasāmu, aptveramu, atgriezenisku, ja iespējams, un atbildīgu. Tas ir komandas API pārvaldības praktiskais pamats, aģentiem pārejot no atbildēm uz jautājumiem un beidzot ar darbību veikšanu.