Kā izveidot LLM API galvenās pārvaldības sistēmu komandām

Koplietotās LLM nodrošinātāja atslēgas ir ērtas līdz pirmajai izslēgšanai, norēķinu pieaugumam, partneru integrācijai vai noslēpuma noplūdei. Praktiskā problēma nav tikai viena atslēga. Tā ir tāda, ka koplietota atslēga padara īpašumtiesības neskaidras, grūti attiecināmus izdevumus un riskantu ārkārtas atsaukšanu, jo vairākas lietojumprogrammas var būt atkarīgas no viena akreditācijas datu.

Darbspējīgai AI API atslēgas pārvaldības sistēmai ir jāatbild uz pieciem jautājumiem par katru pieprasījumu: kam pieder šī piekļuve, ko tai atļauts darīt, cik daudz tā var tērēt, kā tiks atklāta neparasta lietošana un kā to var atsaukt, nenoņemot nesaistītas sistēmas?

Šajā rokasgrāmatā pārbaudītie fakti ir atdalīti no ieviešanas ieteikumiem. Fakti apraksta iespējas un riskus, ko dokumentējuši galvenie pakalpojumu sniedzēji vai drošības sistēmas. Ieteikumos ir aprakstīts praktisks darbības modelis komandām, kuras izmanto vairākus LLM nodrošinātājus.

Sāciet ar divu līmeņu akreditācijas datu modeli

Svarīgākais dizaina lēmums ir pārtraukt neapstrādātu augšupējo pakalpojumu sniedzēja atslēgu izplatīšanu lietojumprogrammās, skriptos, klēpjdatoros, CI uzdevumos un partneru sistēmās. Tā vietā izmantojiet divu līmeņu modeli:

• Pakalpojumu sniedzēja akreditācijas dati: atslēgas vai pakalpojuma akreditācijas dati, ko izdevuši AI pakalpojumu sniedzēji. Tie ir jāglabā tikai kontrolētā aizmugursistēmā, vārtejā, slepenajā pārvaldniekā vai līdzīgi ierobežotā pakalpojumā.
• Pārvaldītie iekšējie akreditācijas dati: komandām, lietojumprogrammām, vidēm, CI darbiem vai partneriem izsniegtās atslēgas. Šīs atslēgas izsauc jūsu kontrolētās piekļuves slāni, kurā tiek piemērota politika, maršrutēšana, telemetrija, ierobežojumi un atsaukšana.

Fakts: pakalpojumu sniedzēju norādījumi parasti iesaka nelietot API atslēgas ar komandas biedriem, iesaka drošu krātuvi un brīdina, ka noplūdušas atslēgas var izraisīt neatļautas darbības vai maksas. Pakalpojumu sniedzēju konsoles var arī atbalstīt projektu, darbvietu, atslēgas līmeņa lietojumu, ātruma ierobežojumu un budžeta vadīklas, lai gan iespējas atšķiras atkarībā no piegādātāja un plāna.

Ieteikums. Uztveriet pakalpojumu sniedzēja atslēgas kā infrastruktūras noslēpumus, nevis izstrādātāju ērtības pilnvaras. Izstrādātājiem ir jāsaņem regulējamās atslēgas, kuras var neatkarīgi ierobežot un atsaukt. Šī pieeja atbalsta uzņēmuma LLM API darbības, jo akreditācijas datu politiku, analīzi un izmaksu kontroli var konsekventi piemērot vairākiem modeļiem un pakalpojumu sniedzējiem.

Pirms vairāku atslēgu izdošanas definējiet atslēgu taksonomiju

Komandas bieži rada pārvaldības problēmas, izdodot atslēgas, pirms tās nosaka, ko katra atslēga pārstāv. Atslēgai vajadzētu būt vairāk nekā nejaušam noslēpumam. Tam ir jābūt pārvaldītam objektam ar metadatiem, īpašumtiesībām, politiku un dzīves cikla stāvokli.

Minimālais metadatu skaits katrai pārvaldītajai atslēgai

