Ključi API-ja umetne inteligence, ki zajemajo stranke: izolirajte najemnike, proračune in zlorabe brez širjenja ključev ponudnika

Ko izdelek številnim strankam omogoča klicanje modelov AI, je napačen primitiv pogosto ključ ponudnika navzgor. Ključ ponudnika običajno predstavlja račun, projekt, delovni prostor ali račun storitve. Vaš izdelek potrebuje nekaj ožjega: ključ, usmerjen v stranko, ki identificira enega najemnika, stranko, aplikacijo, okolje, politiko modela, proračun in revizijsko pravilo.

To je namen ključev AI API z obsegom stranke. Prehod izda ključ, overi zahteve, uporabi pravilnik, meri uporabo in nato pokliče ponudnike navzgor z uporabo skritih poverilnic. Stranke na nižji stopnji nikoli ne prejmejo ključa ponudnika. Z vašo platformo prejmejo stabilno pogodbo.

Težava z bralcem: izolacija strank brez enega ponudnikovega projekta na stranko

Izdelovalci SaaS, agencije in platforme preprodajalcev morajo običajno odgovoriti na praktična vprašanja, preden lahko razkrijejo dostop do umetne inteligence:

• Katera stranka je povzročila to uporabo?
• Katera aplikacija, okolje ali integracija je opravila klic?
• Kateri modeli in modalitete so dovoljeni?
• Koliko lahko ta stranka porabi ta mesec?
• Kaj se zgodi, če ključ pušča?
• Ali je mogoče to stranko začasno onemogočiti, ne da bi to vplivalo na vse ostale?
• Ali je mogoče uporabo pozneje uskladiti s poročili ponudnika?

Projekti in delovni prostori na strani ponudnika so lahko v pomoč, vendar niso vedno prava enota za vsako nadaljnjo stranko. Ustvarjanje ene meje navzgor na stranko lahko izboljša trdo izolacijo in poročanje, vendar ustvarja tudi dodatne stroške zagotavljanja, razdrobljenost kvot, širjenje poverilnic in več usklajevanja.

Ključ, ki ga je izdal prehod, daje izdelku kontrolno točko na ravni stranke, tudi če so zbrane poverilnice navzgor. Podpira tudi močnejše načine, kot so poverilnice ponudnika, vezanega na najemnika, ali prinesi svoj ključ, ko stranka potrebuje ločitev po pogodbi, meje prebivališča ali neposredno lastništvo računa ponudnika.

Dejstva, priporočila in napovedi

Dejstva

• Člani za podporo projektov OpenAI, storitveni računi, ključi API-ja, omejitve uporabe, proračuni in omejeni projektni viri. Zaradi tega so projekti uporabni kot meje navzgor, vendar niso samodejno pravi primitivi za vsakega končnega kupca.
• Poročanje o uporabi OpenAI lahko združuje uporabo po dimenzijah, kot so projekt, uporabnik, ključ API-ja, model, serija in raven storitve. Povratna bremenitev SaaS še vedno potrebuje te zapise ponudnika, povezane z identifikatorji strank v lasti izdelka.
• Antropični delovni prostori ločujejo vire API glede na primer uporabe, skupino, oddelek, projekt ali izdelek. Ključi API-ja so vezani na delovni prostor, kjer so ustvarjeni, in jih ni mogoče premikati med delovnimi prostori.
• Poročanje o antropični uporabi in stroških podpira združevanje po ključu API-ja, delovnem prostoru, modelu, ravni storitve, kontekstualnem oknu, rezidenčnosti podatkov in možnostih, povezanih s hitrostjo, s stroški vrnjenimi v dnevnih vedrih USD.
• Navodila za ključe Google Gemini API priporočajo omejevanje ključev, ključi API Gemini pa so privzeto omejeni na Generative Language API. Omejitve aplikacij, kot so naslovi IP, so lahko na voljo glede na obliko uvedbe.
• Navodila OWASP obravnavajo ključe API kot potrebne kontrole za zaščitene končne točke in pravijo, da je treba ključe preklicati, ko odjemalci kršijo pogodbe o uporabi.
• Navodila za skrivnosti OWASP poudarjajo najmanjše privilegije, preklic, ko skrivnosti niso več potrebne ali so ogrožene, in samodejno rotacijo za zmanjšanje napak pri izvajanju.

Priporočila

