Chei API AI adaptate clienților: izolați chiriașii, bugetele și abuzurile fără extinderea cheilor furnizorului

Atunci când un produs permite multor clienți să apeleze modele AI, primitivul greșit este adesea cheia furnizorului din amonte. O cheie de furnizor reprezintă de obicei un cont, un proiect, un spațiu de lucru sau un cont de serviciu. Produsul dvs. are nevoie de ceva mai restrâns: o cheie orientată către client care identifică un locatar, client, aplicație, mediu, politică de model, buget și regulă de audit.

Acesta este scopul cheilor API AI definite de client. Gateway-ul emite cheia, autentifică cererile, aplică politica, contorizează utilizarea și apoi apelează furnizorii din amonte folosind acreditări ascunse. Clienții din aval nu primesc niciodată cheia furnizorului. Aceștia primesc un contract stabil cu platforma dvs.

Problemă de citire: izolarea clienților fără un proiect de furnizor per client

Constructorii, agențiile și platformele de reseller SaaS trebuie de obicei să răspundă la întrebări practice înainte de a putea expune accesul AI în aval:

• Ce client a generat această utilizare?
• Ce aplicație, mediu sau integrare a făcut apelul?
• Ce modele și modalități sunt permise?
• Cât poate cheltui acest client în această lună?
• Ce se întâmplă dacă o cheie se scurge?
• Acest client poate fi suspendat fără a afecta pe toți ceilalți?
• Utilizarea poate fi reconciliată cu rapoartele furnizorului mai târziu?

Proiectele și spațiile de lucru din partea furnizorului pot ajuta, dar nu sunt întotdeauna unitatea potrivită pentru fiecare client din aval. Crearea unei limite în amonte pentru fiecare client poate îmbunătăți izolarea și raportarea strictă, dar creează, de asemenea, supraîncărcare de furnizare, fragmentare a cotelor, extinderea acreditărilor și mai multă muncă de reconciliere.

O cheie emisă de gateway oferă produsului un punct de control la nivel de client chiar și atunci când acreditările din amonte sunt reunite. De asemenea, acceptă moduri mai puternice, cum ar fi acreditările furnizorului legat de chiriaș sau aduceți-vă propria cheie, atunci când un client are nevoie de separare contractuală, limite de rezidență sau deținere directă a contului de furnizor.

Fapte, recomandări și previziuni

Fapte

• Proiectele OpenAI acceptă membri, conturi de serviciu, chei API, limite de utilizare, bugete și resurse ale proiectului. Acest lucru face ca proiectele să fie utile ca granițe din amonte, dar nu automat primitivul potrivit pentru fiecare client final.
• Raportarea de utilizare OpenAI poate grupa utilizarea în funcție de dimensiuni, cum ar fi proiect, utilizator, cheie API, model, lot și nivel de serviciu. Rambursarea SaaS are nevoie în continuare de acele înregistrări ale furnizorilor asociate cu identificatorii clienților deținut de produs.
• Spațiile de lucru antropice separă resursele API în funcție de caz de utilizare, echipă, departament, proiect sau produs. Cheile API sunt legate de spațiul de lucru în care sunt create și nu pot fi mutate între spațiile de lucru.
• Utilizarea antropică și raportarea costurilor acceptă gruparea după cheie API, spațiu de lucru, model, nivel de serviciu, fereastră de context, rezidență a datelor și opțiuni legate de viteză, cu costurile returnate în bucăți zilnice de USD.
• Instrucțiunile pentru cheile Google Gemini API recomandă restricționarea cheilor, iar cheile Gemini API sunt restricționate la API-ul Generative Language în mod prestabilit. Restricțiile aplicației, cum ar fi adresele IP, pot fi disponibile în funcție de forma de implementare.
• Ghidul OWASP tratează cheile API ca comenzi necesare pentru punctele finale protejate și spune că cheile ar trebui revocate atunci când clienții încalcă acordurile de utilizare.
• Ghidul privind secretele OWASP subliniază cel mai mic privilegiu, revocarea atunci când secretele nu mai sunt necesare sau sunt compromise și rotația automată pentru a reduce erorile de implementare.

Recomandări