• Īpašnieku komanda: atbildīgā grupa, ne tikai individuālais pieprasītājs.
• Lietojumprogramma vai darba slodze: sistēma, pakalpojums, skripts vai integrācija, izmantojot atslēgu.
• Vide: ražošana, iestudēšana, izstrāde, CI, smilškaste vai partneris.
• Uzņēmējdarbības mērķis: klientu atbalsta kopsavilkums, iekšējā meklēšana, koda palīdzība, dokumentu izvilkšana, aģenta darbplūsma vai cits apstiprināts lietošanas gadījums.
• Atļautais modeļu saimes vai pakalpojumu sniedzēja maršruts: kuriem modeļiem vai pakalpojumu sniedzējiem var piekļūt atslēga.
• Datu jutīguma līmenis: vai pieprasījumos var būt ietverti publiski, iekšēji, konfidenciāli, reglamentēti vai klientu dati.
• Budžeta griesti: dienas, nedēļas, mēneša vai projekta līmeņa tēriņu ierobežojums.
• Likmes ierobežojumi: pieprasījumi minūtē, marķieri minūtē, vienlaicīgi veicami darbi vai pakešu ierobežojumi.
• Derīguma termiņš: nepieciešams pagaidu atslēgām un ieteicams lielākajai daļai neražošanas atslēgu.
• Ārkārtas kontaktpersona: komandas kanāls vai persona, kas ir atbildīga par incidentiem.

Vienkārša nosaukumu piešķiršanas metode palīdz operatoriem ātri saprast sprādziena rādiusu. Piemēram:

komanda: support-ops
lietotne: biļešu apkopotājs
env: prod
use_case: klientu atbalsta kopsavilkums
datu_līmenis: klienta konfidencialitāte
modeles_allowed: [modelis-ģimene-a, modelis-ģimene-b]
monthly_budget_usd: 2500
rotācijas_intervala_dienas: 90
owner_contact: #support-platform-alerts

Ieteikums: ražošanas sistēmām neizsniedziet vispārīgas atslēgas, kas nosauktas kādas personas vārdā, piemēram, alice-openai-key. Izmantojiet pakalpojumu konta īpašumtiesības un komandas atbildību, lai atslēga izturētu darbinieka lomu izmaiņas, vienlaikus saglabājot izsekojamību.

Atsevišķas vides, lai samazinātu sprādziena rādiusu

Nekad neizmantojiet vienu LLM API atslēgu ražošanas, iestudēšanas, izstrādes, CI un partneru vidēs. Darbības iemesls ir vienkāršs: šīm vidēm ir dažādi riska profili. Vietējā attīstībā izmantotā atslēga, visticamāk, tiks parādīta čaulas vēsturē, pagaidu failos, piezīmju grāmatiņās vai testu krātuvēs. Ražošanas atslēgai parasti ir lielākas kvotas un piekļuve sensitīvām darba slodzēm. Apvienojot tos, katra noplūde kļūst smagāka.

Praktiskā vides politika

• Ražošana: stingra apstiprināšana, pakalpojumu konta īpašumtiesības, zema pielaide plašai piekļuvei modeļiem, uzraudzīti budžeti un ārkārtas atsaukšanas procedūras.
• Pārskatīšana: līdzīgs ražošanas maršruts, taču zemāki ierobežojumi un bez ražošanas datu, ja vien tas nav skaidri apstiprināts.
• Izstrāde: zemākas kvotas, īss derīguma termiņš, ierobežots datu jutīgums un modeļu ierobežojumi, kas veicina drošu eksperimentēšanu.
• CI un automatizācija: speciālas atslēgas testa darbiem, etalonuzdevumiem, novērtēšanas konveijeriem un izlaiduma darbplūsmām.
• Partnera piekļuve: deleģētas vai partneru aptvertas atslēgas ar stingrām kvotām, dokumentāciju un novērojamību katram partnerim.

Kompozīcija: precīza vides atdalīšana palielina pārvaldāmo akreditācijas datu skaitu. Atbilde ir nesadalīt visu vienā koplietotā atslēgā. Atbilde ir nodrošināt nodrošināšanu, metadatu tveršanu, slepeno krātuvi un rotācijas statusu.

Lietojiet vismazāko privilēģiju politiku API slānī

LLM API atslēgai nevajadzētu nozīmēt neierobežotu piekļuvi katram modelim, galapunktam, konteksta lielumam un tēriņu līmenim. Lai iegūtu mazākās tiesības uz LLM akreditācijas datiem, ir nepieciešama vairāk nekā jā vai nē atļauju pārbaude.