• Uporabite ključe strank, ki jih je izdal prehod, kot ročico pravilnika, ne le žetonov za preverjanje pristnosti.
• Poverilnice zgornjega ponudnika naj bodo skrite pred nadaljnjimi strankami.
• Napišite knjigo uporabe prehoda na zahtevo, preden se zanesete na nadzorne plošče ponudnika.
• Uporabljajte ponudnikove projekte ali delovne prostore selektivno za visoko tvegane, velike količine, regulirane stranke, občutljive na prebivališče ali pogodbeno ločene stranke.
• Zgradite rotacijo ključev kot potek dela s prekrivanjem, ne kot takojšen dogodek zloma.

Napovedi

• Več ponudnikov bo razkrilo bogatejše skupine uporabe in nadzor proračuna, vendar bo dodeljevanje strank v lasti izdelka še vedno potrebno za zaračunavanje SaaS in poročanje preprodajalcem.
• Platforme preprodajalcev in agencij bodo vse bolj obravnavale ključe prehodov kot komercialne predmete: povezane z načrti, dobroimetji, obsegi in podpornimi poteki dela.
• Stranke s strogimi potrebami po skladnosti ali nabavi bodo zahtevale BYOK ali lastništvo računa ponudnika, medtem ko bo večina običajnih strank raje imela pogodbo o upravljanem prehodu.

Ključni objekt prehoda

Ključ v obsegu stranke bi se moral razrešiti v objekt strukturiranega pravilnika. Vsaj modelirajte ključ kot več kot zgoščeno vrednost in ime.

{
  "key_id": "ključ_01J9 ...",
  "tenant_id": "najemnik_acme",
  "customer_id": "cust_4812","application_id": "app_support_bot",
  "okolje": "proizvodnja",
  "lastnik": {
    "type": "service_account",
    "id": "svc_support_ai"
  },
  "model_profile_id": "standardna_podpora_profila",
  "allowed_modalities": ["text", "image_input"],
  "tool_policy_id": "tools_readonly_kb",
  "mesečni_proračun": {
    "valuta": "USD",
    "znesek": "500,00"
  },
  "hitrost_limits": {
    "zahteve_na_minuto": 120,
    "input_tokens_per_minute": 250000,
    "output_tokens_per_minute": 80000
  },
  "retention_policy": "samo metapodatki",
  "status": "aktiven",
  "created_at": "2026-09-05T10:00:00Z",
  "last_used_at": nič
}

Natančna polja se bodo razlikovala, vendar načelo ne bi smelo: vsaka dohodna zahteva razreši ključ v pravilnik najemnika pred pošiljanjem. Preverjanje pristnosti odgovori "kdo kliče?" Rešitev pravilnika odgovarja, "kaj lahko ta klicatelj stori, koliko lahko porabi, kam lahko usmeri zahtevo in kaj mora biti zabeleženo?"

Tukaj je pomembna tudi strategija semantičnega izdelka. Platforma, ki prodaja API AI za agencije, bo morda potrebovala razsežnosti strank in oglaševalskih akcij. Orodje za razvijalce bo morda potrebovalo dimenzije delovnega prostora in skladišča. Prodajalec morda potrebuje zunanje ID-je strank, ki se ujemajo z njegovim sistemom zaračunavanja.

Potek dela za ustvarjanje ključev

Ustvarjanje ključa mora biti dovolj deterministično za avtomatizacijo in dovolj strogo za varnostni pregled.

1. Najprej ustvarite zapis o stranki

Ne ustvarjajte osirotelih ključev. Ključ bi moral pripadati najemniku in evidenci strank, preden obstaja. Za platforme prodajnih posrednikov mora evidenca strank vključevati zunanje ID-je iz prodajalčevega CRM-ja ali sistema zaračunavanja, metapodatke o načrtu, razvrščanje davkov ali računov, če je potrebno, in polje stanja, ki lahko začasno prekine vse podrejene ključe.

2. Pripni profil modela

Profil modela preslika imena modelov, namenjenih strankam, v modele in zmogljivosti ponudnika. Na primer, support-standard morda omogoča uravnotežen besedilni model, vnos slike in brez izvajanja kode. research-premium morda omogoča modele z dolgim kontekstom, spletno iskanje in višje zgornje meje na zahtevo.

Ne vsiljujte nadaljnjim aplikacijam ID-jev modela ponudnika trde kode. Uporabite profil prehoda za upravljanje razpoložljivosti, nadomestne možnosti, cen in zastaranja.

3. Nastavite omejitve porabe in stopnje

Uporabite proračune in omejitve stopenj skupaj. Mesečni proračun sčasoma prepreči škodo na računih. Omejitve stopnje preprečujejo, da bi nenadne zlorabe, ponovne nevihte ali nenamerne zanke v nekaj minutah porabile celoten proračun.