• Utilizați cheile client emise de gateway ca handle de politică, nu doar simboluri de autentificare.
• Păstrați acreditările furnizorului din amonte ascunse pentru clienții din aval.
• Scrieți un registru de utilizare a gateway-ului la momentul solicitării, înainte de a vă baza pe tablourile de bord ale furnizorilor.
• Utilizați proiectele sau spațiile de lucru ale furnizorilor în mod selectiv pentru clienți cu risc ridicat, volum mare, reglementați, sensibili la rezidență sau separati prin contract.
• Construiți rotația tastelor ca un flux de lucru de suprapunere, nu ca un eveniment de rupere imediată.

Predicții

• Mai mulți furnizori vor expune grupări de utilizare mai bogate și controale bugetare, dar atribuirea clienților deținute de produse va fi în continuare necesară pentru facturarea SaaS și pentru raportarea distribuitorilor.
• Platformele de distribuitori și agenții vor trata din ce în ce mai mult cheile de gateway ca obiecte comerciale: legate de planuri, solduri creditare, domenii și fluxuri de lucru de asistență.
• Clienții cu nevoi stricte de conformitate sau achiziții vor solicita BYOK sau proprietatea unui cont de furnizor, în timp ce majoritatea clienților obișnuiți vor prefera un contract de gateway gestionat.

Obiectul cheie Gateway

O cheie aferentă clientului ar trebui să se rezolve într-un obiect de politică structurat. Modelați cel puțin cheia ca mai mult decât un hash și un nume.

{
  "key_id": "key_01J9...",
  "tenant_id": "tenant_acme",
  "customer_id": "cust_4812","application_id": "app_support_bot",
  „mediu”: „producție”,
  „proprietar”: {
    "type": "service_account",
    "id": "svc_support_ai"
  },
  "model_profile_id": "profile_support_standard",
  "allowed_modalities": ["text", "image_input"],
  "tool_policy_id": "tools_readonly_kb",
  „buget_lunar”: {
    "currency": "USD",
    "suma": "500,00"
  },
  „rate_limits”: {
    „cereri_per_minut”: 120,
    „input_tokens_per_minute”: 250000,
    „output_tokens_per_minute”: 80000
  },
  "retention_policy": "numai metadate",
  "status": "activ",
  "created_at": "2026-09-05T10:00:00Z",
  „last_used_at”: nul
}

Câmpurile exacte vor varia, dar principiul nu ar trebui: fiecare solicitare primită rezolvă cheia în politica chiriașilor înainte de expediere. Autentificarea răspunde „cine sună?” Rezolvarea politicii răspunde „ce poate face acest apelant, cât poate cheltui, unde poate ruta solicitarea și ce trebuie înregistrat?”

De asemenea, aici contează strategia semantică a produsului. O platformă care vinde un AI API pentru agenții poate avea nevoie de parametri pentru clienți și campanie. Un instrument de dezvoltator poate avea nevoie de dimensiuni de spațiu de lucru și de depozit. Un revânzător poate avea nevoie de ID-uri de client extern care se potrivesc cu sistemul său de facturare.

Flux de lucru pentru crearea cheilor

Crearea cheilor ar trebui să fie suficient de deterministă pentru automatizare și suficient de strictă pentru examinarea securității.

1. Creați mai întâi înregistrarea clientului

Nu creați chei orfane. Cheia ar trebui să aparțină unui chiriaș și unui client înainte de a exista. Pentru platformele de reseller, înregistrarea clientului ar trebui să includă ID-uri externe din sistemul CRM sau de facturare al revânzătorului, metadatele planului, taxele sau gruparea facturilor dacă este necesar și un câmp de stare care poate suspenda toate cheile secundare.

2. Atașați un profil de model

Un profil de model mapează numele modelelor adresate clienților la modelele și capabilitățile furnizorilor. De exemplu, support-standard ar putea permite un model de text echilibrat, introducerea imaginii și nicio execuție a codului. research-premium ar putea permite modele de context lung, căutare pe web și plafoane mai mari pentru fiecare solicitare.

Nu forțați aplicațiile din aval să codifice ID-urile modelului furnizorului. Utilizați profilul gateway pentru a gestiona disponibilitatea, rezerva, prețurile și deprecierea.

3. Setați limite de cheltuieli și rate

Utilizați împreună bugetele și limitele de tarife. Un buget lunar previne deteriorarea facturilor în timp. Limitele ratelor împiedică abuzurile bruște, furtunile din nou încercarea sau buclele accidentale să consume întregul buget în câteva minute.

