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 uzvodni 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 čitačem: Izolacija korisnika bez jednog projekta pružatelja po korisniku

Sagraditelji 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 korisnika. Stvaranje jedne uzlazne 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 davatelja vezane uz stanara ili donesite vlastiti ključ, kada korisnik treba ugovorno razdvajanje, granice prebivališta ili izravno vlasništvo nad računom davatelja.

Činjenice, preporuke i predviđanja

Činjenice

• Članovi podrške projektima OpenAI, računi usluga, API ključevi, ograničenja upotrebe, proračuni i projektni resursi s opsegom. To čini projekte korisnima kao uzvodne granice, ali ne i automatski pravom primitivom za svakog krajnjeg kupca.
• Izvješća o upotrebi OpenAI mogu grupirati upotrebu 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.
• Antropski radni prostori razdvajaju resurse API-ja prema slučaju upotrebe, timu, odjelu, projektu ili proizvodu. API ključevi vezani su za radni prostor u kojem su stvoreni i ne mogu se premještati između radnih prostora.
• Izvješćivanje o antropičkoj upotrebi i troškovima podržava grupiranje prema ključu API-ja, radnom prostoru, modelu, razini usluge, kontekstualnom prozoru, prebivalištu podataka i opcijama vezanim uz brzinu, s troškovima koji se vraćaju u dnevnim dolarskim segmentima.
• Google Gemini API smjernice za ključeve preporučuju ograničavanje ključeva, a Gemini API ključevi prema zadanim su postavkama ograničeni na Generative Language 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 smjernice za tajne 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 neophodna 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.
• Kupci 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 razriješiti u strukturirani objekt pravila. Minimalno, modelirajte ključ kao nešto više od hasha i imena.

{
  "key_id": "ključ_01J9...",
  "tenant_id": "stanar_acme",
  "customer_id": "cust_4812","application_id": "app_support_bot",
  "okoliš": "proizvodnja",
  "vlasnik": {
    "vrsta": "uslužni_račun",
    "id": "svc_support_ai"
  },
  "model_profile_id": "standardna_podrška_profila",
  "allowed_modalities": ["text", "image_input"],
  "tool_policy_id": "tools_readonly_kb",
  "mjesečni_proračun": {
    "currency": "USD",
    "iznos": "500,00"
  },
  "ograničenja_stope": {
    "zahtjevi_po_minuti": 120,
    "input_tokens_per_minute": 250000,
    "output_tokens_per_minute": 80000
  },
  "pravila_zadržavanja": "samo_metapodaci",
  "status": "aktivan",
  "created_at": "2026-09-05T10:00:00Z",
  "zadnje_korišteno_u": 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 semantička strategija 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 ID-ove korisnika 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. Najprije 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 na korisnike 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 dobavljača 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.
• Stopa ulaznog i izlaznog tokena.
• Maksimalni procijenjeni trošak po zahtjevu.
• Ograničenja specifična za alate 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 ključnu politiku s naplatom AI API-ja 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 identificirati "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 korištenjem odgovarajuće strategije raspršivanja lozinke ili tokena.
• secret_prefix: kratki neosjetljivi prefiks prikaza.
• otisak prsta: deterministički identifikator za revizijsko pretraživanje.
• created_by: korisnički ili partnerski API klijent koji je kreirao 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 poziv modela 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. Razriješite profil stanara, korisnika, aplikacije, okruženja, vlasnika i modela.
4. Provjerite jesu li stanar i korisnik aktivni.
5. Potvrdite traženi pseudonim modela, modalitet, alate, način zadržavanja, regiju i razinu usluge.
6. Procijenite trošak zahtjeva i rezervirajte proračun.
7. Provjerite ograničenja stope i pragove zlouporabe.
8. Odaberite uzvodni način vjerodajnice: skupni, vezan za stanara ili BYOK.
9. Slanje dobavljaču.
10. Zabilježite upotrebu, cijenu, reference pružatelja usluga, pogreške i sigurnosne signale.
11. Odredite proračunsku rezervaciju i zapišite konačni događaj u glavnoj knjizi.

Ovim slijedom pristupnik je odgovoran za korisnički ugovor. Nadzorne ploče pružatelja usluga postaju ulazi za usklađivanje, a ne jedini izvor istine.

Upotrijebite polja knjige 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 ako je prikladno.
• Nadimak modela na zahtjev kupca.
• Riješen uzlazni pružatelj i model.
• Unos, izlaz, obrazloženje, predmemorirano, zvuk, 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 dimenzija grupiranja ključeva API-ja ako je dostupna.
• Primijenjena su pravila 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 tijek rada API ključa za upravljanje koji može odgovoriti na pitanje "što je ovaj ključ učinio?" bez izlaganja nepovezanih stanara.

Načini vjerodajnica: združeni, 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. Funkcionira kada pristupnik ima jaku atribuciju zakupca, provedbu proračuna, ograničenje stope, izolaciju zlouporabe i kontrole granica predmemorije.

Kompromis je u tome što izvješćivanje na strani davatelja može prikazati samo vjerodajnicu pristupnika ili projekt davatelja. Zapise pružatelja morate pridružiti zapisima glavne knjige pristupnika kako biste proizveli naplatu i analitiku na razini korisnika.

Vjerodajnice davatelja vezane za stanara

Za veće ili rizičnije zakupce, zakupca vežite za namjenski projekt pružatelja, radni prostor, račun usluge ili ključ. To daje snažnije 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 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 uzlaznog davatelja. Ovo je jedna od glavnih prednosti virtualnih ključeva.

Koristite odvojena stanja za različite operativne radnje:

• aktivno: zahtjevi su dopušteni.
• ispuštanje: stari ključ se prihvaća tijekom prozora rotacije, ali se emitiraju upozorenja i revizijski događaji.
• opozvano: novi zahtjevi se trajno odbijaju.
• u karanteni: novi zahtjevi blokirani su zbog zloupotrebe, plaćanja, pravila ili odgovora na incident.
• istekao: ključ je istekao i mora se zamijeniti.

Karantena bi se trebala poništiti kada se incident riješi. Opoziv se obično ne bi trebao poništiti 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. To održava razgovore korisnika č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čite stari ključ kao prazni.
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. Emitira 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 Surface

Ako nizvodne platforme upravljaju klijentima programski, izložite ključne operacije putem Partner API-ja. 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: stvorite 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 mutiranje treba prihvatiti ključ idempotencije. Svaka promjena treba napisati revizijski događaj s akterom, ciljem, poljima prije i poslije, izvornim IP-om ili identitetom klijenta i razlogom ako je moguće.

Kada koristiti projekte ili radne prostore dobavljača

Nemojte smatrati da se ključevi pristupnika i granice pružatelja međusobno isključuju. 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 ovjes.
• Tijekovi rada rotacije.
• Analitika korištenja i izvješća preprodavač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.
• Čvrsti proračun ili kvota za zaštitu od strane pružatelja usluga.
• Namjensko praćenje zlouporabe 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.

Popis za provjeru implementacije

• 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 pružatelja usluga i podmirite ga nakon što postane 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 dvije tipke.
• Izlaganje Partner API operacija 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 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 kupca 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

• idempotent Partner API pružanje usluga za klijente, ključeve i krediti