AI API ključevi s opsegom korisnika: izolirajte stanare, proračune i zloupotrebu bez širenja ključeva pružatelja usluga

Kada proizvod mnogim korisnicima omogućuje pozivanje modela umjetne inteligencije, pogrešna primitiva često je uzlazni ključ pružatelja usluga. Ključ pružatelja obično predstavlja račun, projekt, radni prostor ili račun usluge. Vašem proizvodu treba nešto uže: ključ okrenut prema korisniku koji identificira jednog stanara, kupca, aplikaciju, okruženje, politiku modela, proračun i pravilo revizije.

To je svrha AI API ključeva s opsegom korisnika. Gateway izdaje ključ, provjerava autentičnost zahtjeva, primjenjuje pravila, mjeri korištenje, a zatim poziva uzvodne pružatelje koristeći skrivene vjerodajnice. Daljnji korisnici nikada ne dobivaju ključ pružatelja usluga. Oni dobivaju stabilan ugovor s vašom platformom.

Problem s čitateljem: Izolacija korisnika bez jednog projekta pružatelja po korisniku

Sastavnici SaaS-a, agencije i prodavačke platforme obično moraju odgovoriti na praktična pitanja prije nego što mogu izložiti AI pristup nizvodno:

• Koji je korisnik generirao ovu upotrebu?
• Koja je aplikacija, okruženje ili integracija uputila poziv?
• Koji su modeli i modaliteti dopušteni?
• Koliko ovaj kupac može potrošiti ovaj mjesec?
• Što se događa ako ključ procuri?
• Može li se ovaj korisnik suspendirati bez utjecaja na sve ostale?
• Može li se korištenje kasnije uskladiti s izvješćima pružatelja?

Projekti i radni prostori na strani pružatelja mogu pomoći, ali nisu uvijek prava jedinica za svakog daljnjeg kupca. Stvaranje jedne uzvodne granice po korisniku može poboljšati čvrstu izolaciju i izvješćivanje, ali također stvara dodatne troškove za pružanje usluga, fragmentaciju kvota, širenje vjerodajnica i više rada na usklađivanju.

Ključ koji izdaje pristupnik daje proizvodu kontrolnu točku na razini korisnika čak i kada su uzvodne vjerodajnice skupljene. Također podržava snažnije načine, kao što su vjerodajnice pružatelja vezane uz stanara ili donesite vlastiti ključ, kada je korisniku potrebno ugovorno razdvajanje, ograničenja prebivališta ili izravno vlasništvo računa pružatelja.

Činjenice, preporuke i predviđanja

Činjenice

• OpenAI članovi podrške za projekte, servisni računi, API ključevi, ograničenja upotrebe, proračuni i ograničeni projektni resursi. To čini projekte korisnima kao uzvodne granice, ali ne i automatski pravom primitivom za svakog krajnjeg korisnika.
• OpenAI izvješćivanje o korištenju može grupirati korištenje prema dimenzijama kao što su projekt, korisnik, API ključ, model, serija i razina usluge. SaaS storniranje i dalje treba te zapise pružatelja pridružiti identifikatorima korisnika u vlasništvu proizvoda.
• Anthropic radni prostori odvajaju API resurse prema slučaju upotrebe, timu, odjelu, projektu ili proizvodu. API ključevi su vezani za radni prostor u kojem su stvoreni i ne mogu se premještati između radnih prostora.
• Anthropic izvješćivanje o korištenju i troškovima podržava grupiranje prema API ključu, radnom prostoru, modelu, razini usluge, kontekstualnom prozoru, prebivalištu podataka i opcijama vezanim uz brzinu, s troškovima koji se vraćaju u dnevnim USD segmentima.
• Google Gemini API smjernice za ključeve preporučuju ograničavanje ključeva, a Gemini API ključevi su prema zadanim postavkama ograničeni na generativni jezik API. Ograničenja aplikacije kao što su IP adrese mogu biti dostupna ovisno o obliku implementacije.
• OWASP smjernice tretiraju API ključeve kao potrebne kontrole za zaštićene krajnje točke i kažu da ključeve treba opozvati kada klijenti krše ugovore o korištenju.
• OWASP tajne smjernice naglašavaju najmanju privilegiju, opoziv kada tajne više nisu potrebne ili su ugrožene i automatiziranu rotaciju kako bi se smanjile pogreške u implementaciji.

Preporuke