Comenzile utile includ:

• Bugetul lunar al clientului.
• Capac moale zilnic pentru detectarea anomaliilor.
• Rata de solicitare pe cheie.
• Rata simbolurilor de intrare și de ieșire.
• Costul maxim estimat per cerere.
• Limite specifice instrumentului pentru căutarea găzduită, procesarea fișierelor sau executarea codului.

Executarea bugetului ar trebui să rezerve costul estimat înainte de expediere, să plătească costul real după finalizare și să elibereze rezerva neutilizată. Aceasta conectează politica cheie la facturarea API AI, în loc să trateze facturarea ca pe o sarcină de raportare întârziată.

4. Generați și stocați corect secretul

Afișați o dată secretul text simplu. Stocați doar un hash puternic, plus un prefix scurt sau amprentă digitală pentru căutarea de asistență. Prefixul ajută echipele de asistență să identifice „cheia care se termină în 8F2A” fără a vedea secretul.

Un model tipic de stocare este:

• key_id: identificator stabil al bazei de date.
• secret_hash: hash al secretului complet folosind o strategie adecvată de hashing pentru parole sau token.
• secret_prefix: prefix de afișare scurt, nesensibil.
• amprentă digitală: identificator determinist pentru căutarea de audit.
• created_by: utilizator sau client API Partner care a creat cheia.
• stare: activ, epuizat, revocat, pus în carantină, expirat.

Nu stocați niciodată cheile furnizorului din amonte pe obiectul cheie client. Acreditările furnizorului aparțin unui seif separat de acreditări cu propriile reguli de acces.

Executare la momentul solicitării

Poarta de acces ar trebui să trateze fiecare apel model ca o decizie de politică urmată de o trimitere a furnizorului. O cale practică de solicitare arată astfel:

1. Analizați cheia gateway-ului prezentată.
2. Căutați codul hash și starea cheii.
3. Rezolvați profilul chiriașului, clientului, aplicației, mediului, proprietarului și modelului.
4. Verificați dacă locatarul și clientul sunt activi.
5. Validați aliasul de model solicitat, modalitatea, instrumentele, modul de păstrare, regiunea și nivelul de serviciu.
6. Estimați costul cererii și bugetul de rezervă.
7. Verificați limitele ratelor și pragurile de abuz.
8. Selectați modul de autentificare în amonte: grupat, legat de locatari sau BYOK.
9. Expediere către furnizor.
10. Captați utilizarea, costul, referințele furnizorilor, erorile și semnalele de siguranță.
11. Rezolvați rezervarea bugetului și scrieți evenimentul registrului final.

Această secvență menține gateway-ul responsabil pentru contractul cu clientul. Tablourile de bord ale furnizorilor devin intrări de reconciliere, nu singura sursă de adevăr.

Utilizați câmpurile registrului contabil care de fapt ajută mai târziu

Un registru gateway ar trebui să păstreze suficiente detalii pentru a răspunde întrebărilor legate de asistență, facturare, abuz și rutare, fără a necesita stocarea promptă brută în mod implicit.

Câmpurile utile includ:

• request_id și trace_id.
• tenant_id, customer_id, application_id și key_id.
• Identificatorul utilizatorului final, de preferință pseudonim, acolo unde este cazul.
• Alias de model solicitat de client.
• S-au rezolvat furnizorul și modelul din amonte.
• Intrare, ieșire, raționament, stocare în cache, audio, imagine, video și utilizarea instrumentului, acolo unde este cazul.
• Costul cotat, suma rezervată, costul decontat, moneda și versiunea catalogului de prețuri.
• ID solicitarea furnizorului, referința raportului de utilizare, proiectul, spațiul de lucru sau dimensiunea grupării cheilor API, dacă este disponibil.
• Politica de păstrare aplicată.
• Coduri de siguranță, de abuz sau de decizie privind politicile.
• Eroare categorie și reîncercați metadatele.

Această structură acceptă rambursare, asistență pentru clienți, răspuns la incident și un flux de lucru gestionarea cheilor API care poate răspunde „ce a făcut această cheie?” fără a expune chiriașii neînrudiți.

Moduri de acreditări: grupate, legate de chiriași și BYOK

Acreditări ale furnizorului grupate