Uporabni kontrolniki vključujejo:

• Mesečni proračun stranke.
• Dnevna mehka omejitev za odkrivanje nepravilnosti.
• Stopnja zahtev na ključ.
• Vhodna in izhodna stopnja žetona.
• Najvišji ocenjeni strošek na zahtevo.
• Omejitve, specifične za orodje za gostujoče iskanje, obdelavo datotek ali izvajanje kode.

Izvrševanje proračuna mora rezervirati ocenjene stroške pred odpremo, poravnati dejanske stroške po zaključku in sprostiti neporabljeno rezervo. To poveže ključno politiko z zaračunavanjem API-ja AI namesto da bi zaračunavanje obravnavalo kot opravilo poročanja z zakasnitvijo.

4. Pravilno ustvarite in shranite skrivnost

Enkrat prikaži skrivnost navadnega besedila. Shranjujte samo močno zgoščeno vrednost in kratko predpono ali prstni odtis za iskanje podpore. Predpona pomaga ekipam za podporo prepoznati »ključ, ki se konča na 8F2A«, ne da bi videla skrivnost.

Tipični vzorec shranjevanja je:

• key_id: stabilen identifikator baze podatkov.
• secret_hash: zgoščevanje celotne skrivnosti z uporabo ustrezne strategije zgoščevanja gesla ali žetona.
• secret_prefix: kratka neobčutljiva predpona za prikaz.
• prstni odtis: deterministični identifikator za revizijsko iskanje.
• created_by: uporabniški ali partnerski API odjemalec, ki je ustvaril ključ.
• stanje: aktivno, izčrpava, preklicano, v karanteni, poteklo.

Ključev višjega ponudnika nikoli ne shranjujte v objekt ključa stranke. Poverilnice ponudnika spadajo v ločen trezor poverilnic z lastnimi pravili dostopa.

Uveljavljanje v času zahteve

Prehod mora vsak modelni klic obravnavati kot odločitev politike, ki ji sledi odpošiljanje ponudnika. Praktična pot zahteve je videti takole:

1. Razčlenite predstavljeni ključ prehoda.
2. Poiščite zgoščeno vrednost ključa in stanje.
3. Razrešite profil najemnika, stranke, aplikacije, okolja, lastnika in modela.
4. Preverite, ali sta najemnik in stranka aktivna.
5. Potrdite vzdevek zahtevanega modela, način, orodja, način hrambe, regijo in raven storitve.
6. Ocenite stroške zahteve in rezervirajte proračun.
7. Preverite omejitve stopnje in pragove zlorabe.
8. Izberite način poverilnice navzgor: združeno, vezano na najemnika ali BYOK.
9. Pošiljanje ponudniku.
10. Zajemite uporabo, stroške, reference ponudnikov, napake in varnostne signale.
11. Poravnajte proračunsko rezervacijo in napišite končni dogodek v knjigi.

To zaporedje ohranja odgovornost prehoda za pogodbo s stranko. Nadzorne plošče ponudnika postanejo vložki za usklajevanje, ne edini vir resnice.

Uporaba polj glavne knjige, ki kasneje dejansko pomagajo

Knjiga prehoda mora ohraniti dovolj podrobnosti za odgovore na vprašanja o podpori, zaračunavanju, zlorabi in usmerjanju, ne da bi privzeto zahtevala neobdelano hitro shranjevanje.

Uporabna polja vključujejo:

• request_id in trace_id.
• tenant_id, customer_id, application_id in key_id.
• Identifikator končnega uporabnika, po možnosti psevdonim, kjer je to primerno.
• Vzdevek modela, ki ga zahteva stranka.
• Razrešen ponudnik in model navzgor.
• Vnos, izhod, sklepanje, predpomnjeno shranjevanje, zvok, slika, video in uporaba orodja, kjer je primerno.
• Navedeni stroški, rezervirani znesek, poravnani stroški, valuta in različica kataloga s cenami.
• ID zahteve ponudnika, sklic na poročilo o uporabi, projekt, delovni prostor ali dimenzija združevanja ključev API, če je na voljo.
• Uporabljen je pravilnik o hrambi.
• Varnost, zloraba ali kode odločitev o politiki.
• Kategorija napake in metapodatki o ponovnem poskusu.

Ta struktura podpira povratne bremenitve, podporo strankam, odziv na incidente in potek dela za upravljanje ključev API-ja, ki lahko odgovori, "kaj je naredil ta ključ?" brez izpostavljanja nepovezanih najemnikov.

Načini poverilnic: združeni, vezani na najemnika in BYOK