Vadības, kuras ir vērts ieviest

• Atļautie modeļi: atslēgas lietošanas gadījumā atļaut tikai apstiprinātas modeļu saimes vai maršrutus.
• Maksimālais konteksta lielums: novērsiet nejaušu neparasti lielu dokumentu vai steidzamu komplektu iesniegšanu.
• Maksimālais izvades marķieris: ierobežojiet ģenerēšanas izmaksas un samaziniet ļaunprātīgas izmantošanas ietekmi.
• Galapunkta ierobežojumi: attiecīgā gadījumā atdaliet tērzēšanu, iegulšanu, pakešu, attēlu, rīku izmantošanu un aģenta darbplūsmas piekļuvi.
• Budžeta ierobežojumi: iestatiet atslēgas līmeņa, lietojumprogrammas līmeņa un komandas līmeņa griestus.
• Likmes ierobežojumi: ierobežojiet pieprasījumu pieaugumu un aizsargājiet iepriekšējās kvotas.
• IP vai tīkla ierobežojumi: piemērojiet, kad tas tiek atbalstīts un praktiski iespējams.
• Bloķēti lietošanas gadījumi: noliedziet zināmās neatļautās darbplūsmas, neapstiprinātos datu līmeņus vai augsta riska automatizācijas ceļus.

Piemēram, iekšējam dokumentācijas palīgam var būt atļauts izmantot iegulšanu un vidēja izmaksu teksta ģenerēšanas modeli, bet ne augstākās klases argumentācijas modeļus, lielapjoma pakešu darbus vai attēlu ģenerēšanu. Finanšu darbplūsmai var būt nepieciešama stingrāka datu apstrāde un šaurāka modeļa maršrutēšana. Izstrādes smilškastei var būt zems dienas ierobežojums un piekļuve tikai nesensitīviem testa datiem.

Ieteikums: ievietojiet politikas izpildi kontrolētās piekļuves slānī, nevis pilnībā paļaujieties uz lietojumprogrammas kodu. Lietojumprogrammu līmeņa pārbaudes ir noderīgas, taču tās ir vieglāk nejauši apiet, kad komandas kopē fragmentus, veido skriptus vai ātri pievieno jaunas integrācijas.

Instrumentējiet katru taustiņu, izmantojot lietojuma analīzi

Galvenā pārvaldība neizdodas, ja akreditācijas dati tiek izsniegti, bet netiek ievēroti. Uzraudzībai ir jāpadara katra pārvaldītā atslēga attiecināma un diagnosticējama.

Pēc noklusējuma tveramā telemetrija

• Atslēgas ID un atslēgas nosaukums, izņemot pašu slepeno vērtību.
• Īpašnieku komandas, lietojumprogrammas, vides un izmaksu centra tagi.
• Laika zīmogs, pieprasījumu skaits, marķiera apjoms un aptuvenās izmaksas.
• Nodrošinātājs, modelis, galapunkts, latentums, statusa kods un kļūdu kategorija.
• Avota lietojumprogramma, pakalpojuma konts, reģions vai tīkla izcelsme, ja pieejama.
• Politikas lēmumi, piemēram, atļauts, liegts, ierobežots, bloķēts budžets vai novirzīts uz atkāpšanos.

Fakts: lielākie AI pakalpojumu sniedzēji piedāvā noteikta veida lietojuma, izmaksu, projekta, darbvietas vai atslēgas līmeņa pārskatus. Precīzi pārskatu lauki un administratīvās API atšķiras atkarībā no pakalpojumu sniedzēja un plāna.

Ieteikums. Ja izmantojat vairākus pakalpojumu sniedzējus, normalizējiet lietošanas metadatus savā sistēmā. Pakalpojumu sniedzēja vietējie informācijas paneļi ir noderīgi, taču starpnodrošinātāju skats ir nepieciešams, ja viena komanda dažādām darba slodzēm var izmantot dažādus modeļus.

Tūlītējai un atbildes reģistrēšanai nepieciešama īpaša piesardzība. Detalizēti satura žurnāli var palīdzēt incidentu izmeklēšanā un kvalitatīvā atkļūdošanā, taču tie var arī radīt privātuma un atbilstības pienākumus. Drošāks noklusējuma risinājums ir reģistrēt metadatus, politikas lēmumus, izmaksas un jaucējus vai atsauces. Iespējojiet satura reģistrēšanu tikai apstiprinātiem lietošanas gadījumiem ar saglabāšanas noteikumiem un piekļuves vadīklām.