În modul implicit, multe chei de client sunt direcționate printr-un set mai mic de acreditări ale furnizorului. Acest lucru este simplu din punct de vedere operațional și reduce extinderea la nivelul furnizorului. Funcționează atunci când gateway-ul are o atribuire puternică a chiriașilor, aplicarea bugetului, limitarea ratei, izolarea abuzului și controalele limitelor cache-ului.

Compartimentul este că raportarea la nivelul furnizorului poate afișa numai acreditările gateway-ului sau proiectul furnizorului. Trebuie să vă conectați înregistrările furnizorului înapoi la înregistrările registrului gateway pentru a produce facturare și analize la nivel de client.

Acreditările furnizorului legat de chiriaș

Pentru chiriașii mai mari sau mai riscați, legați un chiriaș la un proiect de furnizor dedicat, spațiu de lucru, cont de serviciu sau cheie. Acest lucru oferă o separare mai puternică în amonte și poate simplifica raportarea furnizorilor. Poate oferi, de asemenea, o rezervă de cotă rigidă dacă furnizorul acceptă limite la limita respectivă.

Costul este complexitatea operațională. Aprovizionarea, rotația, limitele furnizorilor, răspunsul la incident și reconcilierea au loc acum pentru mai multe obiecte din amonte.

Aduceți-vă propria cheie

BYOK poate fi util atunci când clienții trebuie să dețină contul de furnizor, să își negocieze propriul contract cu furnizorul sau să păstreze separat facturarea furnizorului. Gateway-ul aplică în continuare profiluri de model, politica de rutare, analize și controale la nivel de aplicație, acolo unde este posibil.

Compartimentul este complexitatea suportului. Contul de furnizor al fiecărui client poate avea acces la model, cote, prețuri, setări de păstrare și starea incidentului diferit. Poarta de acces trebuie să detecteze și să explice clar aceste diferențe.

Revocare și carantină

Revocarea ar trebui să blocheze imediat noile solicitări pentru o cheie de client, fără a schimba acreditările de furnizor care nu au legătură în amonte. Acesta este unul dintre principalele avantaje ale tastelor virtuale.

Utilizați stări separate pentru diferite acțiuni operaționale:

• activ: cererile sunt permise.
• evacuare: vechea cheie este acceptată în timpul unei ferestre de rotație, dar sunt emise avertismente și evenimente de audit.
• revocat: cererile noi sunt respinse definitiv.
• în carantină: solicitările noi sunt blocate din cauza abuzului, plății, politicii sau răspunsului la incident.
• a expirat: cheia și-a depășit durata de viață și trebuie înlocuită.

Carantina ar trebui să fie reversibilă atunci când incidentul este rezolvat. De obicei, revocarea nu ar trebui să fie reversibilă, deoarece restaurarea vechilor secrete crește confuzia și riscul.

Când o cheie încalcă politica de utilizare, înregistrați motivul, actorul, timpul și domeniul de aplicare. Dacă decizia a fost automatizată, păstrați versiunea regulii și semnalele care au declanșat-o. Acest lucru păstrează conversațiile cu clienții reale.

Rotație fără întrerupere a producției

Rotirea tastelor ar trebui să utilizeze un flux de lucru cu două taste suprapuse:

1. Creați o cheie de înlocuire cu același client, aplicație, profil de model și limite, cu excepția cazului în care operatorul le modifică în mod intenționat.
2. Afișează noul secret o dată.
3. Marcați vechea cheie ca se scurge.
4. Acceptați ambele chei pentru o perioadă limitată, cum ar fi 7, 14 sau 30 de zile, în funcție de planul și riscul clientului.
5. Emiteți avertismente de utilizare pe cheia de golire.
6. Anunțați proprietarul sau clientul Partner API atunci când vechea cheie este încă folosită în apropierea termenului limită.
7. Revocați vechea cheie de la capătul ferestrei.
8. Păstrați atribuirea pentru ambele ID-uri cheie sub același client și aplicație.

Acest lucru evită modul obișnuit de eroare în care o îmbunătățire a securității devine o întrerupere a producției. Rotația este încă un control, dar devine un flux de lucru operațional cu dovezi și termene limită.

Partner API Surface

Dacă platformele din aval gestionează clienții în mod programatic, expuneți operațiunile cheie printr-un API Partner. API-ul ar trebui să accepte chei de idempotence și evenimente de audit, deoarece furnizarea are loc adesea în cadrul fluxurilor de lucru de facturare, integrare sau CRM.