Združene poverilnice ponudnika

V privzetem načinu veliko ključev strank poteka skozi manjši nabor poverilnic ponudnika. To je operativno preprosto in zmanjšuje širjenje na strani ponudnika. Deluje, če ima prehod močno dodeljevanje najemnikov, izvrševanje proračuna, omejevanje stopnje, izolacijo zlorab in nadzor meja predpomnilnika.

Kompromis je v tem, da lahko poročanje na strani ponudnika prikaže le poverilnico prehoda ali projekt ponudnika. Zapise ponudnika morate pridružiti zapisom glavne knjige prehoda, da ustvarite obračunavanje in analitiko na ravni stranke.

Poverilnice ponudnika, vezanega na najemnika

Pri večjih ali bolj tveganih najemnikih najemnika povežite z namenskim ponudnikovim projektom, delovnim prostorom, računom storitve ali ključem. To omogoča močnejše ločevanje navzgor in lahko poenostavi poročanje na strani ponudnika. Zagotovi lahko tudi varovalni mehanizem trde kvote, če ponudnik podpira omejitve na tej meji.

Cena je operativna zapletenost. Oskrbovanje, rotacija, omejitve ponudnika, odziv na incidente in usklajevanje se zdaj dogajajo v več objektih navzgor.

Prinesite svoj ključ

BYOK je lahko koristen, ko morajo stranke imeti račun ponudnika, se pogajati o lastni pogodbi s ponudnikom ali voditi ločeno zaračunavanje ponudniku. Prehod še vedno uporablja profile modelov, politiko usmerjanja, analitiko in kontrole na ravni aplikacije, kjer je to mogoče.

Kompromis je zapletenost podpore. Račun ponudnika vsakega kupca ima lahko drugačen model dostopa, kvote, cene, nastavitve hrambe in status incidenta. Prehod mora te razlike jasno zaznati in pojasniti.

Preklic in karantena

Preklic bi moral takoj blokirati nove zahteve za ključ stranke, ne da bi zamenjal nepovezane poverilnice ponudnika navzgor. To je ena glavnih prednosti virtualnih ključev.

Uporabite ločena stanja za različna operativna dejanja:

• aktivno: zahteve so dovoljene.
• izčrpavanje: stari ključ je sprejet med oknom rotacije, vendar se oddajo opozorila in revizijski dogodki.
• preklicano: nove zahteve so trajno zavrnjene.
• v karanteni: nove zahteve so blokirane zaradi zlorabe, plačila, pravilnika ali odziva na incident.
• potekel: ključ je potekel svojo življenjsko dobo in ga je treba zamenjati.

Karantena bi morala biti razveljavljena, ko je incident odpravljen. Preklic običajno ne bi smel biti reverzibilen, ker obnavljanje starih skrivnosti poveča zmedo in tveganje.

Ko ključ krši pravilnik uporabe, zabeležite razlog, akterja, čas in obseg uveljavljanja. Če je bila odločitev avtomatizirana, ohranite različico pravila in signale, ki so jo sprožili. Tako so pogovori strank dejanski.

Rotacija brez prekinitve proizvodnje

Rotacija tipk mora uporabljati potek dela s prekrivanjem dveh tipk:

1. Ustvarite nadomestni ključ z isto stranko, aplikacijo, profilom modela in omejitvami, razen če jih operater namerno spremeni.
2. Enkrat prikaži novo skrivnost.
3. Označite stari ključ kot praznitev.
4. Sprejmite oba ključa za omejeno obdobje, na primer 7, 14 ali 30 dni, odvisno od načrta stranke in tveganja.
5. Oddajanje opozoril o uporabi na tipki za izčrpavanje.
6. Obvestite lastnika ali odjemalca API-ja partnerja, ko se stari ključ še vedno uporablja blizu roka.
7. Prekličite stari ključ na koncu okna.
8. Ohranite dodelitev za oba ključna ID-ja pri isti stranki in aplikaciji.

S tem se izognete običajnemu načinu napake, kjer izboljšanje varnosti postane izpad proizvodnje. Kroženje je še vedno nadzor, vendar postane operativni potek dela z dokazi in roki.

Partner API Surface

Če platforme na nižji stopnji upravljajo stranke programsko, izpostavite ključne operacije prek partnerskega API-ja. API bi moral podpirati ključe idempotence in revizijske dogodke, ker se oskrba pogosto zgodi znotraj delovnih tokov zaračunavanja, vkrcanja ali CRM.

Najmanjše število končnih točk:

• POST /customers: ustvarite ali postavite stranko.
• POST /customers/{customer_id}/keys: ustvarite ključ.
• GET /customers/{customer_id}/keys: seznam ključev in stanj.
• POPRAVEK /keys/{key_id}: posodobite obsege, lastnika, omejitve, profil modela ali status.
• POST /keys/{key_id}/rotate: ustvarite nadomestni ključ in označite stari ključ kot prazni.
• POST /keys/{key_id}/revoke: takoj prekliči.
• GET /customers/{customer_id}/usage: vrnite uporabo in ceno glede na časovno obdobje, ključ, aplikacijo, model ali dimenzijo končnega uporabnika.

Vsaka zahteva za mutacijo mora sprejeti ključ idempotence. Vsaka sprememba bi morala napisati revizijski dogodek z akterjem, ciljem, polji pred in po, izvornim IP-jem ali identiteto odjemalca in razlogom, kjer je na voljo.

Kdaj uporabiti projekte ali delovne prostore ponudnika

Ključev prehoda in meja ponudnika ne obravnavajte kot medsebojno izključujoče. Rešujejo različne probleme.

Uporabite prehodne ključe za običajni nadzor na ravni stranke:

• Dodeljevanje na stranko.
• Ključi za posamezne aplikacije.
• Omejitve proračuna in cene.
• Hitro vzmetenje.
• Rotacijski poteki dela.
• Analitika uporabe in poročanje prodajalcem.

Dodajte ponudnikove projekte, delovne prostore ali namenske ponudnikove poverilnice, ko stranka potrebuje močnejšo ločitev:

• Velika mesečna količina, ki si zasluži namenske kvote.
• Regulirane delovne obremenitve z izrecnimi zahtevami glede stalnega prebivališča ali hrambe.
• Pogodbeno ločevanje računov.
• Trdi zaščitni mehanizmi proračuna ali kvot na strani ponudnika.
• Posebno spremljanje zlorab ali meje varnostnega pregleda.
• Računi ponudnika v lasti stranke prek BYOK.

Praktično privzeto je izolacija, ki jo uveljavlja prehod, s selektivnimi trdimi mejami navzgor. To ohranja skupno pot preprosto, hkrati pa ohranja pot stopnjevanja za stranke, ki potrebujejo več ločevanja.

Kontrolni seznam za implementacijo

• Določite shemo ključev stranke z najemnikom, stranko, aplikacijo, okoljem, lastnikom, profilom modela, omejitvami, politiko hrambe in statusom.
• Zgosti skrivnosti v mirovanju in prikaži golo besedilo samo enkrat.
• Ločite ključe prehoda od shrambe poverilnic ponudnika navzgor.
• Vsako zahtevo pred pošiljanjem razrešite s pravilnikom.
• Rezervirajte proračun pred klicem ponudnika in poravnajte, ko je znana končna poraba.
• Zabeležite uporabo s stranko, ključem, vzdevkom modela, modelom navzgor, kategorijami žetonov, uporabo orodja, navedenimi stroški, poravnanimi stroški in referencami ponudnika.
• Implementirajte stanja aktivno, izpraznitev, preklicano, karantena in potečeno stanje.
• Podpora za prekrivanje vrtenja dveh tipk.
• Izpostavite operacije partnerskega API-ja s ključi idempotence.
• Uporabljajte ponudnikove projekte ali delovne prostore samo tam, kjer so njihovi operativni stroški upravičeni.

Ukrepljiv sklep

Izolacija strank za dostop z umetno inteligenco se mora običajno začeti pri ključu prehoda, ne pri ključu ponudnika. Ključ prehoda je pogodba, usmerjena v stranko: imenuje najemnika, stranko, aplikacijo, profil modela, proračun, omejitev stopnje, pravilo hrambe in politiko revizije. Ključ ponudnika je podrobnost izvedbe za to pogodbo.

Ta arhitektura omogoča izdelovalcem SaaS in platformam preprodajalcev hiter preklic, natančno dodeljevanje, proračune na stranko, nadzorovano rotacijo in uporabno analitiko uporabe, ne da bi privzeto ustvarili en projekt ponudnika navzgor za vsako stranko. Uporabite predhodne projekte, delovne prostore, poverilnice, vezane na najemnika, ali BYOK, kadar to zahteva tveganje, obseg, rezidenčnost ali pogodba. Za običajno pot uveljavite izolacijo strank v glavni knjigi prehoda in mehanizmu pravilnika, nato pa uskladite zapise ponudnika.

Sorodno branje

• oskrba idempotentnega API-ja za stranke za stranke, ključe in krediti