• Koristite korisničke ključeve koje izdaje pristupnik kao pravila za rukovanje, a ne samo tokene za provjeru autentičnosti.
• Držite vjerodajnice uzvodnog pružatelja skrivene od daljnjih kupaca.
• Napišite knjigu korištenja pristupnika na zahtjev, prije oslanjanja na nadzorne ploče pružatelja usluga.
• Koristite projekte ili radne prostore pružatelja selektivno za visokorizične, velike količine, regulirane, osjetljive na prebivalište ili ugovorno odvojene korisnike.
• Izgradite rotaciju ključa kao radni tijek preklapanja, a ne kao trenutni događaj kvara.

Predviđanja

• Više pružatelja izložit će bogatije grupiranje upotrebe i kontrole proračuna, ali će atribucija korisnika u vlasništvu proizvoda i dalje biti potrebna za SaaS naplatu i izvješćivanje prodavača.
• Platforme prodavača i agencija sve će više tretirati ključeve pristupnika kao komercijalne objekte: vezane uz planove, kreditna stanja, opsege i tijekove rada podrške.
• Klijenti sa striktnom usklađenošću ili potrebama nabave tražit će BYOK ili vlasništvo nad računom davatelja usluga, dok će većina običnih kupaca preferirati ugovor o upravljanom pristupniku.

Ključni objekt pristupnika

Ključ s opsegom korisnika trebao bi se razlučiti u strukturirani objekt pravila. Minimalno, modelirajte ključ kao nešto više od hasha i imena.

{
  "key_id": "key_01J9...",
  "tenant_id": "tenant_acme",
  "customer_id": "cust_4812",
  "application_id": "app_support_bot",
  "environment": "production",
  "owner": {
    "type": "service_account",
    "id": "svc_support_ai"
  },
  "model_profile_id": "profile_support_standard",
  "allowed_modalities": ["text", "image_input"],
  "tool_policy_id": "tools_readonly_kb",
  "monthly_budget": {
    "currency": "USD",
    "amount": "500.00"
  },
  "rate_limits": {
    "requests_per_minute": 120,
    "input_tokens_per_minute": 250000,
    "output_tokens_per_minute": 80000
  },
  "retention_policy": "metadata_only",
  "status": "active",
  "created_at": "2026-09-05T10:00:00Z",
  "last_used_at": null
}

Točna polja će varirati, ali načelo ne bi trebalo: svaki dolazni zahtjev razrješava ključ u politici stanara prije slanja. Autentifikacija odgovara "tko zove?" Rješenje pravila odgovara "što ovaj pozivatelj može učiniti, koliko može potrošiti, kamo može usmjeriti zahtjev i što se mora zabilježiti?"

Ovdje je također važna strategija semantičkog proizvoda. Platforma koja prodaje AI API za agencije može trebati dimenzije korisnika i kampanje. Alat za razvojne programere možda će trebati dimenzije radnog prostora i spremišta. Prodavač može trebati vanjske korisničke ID-ove koji odgovaraju njegovom sustavu naplate.

Tijek rada za izradu ključa

Stvaranje ključa mora biti dovoljno determinističko za automatizaciju i dovoljno strogo za sigurnosni pregled.

1. Prvo izradite evidenciju korisnika

Ne stvarajte ključeve siroče. Ključ bi trebao pripadati najmoprimcu i evidenciji kupaca prije nego što postoji. Za platforme preprodavača, evidencija korisnika treba uključivati vanjske ID-ove iz preprodavačevog CRM-a ili sustava naplate, metapodatke plana, grupiranje poreza ili faktura ako je potrebno i polje statusa koje može suspendirati sve podređene ključeve.

2. Priložite profil modela

Profil modela preslikava nazive modela usmjerenih prema korisnicima na modele i mogućnosti pružatelja usluga. Na primjer, support-standard može dopustiti uravnotežen tekstualni model, unos slike i bez izvršavanja koda. research-premium može omogućiti modele dugog konteksta, pretraživanje weba i više gornje granice po zahtjevu.

Nemojte prisiljavati nizvodne aplikacije na ID-jeve modela pružatelja tvrdog koda. Upotrijebite profil pristupnika za upravljanje dostupnošću, zamjenama, cijenama i obustavom.

3. Postavite ograničenja potrošnje i stope

Koristite proračune i ograničenja stopa zajedno. Mjesečni proračun sprječava oštećenje faktura tijekom vremena. Ograničenja stope sprječavaju iznenadnu zloupotrebu, ponovne oluje ili slučajne petlje da potroše cijeli proračun u nekoliko minuta.

Korisne kontrole uključuju:

• Mjesečni korisnički proračun.
• Dnevno meko ograničenje za otkrivanje anomalija.
• Stopa zahtjeva po ključu.
• Ulazna i izlazna stopa tokena.
• Maksimalni procijenjeni trošak po zahtjevu.
• Ograničenja specifična za alat za hostirano pretraživanje, obradu datoteka ili izvršavanje koda.

Izvršenje proračuna treba rezervirati procijenjeni trošak prije otpreme, podmiriti stvarni trošak nakon završetka i osloboditi neiskorištenu rezervu. Ovo povezuje pravilo ključa s AI API naplatom umjesto da naplatu tretira kao zadatak odgođenog izvješćivanja.

4. Ispravno generirajte i pohranite tajnu

Prikaži tajnu otvorenog teksta jednom. Pohranite samo jaki hash, plus kratki prefiks ili otisak prsta za traženje podrške. Prefiks pomaže timovima za podršku da prepoznaju "ključ koji završava na 8F2A" bez da vide tajnu.

Tipični uzorak pohrane je:

• key_id: identifikator stabilne baze podataka.
• secret_hash: raspršivanje cijele tajne pomoću odgovarajuće strategije raspršivanja lozinke ili tokena.
• secret_prefix: kratki neosjetljivi prefiks prikaza.
• fingerprint: deterministički identifikator za revizijsko pretraživanje.
• created_by: korisnik ili partner API klijent koji je stvorio ključ.
• status: aktivno, iscrpljuje se, opozvano, u karanteni, isteklo.

Nikada ne pohranjujte ključeve uzvodnog pružatelja usluga na objekt ključa korisnika. Vjerodajnice pružatelja usluga pripadaju zasebnom trezoru vjerodajnica s vlastitim pravilima pristupa.

Provedba vremena zahtjeva

Gateway bi svaki model poziva trebao tretirati kao odluku o politici nakon koje slijedi slanje davatelja. Praktični put zahtjeva izgleda ovako:

1. Raščlanite prikazani ključ pristupnika.
2. Potražite hash ključ i status.
3. Rješavanje profila zakupca, korisnika, aplikacije, okruženja, vlasnika i modela.
4. Provjerite jesu li stanar i korisnik aktivni.
5. Potvrdite traženi alias modela, modalitet, alate, način zadržavanja, regiju i razinu usluge.
6. Procijenite troškove zahtjeva i rezervni proračun.
7. Provjerite ograničenja stope i pragove zlouporabe.
8. Odaberite uzvodni način vjerodajnice: skupni, vezan za stanara ili BYOK.
9. Slanje davatelju.
10. Snimite upotrebu, cijenu, reference pružatelja usluga, pogreške i sigurnosne signale.
11. Podmirite proračunsku rezervaciju i zapišite konačni događaj u glavnoj knjizi.

Ovaj slijed drži pristupnik odgovornim za korisnički ugovor. Nadzorne ploče pružatelja usluga postaju unosi za usklađivanje, a ne jedini izvor istine.

Polja knjige korištenja koja kasnije stvarno pomažu

Knjižna knjiga pristupnika trebala bi sačuvati dovoljno detalja za odgovore na pitanja o podršci, naplati, zloupotrebi i usmjeravanju bez potrebe za neobrađenom brzom pohranom prema zadanim postavkama.

Korisna polja uključuju:

• request_id i trace_id.
• tenant_id, customer_id, application_id i key_id.
• Identifikator krajnjeg korisnika, po mogućnosti pseudonim gdje je to prikladno.
• Nadimak modela na zahtjev kupca.
• Riješen uzlazni pružatelj i model.
• Unos, izlaz, obrazloženje, predmemorirano, audio, slika, video i upotreba alata gdje je primjenjivo.
• Navedeni trošak, rezervirani iznos, podmireni trošak, valuta i verzija kataloga s cijenama.
• ID zahtjeva pružatelja, referenca izvješća o korištenju, projekt, radni prostor ili API dimenzija grupiranja ključeva ako je dostupna.
• Primijenjeno pravilo zadržavanja.
• Sigurnosni kodovi, zlouporaba ili pravila odlučivanja.
• Kategorija pogreške i metapodaci za ponovni pokušaj.

Ova struktura podržava storniranje, korisničku podršku, odgovor na incidente i API upravljanje ključem tijek rada koji može odgovoriti "što je ovaj ključ učinio?" bez izlaganja nepovezanih stanara.

Načini vjerodajnica: skupni, vezani uz stanara i BYOK

Skupljene vjerodajnice davatelja