Izveidojiet brīdinājumus, kas agri konstatē akreditācijas datu ļaunprātīgu izmantošanu

Tēriņu sliekšņi ir nepieciešami, bet nav pietiekami. Noplūdusi atslēga var izraisīt aizdomīgus satiksmes modeļus, pirms tā sasniedz lielu rēķinu. Brīdināšanai jāapvieno izmaksas, apjoms, maršruts un uzvedības signāli.

Noderīgi brīdinājumi par anomālijām

• Izstrādes atslēga pēkšņi nosūta produkcijai līdzīgu trafika apjomu.
• Atslēga izmanto modeļu saimi, kas tā iepriekš nav izmantota.
• Tokena apjoms strauji palielinās, salīdzinot ar to pašu stundu vai dienu iepriekšējos periodos.
• Pieprasījumi nāk no jauna tīkla, reģiona, partnera vai izvietošanas mērķa.
• Kļūdu līmenis strauji palielinās, jo automatizēts klients agresīvi mēģina atkārtoti.
• Atslēga tuvojas 50%, 80% un 100% no budžeta griestiem.
• Neaktīva atslēga kļūst aktīva pēc nedēļām vai mēnešiem, kad tā netiek izmantota.

Paredzēšana. Tā kā komandas izvieto vairāk aģentu darbplūsmu un automatizētu LLM darbu, atslēgas līmeņa anomāliju noteikšana kļūs svarīgāka nekā ikmēneša rēķinu pārskatīšana. Problēmas radīsies mašīnas ātrumā, tāpēc pārvaldības sistēmām ir nepieciešami gandrīz reāllaika signāli.

Izveidojiet rotācijas darbplūsmu, kas neizraisa pārtraukumus

Bieži vien izvairās no atslēgu rotācijas, jo komandas baidās pārtraukt ražošanu. Šīs bailes ir pamatotas, ja rotācija ir manuāla un neizsekota. Drošāka rotācijas darbplūsma izmanto derīguma logus, kas pārklājas.

Rotācijas rokasgrāmata

1. Izveidojiet aizstāšanas atslēgu ar tādu pašu vai apzināti atjauninātu politiku.
2. Saglabājiet to apstiprinātajā slepenajā pārvaldniekā un pievienojiet tos pašus īpašnieka, lietojumprogrammas un vides metadatus.
3. Izvietojiet jauno atslēgu lietojumprogrammā vai darba slodzē, izmantojot parasto izlaišanas procesu.
4. Apstipriniet satiksmes maiņu, pārbaudot, vai pieprasījumi tiek saņemti ar jauno atslēgas ID.
5. Pagaidiet, līdz tiek pabeigts saskaņotais novērošanas logs, pietiekami ilgi, lai aptvertu plānotos darbus un fona darbiniekus.
6. Atsauciet veco atslēgu tikai pēc tam, kad esat apstiprinājis, ka nav palikusi likumīga trafika.
7. Ieraksta pabeigšana ar laikspiedolu, īpašnieku, iemeslu un visām politikas izmaiņām.

Pagaidu partneru koncepcijas pierādījumiem, īslaicīgām izstrādes atslēgām vai vienreizējiem novērtēšanas darbiem izmantojiet derīguma termiņus un automātiskus atgādinājumus. Ražošanas darba slodzēm izvēlieties rotācijas intervālu, kas atbilst jūsu drošības prasībām un izvietošanas termiņam. Ļoti īss kalpošanas laiks samazina iedarbību, bet var izraisīt pārtraukumus, ja slepenā izvietošana nav uzticama.

Kompozīcija: rotācijas biežums ir līdzsvars. Īsāki intervāli samazina ilgstošu iedarbību. Garāki intervāli samazina darbības troksni. Automatizācija maina līdzsvaru, padarot biežu rotāciju mazāk traucējošu.

Sagatavojiet noplūžu-reakcijas izpildgrāmatu, pirms notiek noplūde

Reakcija uz informācijas noplūdi nedrīkst sākt ar debatēm par to, kam pieder atslēga. Pārvaldības sistēmai ir jāparedz īpašumtiesības, nesenais lietojums un atsaukšanas iespējas.