Punctele finale minime:

• POST /clienți: creați sau ridicați un client.
• POST /customers/{customer_id}/keys: creați o cheie.
• GET /customers/{customer_id}/keys: listează cheile și stările.
• PATCH /keys/{key_id}: actualizați domeniile, proprietarul, limitele, profilul modelului sau starea.
• POST /keys/{key_id}/rotate: creați o cheie de înlocuire și marcați cheia veche ca epuizată.
• POST /keys/{key_id}/revoke: revocați imediat.
• GET /customers/{customer_id}/usage: returnați utilizarea și costul în funcție de intervalul de timp, cheie, aplicație, model sau dimensiunea utilizatorului final.

Fiecare cerere mutantă ar trebui să accepte o cheie de idempotenta. Fiecare modificare ar trebui să scrie un eveniment de audit cu actor, țintă, câmpuri înainte și după, IP sursă sau identitate client și motiv, acolo unde este disponibil.

Când să utilizați proiectele sau spațiile de lucru ale furnizorului

Nu tratați cheile gateway-ului și limitele furnizorului ca fiind excluse reciproc. Ele rezolvă diferite probleme.

Utilizați cheile gateway pentru controlul normal la nivel de client:

• Atribuire pe client.
• Taste pentru fiecare aplicație.
• Buget și limite de tarife.
• Suspensie rapidă.
• Fluxuri de lucru de rotație.
• Analitice de utilizare și raportare pentru distribuitori.

Adăugați proiecte de furnizor, spații de lucru sau acreditări de furnizor dedicat atunci când clientul are nevoie de o separare mai puternică:

• Volum lunar mare care merită cote dedicate.
• Scărcări de muncă reglementate cu cerințe explicite de rezidență sau de păstrare.
• Separarea facturii contractuale.
• Buget dur la nivelul furnizorului sau măsuri de respingere a cotei.
• Monitorizarea abuzurilor dedicate sau limitele de evaluare a siguranței.
• Conturi de furnizor deținute de client prin BYOK.

Valoarea implicită practică este izolarea impusă de gateway cu granițe dure selective în amonte. Acest lucru menține calea comună simplă, păstrând în același timp o cale de escaladare pentru clienții care au nevoie de mai multă separare.

Lista de verificare a implementării

• Definiți o schemă de cheie pentru client cu chiriaș, client, aplicație, mediu, proprietar, profil de model, limite, politică de păstrare și stare.
• Hash secretele în repaus și afișați text simplu o singură dată.
• Separați cheile gateway-ului de stocarea acreditărilor furnizorului din amonte.
• Rezolvați fiecare solicitare în politică înainte de expediere.
• Rezervați bugetul înainte de a apela furnizorul și stabiliți-l după ce se cunoaște utilizarea finală.
• Înregistrați utilizarea cu client, cheie, alias de model, model din amonte, categorii de simboluri, utilizarea instrumentului, costul cotat, costul decontat și referințele la furnizor.
• Implementați stările active, de scurgere, revocate, puse în carantină și expirate.
• Acceptă suprapunerea rotației cu două taste.
• Expunerea operațiunilor Partner API cu chei de idempotence.
• Utilizați proiectele sau spațiile de lucru ale furnizorilor numai acolo unde costul lor operațional este justificat.

Concluzie acționabilă

Izolarea clientului pentru accesul AI ar trebui să înceapă de obicei de la cheia gateway-ului, nu de la cheia furnizorului. Cheia gateway-ului este contractul orientat către client: numește chiriașul, clientul, aplicația, profilul modelului, bugetul, limita de tarif, regula de reținere și politica de audit. Cheia furnizorului este un detaliu de implementare din spatele contractului respectiv.

Această arhitectură oferă constructorilor SaaS și platformelor de reseller revocare rapidă, atribuire precisă, bugete pe client, rotație controlată și analize utile de utilizare, fără a crea în mod implicit un singur proiect de furnizor pentru fiecare client. Utilizați proiecte din amonte, spații de lucru, acreditări legate de chiriași sau BYOK atunci când riscul, volumul, rezidența sau contractul o impun. Pentru calea obișnuită, impuneți izolarea clienților în registrul gateway și în motorul de politici, apoi reconciliați înregistrările furnizorului ulterior.

Lectură similară

• chei de provizionare, API-idempotent și parteneri pentru clienți credite