U zadanom načinu rada mnogi korisnički ključevi prolaze kroz manji skup vjerodajnica pružatelja usluga. Ovo je operativno jednostavno i smanjuje širenje na strani pružatelja usluga. Radi kada pristupnik ima jaku atribuciju zakupca, provedbu proračuna, ograničenje stope, izolaciju zlouporabe i kontrolu granica predmemorije.

Razvoj je u tome što izvješćivanje na strani pružatelja može prikazivati samo vjerodajnicu pristupnika ili projekt pružatelja. Morate pridružiti zapise pružatelja natrag zapisima glavne knjige pristupnika kako biste proizveli naplatu i analitiku na razini korisnika.

Vjerodajnice davatelja vezane uz stanara

Za veće ili rizičnije stanare, povežite stanara s namjenskim projektom pružatelja, radnim prostorom, računom usluge ili ključem. To daje jače odvajanje uzvodno i može pojednostaviti izvješćivanje na strani pružatelja usluga. Također može pružiti čvrstu zaštitu kvote ako pružatelj podržava ograničenja na toj granici.

Cijena je operativna složenost. Pružanje, rotacija, ograničenja pružatelja, odgovor na incidente i usklađivanje sada se odvijaju preko više uzvodnih objekata.

Donesite vlastiti ključ

BYOK može biti koristan kada korisnici moraju posjedovati račun pružatelja, pregovarati o vlastitom ugovoru s pružateljem ili držati naplatu od pružatelja odvojenom. Gateway i dalje primjenjuje profile modela, politiku usmjeravanja, analitiku i kontrole na razini aplikacije gdje je to moguće.

Kompromis je složenost podrške. Račun pružatelja usluga svakog korisnika može imati drugačiji model pristupa, kvote, cijene, postavke zadržavanja i status incidenta. Gateway mora jasno otkriti i objasniti ove razlike.

Opoziv i karantena

Opoziv bi trebao odmah blokirati nove zahtjeve za korisnički ključ bez rotiranja nepovezanih vjerodajnica uzvodnog pružatelja usluga. Ovo je jedna od glavnih prednosti virtualnih ključeva.

Koristite odvojena stanja za različite operativne radnje:

• active: zahtjevi su dopušteni.
• draining: stari ključ se prihvaća tijekom prozora rotacije, ali se emitiraju upozorenja i revizijski događaji.
• revoked: novi zahtjevi se trajno odbijaju.
• quarantined: novi zahtjevi su blokirani zbog zloupotrebe, plaćanja, pravila ili odgovora na incident.
• expired: ključ je istekao vijek trajanja i mora se zamijeniti.

Karantena bi trebala biti poništena kada se incident riješi. Opoziv obično ne bi trebao biti poništen, jer vraćanje starih tajni povećava zabunu i rizik.

Kada ključ prekrši pravila korištenja, zabilježite razlog, aktera, vrijeme i opseg provedbe. Ako je odluka bila automatizirana, sačuvajte verziju pravila i signale koji su je pokrenuli. Ovo održava razgovore kupaca činjeničnim.

Rotacija bez prekida proizvodnje

Rotacija tipki treba koristiti tijek rada s preklapanjem dvije tipke:

1. Stvorite zamjenski ključ s istim kupcem, aplikacijom, profilom modela i ograničenjima osim ako ih operater namjerno ne promijeni.
2. Prikaži novu tajnu jednom.
3. Označi stari ključ kao draining.
4. Prihvatite oba ključa na određeno razdoblje, kao što je 7, 14 ili 30 dana, ovisno o korisničkom planu i riziku.
5. Emitiraj upozorenja o korištenju na ključu za pražnjenje.
6. Obavijestite vlasnika ili partnera API klijenta kada se stari ključ još uvijek koristi blizu roka.
7. Opozovite stari ključ na kraju prozora.
8. Zadržite atribuciju za oba ključna ID-a pod istim korisnikom i aplikacijom.

Time se izbjegava uobičajeni način kvara gdje sigurnosno poboljšanje postaje prekid proizvodnje. Rotacija je i dalje kontrola, ali postaje operativni tijek rada s dokazima i rokovima.

Partner API Površina

Ako nizvodne platforme upravljaju klijentima programski, izložite ključne operacije putem partnera API. API bi trebao podržavati ključeve idempotencije i revizijske događaje jer se dodjela često događa unutar radnih procesa naplate, uključivanja ili CRM-a.

Minimalne krajnje točke:

• POST /customers: kreirajte ili postavite kupca.
• POST /customers/{customer_id}/keys: izradite ključ.
• GET /customers/{customer_id}/keys: popis ključeva i statusa.
• PATCH /keys/{key_id}: ažurirajte opsege, vlasnika, ograničenja, profil modela ili status.
• POST /keys/{key_id}/rotate: kreirajte zamjenu i označite stari ključ kao prazni.
• POST /keys/{key_id}/revoke: opozovi odmah.
• GET /customers/{customer_id}/usage: povrat upotrebe i cijene prema vremenskom rasponu, ključu, aplikaciji, modelu ili dimenziji krajnjeg korisnika.

Svaki zahtjev za mutaciju treba prihvatiti ključ idempotencije. Svaka bi promjena trebala napisati revizijski događaj s akterom, ciljem, poljima prije i poslije, izvornim IP-om ili identitetom klijenta i razlogom gdje je to moguće.

Kada koristiti projekte ili radne prostore pružatelja usluga

Ključeve pristupnika i granice pružatelja nemojte smatrati međusobno isključivim. Rješavaju različite probleme.

Koristite ključeve pristupnika za normalnu kontrolu na razini korisnika:

• Atribucija po korisniku.
• Ključevi po aplikaciji.
• Ograničenja proračuna i stope.
• Brzo obustavljanje.
• Tijekovi rada rotacije.
• Analitika korištenja i izvješća prodavača.

Dodajte projekte pružatelja, radne prostore ili namjenske vjerodajnice pružatelja usluga kada je korisniku potrebno jače odvajanje:

• Velika mjesečna količina koja zaslužuje namjenske kvote.
• Regulirana radna opterećenja s izričitim zahtjevima boravka ili zadržavanja.
• Ugovorno odvajanje faktura.
• Tvrdi proračun ili kvota za zaštitu od strane pružatelja usluga.
• Namjensko praćenje zlostavljanja ili granice sigurnosnog pregleda.
• Računi pružatelja usluga u vlasništvu korisnika putem BYOK-a.

Praktični standard je izolacija koju provodi pristupnik sa selektivnim uzvodnim čvrstim granicama. To održava uobičajeni put jednostavnim, a istovremeno zadržava put eskalacije za klijente kojima je potrebno više odvajanja.

Kontrolni popis za implementaciju

• Definirajte shemu korisničkog ključa sa stanarom, korisnikom, aplikacijom, okruženjem, vlasnikom, profilom modela, ograničenjima, politikom zadržavanja i statusom.
• Hash tajne u mirovanju i prikaži otvoreni tekst samo jednom.
• Odvojite ključeve pristupnika od pohrane vjerodajnica uzlaznog davatelja.
• Svaki zahtjev razriješite u pravila prije slanja.
• Rezervirajte proračun prije poziva davatelja usluga i podmirite nakon što je poznata konačna potrošnja.
• Bilježite korištenje s korisnikom, ključem, aliasom modela, uzvodnim modelom, kategorijama tokena, upotrebom alata, navedenim troškom, podmirenim troškom i referencama pružatelja usluga.
• Implementirajte aktivna, iscrpljujuća, opozvana, karantena i istekla stanja.
• Podržava preklapanje rotacije s dvije tipke.
• Expose Partner API operacije s ključevima idempotencije.
• Koristite projekte ili radne prostore pružatelja samo tamo gdje je njihov operativni trošak opravdan.

Zaključak koji se može poduzeti

Izolacija korisnika za AI pristup obično bi trebala započeti na ključu pristupnika, a ne na ključu pružatelja usluga. Ključ pristupnika je ugovor okrenut prema korisniku: imenuje zakupca, kupca, aplikaciju, profil modela, proračun, ograničenje stope, pravilo zadržavanja i politiku revizije. Ključ pružatelja usluga je detalj implementacije koji stoji iza tog ugovora.

Ova arhitektura pruža SaaS graditeljima i platformama preprodavača brz opoziv, točnu atribuciju, proračune po klijentima, kontroliranu rotaciju i korisnu analitiku upotrebe bez stvaranja jednog projekta uzvodnog pružatelja za svakog korisnika prema zadanim postavkama. Koristite uzvodne projekte, radne prostore, vjerodajnice vezane za stanara ili BYOK kada to zahtijeva rizik, obujam, prebivalište ili ugovor. Za uobičajeni put, nametnite izolaciju korisnika u glavnoj knjizi pristupnika i mehanizmu pravila, a zatim uskladite zapise pružatelja usluga nakon toga.

Povezano čitanje

• idempotentni partner API dodjela za klijente, ključeve i kredite