Noplūdes novēršanas kontrolsaraksts

1. Identificējiet atslēgu no noplūdušās vērtības, prefiksa, jaucējkoda, atslēgas ID, repozitorija atrašanas vai vārtejas žurnāliem.
2. Atrodiet īpašnieku un vidi, izmantojot atslēgu reģistru.
3. Iesaldējiet vai atsauciet atslēgu atkarībā no smaguma pakāpes un pieejamajām nepārtrauktības iespējām.
4. Pārbaudiet neseno lietojumu, lai noteiktu neparastu pieprasījumu apjomu, modeļus, reģionus, galapunktus un izmaksas.
5. Aprēķiniet ekspozīciju, tostarp tēriņus, piekļuvi datiem un pieskarties pakārtotajām sistēmām.
6. Pagrieziet saistītos noslēpumus, ja atslēga tika glabāta citu akreditācijas datu tuvumā.
7. Paziņojiet ieinteresētajām personām, piemēram, īpašnieka komandu, drošības, finanšu, juridisko, partneru vadītāju vai klientu komandu, ja nepieciešams.
8. Dokumenta pamatcēlonis, piemēram, slepeni, klienta puses ekspozīcija, kopēta piezīmju grāmatiņa, nedrošs CI mainīgais vai partnera nepareiza rīcība.
9. Pievienojiet profilaktisku kontroli, piemēram, slepenu skenēšanu, īsāku derīguma termiņu, stingrāku politiku vai izvietošanas izmaiņas.

Fakts: API atslēgu atklāšana klienta puses vidēs, piemēram, pārlūkprogrammās vai mobilajās lietotnēs, ir plaši atzīta par nedrošu, jo var iegūt noslēpumus, kas tiek izplatīti galalietotāju ierīcēm. Mobilo lietojumprogrammu ekosistēmu pētījumos ir ziņots arī par pastāvīgu LLM API akreditācijas datu noplūdi, kas pastiprina nepieciešamību nodrošināt pakalpojumu sniedzēja akreditācijas datus no izplatītajiem klientiem.

Apstrādājiet partneru integrāciju ar deleģētu piekļuvi

Partneru integrācija rada īpašu pārvaldības problēmu. Partneriem ir nepieciešama stabila piekļuve, taču, nododot viņiem neapstrādātu nodrošinātāja atslēgu, tiek zaudēta pārāk liela kontrole un tiek vājināta attiecināšana. Ja partneris nepareizi konfigurē krātuvi vai pārsniedz saskaņoto lietojumu, pakalpojumu sniedzēja atslēgas īpašnieks uzņemas darbības un finansiālo risku.

Tā vietā izdodiet partneru darbības jomas atslēgas vai deleģētās piekļuves pilnvaras. Katram partnera akreditācijas datiem ir jābūt savai kvotai, apstiprinātiem galapunktiem, atļautajam lietošanas gadījumam, derīguma termiņa vai atjaunošanas datumam un atbalsta ceļam. Partneru datplūsmai ir jābūt redzamai atsevišķi no lietojumprogrammu iekšējās datplūsmas.

Partnera atslēgas politikas piemērs

partneris: acme-integration
env: ražošana
allow_endpoints: [čats]
allow_models: [approved-low-latency-model]
monthly_budget_usd: 500
rate_limit_rpm: 60
max_output_tokens: 800
content_logging: atspējots
renewal_review: 2026-12-31
support_contact: [email protected]

Ieteikums: iedarbiniet partneru atslēgas ar zemākām noklusējuma kvotām un palieliniet tās pēc stabilas datplūsmas novērošanas. Tas aizsargā abas puses: partneris iegūst skaidru integrācijas ceļu, un platformas īpašnieks saglabā atsaukšanu un tēriņu kontroli.

Izmantojiet nodrošinātāja vietējās vadīklas, taču tās nav atkarīgas no viena pakalpojumu sniedzēja modeļa

Pakalpojumu sniedzēju projekti, darbvietas, pakalpojumu konti, budžeta brīdinājumi, tarifu ierobežojumi un lietošanas pārskati ir vērtīgi. Izmantojiet tos. Tie samazina risku pie avota un var nodrošināt papildu izolācijas slāni.

Tomēr vairāku pakalpojumu sniedzēju komandas ātri saskaras ar nekonsekvenci. Viens pakalpojumu sniedzējs var atklāt atslēgas līmeņa lietošanas pārskatus; cits var strukturēt piekļuvi ap darbvietām; cits var piedāvāt dažādas administratīvās API vai ar plānu saistītas vadīklas. Ja komandas izmanto vairākus LLM nodrošinātājus, pārvaldībai ir jānormalizē to darbības modelis.

Ieteikums: saglabājiet iekšējo atslēgu reģistru un politikas slāni pat tad, ja pastāv nodrošinātāja vietējās vadīklas. Ja iespējams, kartējiet iekšējās atslēgas pakalpojumu sniedzēja projektiem vai darbvietām. Tas nodrošina drošības, platformas un finanšu komandām vienu vietu, kur atbildēt uz pamatjautājumiem: kam pieder šī datplūsma, kāda politika tiek piemērota, cik tas maksāja un kā to izslēgt?

Ieviešanas kontrolsaraksts

• Izveidojiet atslēgu reģistru ar īpašnieku, lietojumprogrammu, vidi, mērķi, datu līmeni, budžetu, derīguma termiņu un ārkārtas kontaktpersonu.
• Pārvietojiet nodrošinātāja atslēgas uz ierobežotu aizmugursistēmu, vārteju vai slepeni pārvaldītu pakalpojumu.
• Izdodiet pārvaldītās atslēgas komandām, lietojumprogrammām, vidēm, CI darbiem un partneriem.
• Lietojiet vismazāko privilēģiju maršrutēšanu: atļautos modeļus, galapunktus, pilnvaru ierobežojumus, ātruma ierobežojumus un budžeta ierobežojumus.
• Atsevišķa ražošana, iestudēšana, izstrāde, CI un partneru piekļuve.
• Pieprasīt pakalpojuma konta īpašumtiesības, lai veiktu darba slodzi no vienas iekārtas uz otru.
• Tveriet atslēgas līmeņa lietojuma telemetriju un normalizējiet to starp pakalpojumu sniedzējiem.
• Iestatiet brīdinājumus par novirzēm par tēriņiem, neaktīvo taustiņu darbību, jauna modeļa izmantošanu un neparastiem tīkla avotiem.
• Centrāli ieviesiet pārklājošu taustiņu rotāciju un ierakstu pabeigšanu.
• Rakstiet un pārbaudiet noplūžu atbildes rokasgrāmatu.
• Pēc noklusējuma izmantojiet tikai metadatu reģistrēšanu, ja vien satura reģistrēšana nav skaidri apstiprināta.
• Atkārtoti pārskatiet neaktīvas, bezsaimnieka, pārmērīgi atļautās atslēgas un atslēgas, kurām tuvojas derīguma termiņš.

Lietojams secinājums

LLM API galvenās pārvaldības mērķis nav palēnināt komandu darbību. Tas ir paredzēts, lai padarītu drošu piekļuvi vieglu un nedrošu piekļuvi nevajadzīgu. Koplietotās pakalpojumu sniedzēja atslēgas rada neskaidras īpašumtiesības, nekontrolētu sprādziena rādiusu un lēnu reaģēšanu uz incidentiem. Pārvaldītās atslēgas veido pārvaldāmu dzīves ciklu: pieprasiet, apstipriniet, izdodiet, tvēriet, pārraugiet, pagrieziet un atsauciet.

Sāciet ar visaugstākā riska jomu: ražošanu un piekļuvi partneriem. Novietojiet nodrošinātāja atslēgas aiz kontrolēta slāņa, izsniedziet aptvertus iekšējos akreditācijas datus, pievienojiet īpašumtiesību metadatus un pārraugiet tēriņus un lietojumu pēc atslēgas. Kad šis pamats ir izveidots, izvērsiet to pašu modeli izstrādei, CI, novērtēšanas konveijeriem un pagaidu eksperimentiem.

Labākā pārvaldības sistēma ir tāda, ko izstrādātāji var izmantot: ātri pieprasāma, skaidra politikā, pēc noklusējuma novērojama un droši atsaukta, ja kaut kas noiet greizi.

Saistīta informācija

• costper-ledger/ulteama