Kundebaserte AI API-nøkler: Isoler leietakere, budsjetter og misbruk uten leverandør-nøkkelspredning

Når et produkt lar mange kunder kalle AI-modeller, er feil primitiv ofte oppstrømsleverandørnøkkelen. En leverandørnøkkel representerer vanligvis en konto, et prosjekt, et arbeidsområde eller en tjenestekonto. Produktet ditt trenger noe smalere: en kundevendt nøkkel som identifiserer én leietaker, kunde, applikasjon, miljø, modellpolicy, budsjett og revisjonsregel.

Det er formålet med kundetilpassede AI API-nøkler. Gatewayen utsteder nøkkelen, autentiserer forespørsler, bruker policy, målerbruk og ringer deretter oppstrømsleverandører ved å bruke skjult legitimasjon. Nedstrømskunder mottar aldri leverandørnøkkelen. De får en stabil kontrakt med plattformen din.

Leserproblem: Kundeisolering uten ett leverandørprosjekt per kunde

SaaS-byggere, -byråer og forhandlerplattformer må vanligvis svare på praktiske spørsmål før de kan avsløre AI-tilgang nedstrøms:

• Hvilken kunde genererte denne bruken?
• Hvilken applikasjon, miljø eller integrasjon foretok samtalen?
• Hvilke modeller og modaliteter er tillatt?
• Hvor mye kan denne kunden bruke denne måneden?
• Hva skjer hvis en nøkkel lekker?
• Kan denne kunden suspenderes uten å påvirke alle andre?
• Kan bruk avstemmes mot leverandørrapporter senere?

Prosjekter og arbeidsområder på leverandørsiden kan hjelpe, men de er ikke alltid den rette enheten for alle nedstrømskunder. Å opprette én oppstrømsgrense per kunde kan forbedre hard isolasjon og rapportering, men det skaper også provisjonsoverhead, kvotefragmentering, legitimasjonsspredning og mer avstemmingsarbeid.

En gateway-utstedt nøkkel gir produktet et kontrollpunkt på kundenivå selv når oppstrøms-legitimasjonen er samlet. Den støtter også sterkere moduser, for eksempel påloggingsinformasjon for leietaker eller ta med-din-egen-nøkkel, når en kunde trenger kontraktsmessig separasjon, bostedsgrenser eller direkte eierskap av leverandørkonto.

Fakta, anbefalinger og spådommer

Fakta

• OpenAI-prosjekter støtter medlemmer, tjenestekontoer, API-nøkler, bruksgrenser, budsjetter og prosjektressurser med omfang. Det gjør prosjekter nyttige som oppstrømsgrenser, men ikke automatisk de rette primitive for hver sluttkunde.
• OpenAI-bruksrapportering kan gruppere bruk etter dimensjoner som prosjekt, bruker, API-nøkkel, modell, batch og tjenestenivå. SaaS-tilbakeførsel trenger fortsatt disse leverandørpostene knyttet til produkteide kundeidentifikatorer.
• Antropiske arbeidsområder skiller API-ressurser etter brukstilfelle, team, avdeling, prosjekt eller produkt. API-nøkler er knyttet til arbeidsområdet der de opprettes og kan ikke flyttes mellom arbeidsområder.
• Antropisk bruk og kostnadsrapportering støtter gruppering etter API-nøkkel, arbeidsområde, modell, tjenestenivå, kontekstvindu, dataopphold og hastighetsrelaterte alternativer, med kostnader returnert i daglige USD-bøtter.
• Nøkkelveiledning for Google Gemini API anbefaler å begrense nøkler, og Gemini API-nøkler er begrenset til Generative Language API som standard. Applikasjonsbegrensninger som IP-adresser kan være tilgjengelige avhengig av distribusjonsform.
• OWASP-veiledning behandler API-nøkler som nødvendige kontroller for beskyttede endepunkter og sier at nøkler bør tilbakekalles når klienter bryter bruksavtaler.
• Veiledning for OWASP-hemmeligheter legger vekt på minste privilegium, tilbakekalling når hemmeligheter ikke lenger kreves eller er kompromittert, og automatisert rotasjon for å redusere implementeringsfeil.

Anbefalinger

• Bruk gateway-utstedte kundenøkler som policyhåndtak, ikke bare autentiseringstokener.
• Hold oppstrømsleverandørlegitimasjonen skjult for nedstrømskunder.
• Skriv en gatewaybruksreskontro på forespørselstidspunktet, før du stoler på leverandørdashbord.
• Bruk leverandørprosjekter eller arbeidsområder selektivt for kunder med høy risiko, høyvolum, regulerte, bostedssensitive eller kontraktsmessig separate.
• Bygg nøkkelrotasjon som en overlappende arbeidsflyt, ikke som en umiddelbar bruddhendelse.

Spådommer

• Flere leverandører vil avdekke rikere bruksgruppering og budsjettkontroller, men produkteid kundeattribusjon vil fortsatt være nødvendig for SaaS-fakturering og forhandlerrapportering.
• Forhandler- og byråplattformer vil i økende grad behandle gatewaynøkler som kommersielle objekter: knyttet til planer, kredittsaldoer, omfang og støttearbeidsflyter.
• Kunder med streng overholdelse eller anskaffelsesbehov vil be om eierskap av BYOK eller leverandørkonto, mens de fleste vanlige kunder vil foretrekke en administrert gateway-kontrakt.

Gateway-nøkkelobjektet

En nøkkel med kundeomfang bør løses til et strukturert policyobjekt. Modeller nøkkelen som et minimum som mer enn en hash og et navn.

{
  "key_id": "key_01J9...",
  "tenant_id": "tenant_acme",
  "customer_id": "cust_4812","application_id": "app_support_bot",
  "environment": "produksjon",
  "eier": {
    "type": "tjenestekonto",
    "id": "svc_support_ai"
  },
  "model_profile_id": "profile_support_standard",
  "allowed_modalities": ["tekst", "bildeinngang"],
  "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": "bare metadata",
  "status": "aktiv",
  "created_at": "2026-09-05T10:00:00Z",
  "last_used_at": null
}

De nøyaktige feltene vil variere, men prinsippet bør ikke: hver innkommende forespørsel løser nøkkelen til leietakerpolicyen før utsendelse. Autentisering svarer "hvem ringer?" Retningslinjer svarer "hva kan denne innringeren gjøre, hvor mye kan de bruke, hvor kan forespørselen rute, og hva må logges?"

Det er også her semantisk produktstrategi er viktig. En plattform som selger en AI API for byråer kan trenge kunde- og kampanjedimensjoner. Et utviklerverktøy kan trenge arbeidsområde- og depotdimensjoner. En forhandler kan trenge eksterne kunde-ID-er som samsvarer med faktureringssystemet.

Nøkkelopprettingsarbeidsflyt

Nøkkeloppretting bør være deterministisk nok for automatisering og streng nok for sikkerhetsgjennomgang.

1. Opprett kundeoppføringen først

Ikke lag foreldreløse nøkler. Nøkkelen bør tilhøre en leietaker og en kundejournal før den eksisterer. For forhandlerplattformer bør kundeposten inkludere eksterne ID-er fra forhandlerens CRM- eller faktureringssystem, planmetadata, skatt- eller fakturagruppering om nødvendig, og et statusfelt som kan suspendere alle undernøkler.

2. Legg ved en modellprofil

En modellprofil tilordner kundevendte modellnavn til leverandørmodeller og -funksjoner. For eksempel kan support-standard tillate en balansert tekstmodell, bildeinntasting og ingen kodekjøring. research-premium kan tillate langkontekstmodeller, nettsøk og høyere tak per forespørsel.

Ikke tving nedstrømsapplikasjoner til hardkode-leverandørmodell-ID-er. Bruk gateway-profilen til å administrere tilgjengelighet, reserve, priser og avvikling.

3. Angi forbruks- og satsgrenser

Bruk budsjetter og takstgrenser sammen. Et månedlig budsjett forhindrer fakturaskade over tid. Satsgrenser forhindrer plutselig misbruk, stormer på nytt eller tilfeldige sløyfer fra å forbruke hele budsjettet på få minutter.

Nyttige kontroller inkluderer:

• Månedlig kundebudsjett.
• Daglig soft cap for oppdagelse av anomalier.
• Forespørselsfrekvens per nøkkel.
• Inn- og utdatatokenhastighet.
• Maksimal estimert kostnad per forespørsel.
• Verktøyspesifikke grenser for vertsbasert søk, filbehandling eller kjøring av kode.

Budsjetthåndhevelse bør reservere estimerte kostnader før utsendelse, avgjøre faktiske kostnader etter fullføring og frigjøre ubrukt reserve. Dette kobler nøkkelpolicyen til AI API-fakturering i stedet for å behandle fakturering som en forsinket rapporteringsoppgave.

4. Generer og lagre hemmeligheten riktig

Vis hemmeligheten i ren tekst én gang. Lagre bare en sterk hash, pluss et kort prefiks eller fingeravtrykk for støtteoppslag. Prefikset hjelper støtteteam med å identifisere "nøkkelen som slutter på 8F2A" uten å se hemmeligheten.

Et typisk lagringsmønster er:

• key_id: stabil databaseidentifikator.
• secret_hash: hash av hele hemmeligheten ved å bruke et passende passord eller token hashing-strategi.
• secret_prefix: kort ikke-sensitivt displayprefiks.
• fingeravtrykk: deterministisk identifikator for revisjonsoppslag.
• created_by: bruker eller Partner API-klient som opprettet nøkkelen.
• status: aktiv, utløper, opphevet, satt i karantene, utløpt.

Aldri lagre oppstrømsleverandørnøkler på kundenøkkelobjektet. Leverandørlegitimasjon hører hjemme i et eget legitimasjonshvelv med egne tilgangsregler.

Forespørsel-tidshåndhevelse

Gatewayen bør behandle hvert modellanrop som en policybeslutning etterfulgt av en leverandørutsendelse. En praktisk forespørselsbane ser slik ut:

1. Parse den presenterte gatewaynøkkelen.
2. Slå opp nøkkelhashen og statusen.
3. Løs leietaker-, kunde-, applikasjons-, miljø-, eier- og modellprofil.
4. Sjekk om leietaker og kunde er aktive.
5. Valider forespurt modellalias, modalitet, verktøy, oppbevaringsmodus, region og tjenestenivå.
6. Estimer forespørselskostnad og reservebudsjett.
7. Sjekk rategrenser og misbruksterskler.
8. Velg oppstrøms legitimasjonsmodus: samlet, leietakerbundet eller BYOK.
9. Send til leverandøren.
10. Fang opp bruk, kostnader, leverandørreferanser, feil og sikkerhetssignaler.
11. Avgjør budsjettreservasjonen og skriv den endelige hovedbokhendelsen.

Denne sekvensen holder gatewayen ansvarlig for kundekontrakten. Leverandørdashbord blir forsoningsinndata, ikke den eneste kilden til sannhet.

Bruksreskontrofelter som faktisk hjelper senere

En gateway-reskontro skal ha nok detaljer til å svare på spørsmål om støtte, fakturering, misbruk og ruting uten å kreve ubehandlet lagring som standard.

Useful fields include:

• request_id og trace_id.
• tenant_id, customer_id, application_id og key_id.
• Sluttbrukeridentifikator, fortrinnsvis pseudonym der det er aktuelt.
• Model alias requested by the customer.
• Resolved upstream provider and model.
• Inndata, utdata, resonnement, bufret, lyd, bilde, video og verktøybruk der det er aktuelt.
• Offert kostnad, reservert beløp, utlignet kostnad, valuta og priskatalogversjon.
• Tilbyderforespørsels-ID, bruksrapportreferanse, prosjekt, arbeidsområde eller API-nøkkelgrupperingsdimensjon hvis tilgjengelig.
• Retention policy applied.
• Koder for sikkerhet, misbruk eller retningslinjer.
• Error category and retry metadata.

Denne strukturen støtter tilbakeføring, kundestøtte, hendelsesrespons og en arbeidsflyt for API-nøkkeladministrasjon som kan svare "hva gjorde denne nøkkelen?" without exposing unrelated tenants.

Legitimasjonsmoduser: samlet, leietakerbundet og BYOK

Pooled Provider Credentials

I standardmodus ruter mange kundenøkler gjennom et mindre sett med leverandørlegitimasjon. Dette er operativt enkelt og reduserer spredning på leverandørsiden. Det fungerer når gatewayen har sterk leietakerattribusjon, budsjetthåndhevelse, takstbegrensning, misbruksisolasjon og kontroller for cachegrense.

Kompromissen er at rapportering på leverandørsiden bare kan vise gateway-legitimasjonen eller leverandørprosjektet. Du må slå sammen leverandørposter tilbake til gateway-reskontroposter for å produsere fakturering og analyser på kundenivå.

Tenant-Bound Provider Credentials

For større eller mer risikofylte leietakere, bind en leietaker til et dedikert leverandørprosjekt, arbeidsområde, tjenestekonto eller nøkkel. Dette gir sterkere oppstrømsseparasjon og kan forenkle rapportering på leverandørsiden. Det kan også gi en hard kvote-backstop hvis leverandøren støtter grenser ved den grensen.

The cost is operational complexity. Klargjøring, rotasjon, leverandørgrenser, hendelsesrespons og avstemming skjer nå på tvers av flere oppstrømsobjekter.

Bring Your Own Key

BYOK kan være nyttig når kunder må eie leverandørkontoen, forhandle sin egen leverandørkontrakt eller holde leverandørfakturering separat. Gatewayen bruker fortsatt modellprofiler, rutingpolicy, analyser og kontroller på applikasjonsnivå der det er mulig.

The trade-off is support complexity. Hver kundes leverandørkonto kan ha forskjellig modelltilgang, kvoter, priser, oppbevaringsinnstillinger og hendelsesstatus. Gatewayen må oppdage og forklare disse forskjellene tydelig.

Revocation And Quarantine

Tilbakekalling bør blokkere nye forespørsler umiddelbart for en kundenøkkel uten å rotere urelatert oppstrømsleverandørlegitimasjon. Dette er en av hovedfordelene med virtuelle nøkler.

Bruk separate tilstander for forskjellige operasjonelle handlinger:

• aktiv: forespørsler er tillatt.
• tømmer: gammel nøkkel godtas under et rotasjonsvindu, men advarsler og revisjonshendelser sendes ut.
• opphevet: nye forespørsler avvises permanent.
• i karantene: nye forespørsler blokkeres på grunn av misbruk, betaling, retningslinjer eller hendelsesrespons.
• utløpt: nøkkelen har overskredet levetiden og må erstattes.

Karantene bør være reversibel når hendelsen er løst. Tilbakekalling bør vanligvis ikke være reversibel, fordi gjenoppretting av gamle hemmeligheter øker forvirring og risiko.

Når en nøkkel bryter retningslinjene for bruk, logger du årsaken, aktøren, tidspunktet og omfanget av håndhevelsen. Hvis avgjørelsen ble automatisert, bevar regelversjonen og signalene som utløste den. This keeps customer conversations factual.

Rotation Without Breaking Production

Nøkkelrotasjon bør bruke en to-tasters overlappende arbeidsflyt:

1. Opprett en erstatningsnøkkel med samme kunde, applikasjon, modellprofil og grenser med mindre operatøren endrer dem med vilje.
2. Vis den nye hemmeligheten én gang.
3. Merk den gamle nøkkelen som tømmer.
4. Godta begge nøklene for en begrenset periode, for eksempel 7, 14 eller 30 dager, avhengig av kundeplan og risiko.
5. Skriv ut bruksadvarsler på tømmenøkkelen.
6. Varsle eieren eller Partner API-klienten når den gamle nøkkelen fortsatt brukes nær fristen.
7. Ta tilbake den gamle nøkkelen på slutten av vinduet.
8. Behold attribusjon på tvers av begge nøkkel-ID-ene under samme kunde og applikasjon.

Dette unngår den vanlige feilmodusen der en sikkerhetsforbedring blir en produksjonsstans. Rotasjon er fortsatt en kontroll, men det blir en operativ arbeidsflyt med bevis og tidsfrister.

Partner API-overflate

Hvis nedstrømsplattformer administrerer kunder programmatisk, avslør nøkkeloperasjoner gjennom et Partner API. API-en bør støtte idempotensnøkler og revisjonshendelser fordi klargjøring ofte skjer i fakturerings-, onboarding- eller CRM-arbeidsflyter.

Minste endepunkter:

• POST /kunder: opprett eller opphev en kunde.
• POST /customers/{customer_id}/keys: opprett en nøkkel.
• GET /customers/{customer_id}/keys: liste opp nøkler og statuser.
• PATCH /keys/{key_id}: oppdater omfang, eier, grenser, modellprofil eller status.
• POST /keys/{key_id}/rotate: lag erstatning og merk gammel nøkkel som drenering.
• POST /keys/{key_id}/revoke: tilbakekall umiddelbart.
• GET /customers/{customer_id}/usage: returner bruk og kostnad etter tidsrom, nøkkel, app, modell eller sluttbrukerdimensjon.

Hver muterende forespørsel bør godta en idempotensnøkkel. Hver endring bør skrive en revisjonshendelse med aktør, mål, før-og-etter-felt, kilde-IP eller klientidentitet, og årsak der tilgjengelig.

Når skal leverandørprosjekter eller arbeidsområder brukes

Ikke behandle gatewaynøkler og leverandørgrenser som gjensidig utelukkende. De løser forskjellige problemer.

Bruk gateway-nøkler for normal kontroll på kundenivå:

• Attribusjon per kunde.
• Per-program-nøkler.
• Budsjett- og prisgrenser.
• Rask suspensjon.
• Rotasjonsarbeidsflyter.
• Bruksanalyse og forhandlerrapportering.

Legg til leverandørprosjekter, arbeidsområder eller dedikert leverandørlegitimasjon når kunden trenger sterkere separasjon:

• Høyt månedlig volum som fortjener dedikerte kvoter.
• Regulerte arbeidsbelastninger med eksplisitte krav til opphold eller oppbevaring.
• Kontraktmessig fakturaseparasjon.
• Hårde budsjett- eller kvotestopper på leverandørsiden.
• Dedikert overvåking av misbruk eller grenser for sikkerhetsvurdering.
• Kundeeide leverandørkontoer gjennom BYOK.

Den praktiske standard er gateway-håndhevet isolasjon med selektive oppstrøms harde grenser. Det holder den vanlige banen enkel samtidig som den bevarer en eskaleringsvei for kunder som trenger mer separasjon.

Implementeringssjekkliste

• Definer et kundenøkkelskjema med leietaker, kunde, applikasjon, miljø, eier, modellprofil, grenser, oppbevaringspolicy og status.
• Hash hemmeligheter i ro og vis ren tekst bare én gang.
• Skill gatewaynøkler fra oppstrøms leverandørlegitimasjonslagring.
• Løs hver forespørsel i retningslinjene før utsendelse.
• Reserver budsjett før leverandøren ringer og gjør opp etter at endelig bruk er kjent.
• Registrer bruk med kunde, nøkkel, modellalias, oppstrømsmodell, tokenkategorier, verktøybruk, oppgitt pris, avgjort kostnad og leverandørreferanser.
• Implementer tilstander som er aktive, tømmende, opphevet, karantene og utløpt.
• Støtt to-tasts rotasjonsoverlapping.
• Vis partner-API-operasjoner med idempotensnøkler.
• Bruk leverandørprosjekter eller arbeidsområder bare der driftskostnadene er berettiget.

Aktiv konklusjon

Kundeisolering for AI-tilgang bør vanligvis starte ved gateway-nøkkelen, ikke ved leverandørnøkkelen. Gateway-nøkkelen er den kundevendte kontrakten: den gir navn til leietaker, kunde, applikasjon, modellprofil, budsjett, takstgrense, oppbevaringsregel og revisjonspolicy. Leverandørnøkkelen er en implementeringsdetalj bak den kontrakten.

Denne arkitekturen gir SaaS-byggere og forhandlerplattformer rask tilbakekalling, nøyaktig attribusjon, budsjetter per kunde, kontrollert rotasjon og nyttig bruksanalyse uten å opprette ett oppstrøms leverandørprosjekt for hver kunde som standard. Bruk oppstrømsprosjekter, arbeidsområder, leietakerbundet legitimasjon eller BYOK når risiko, volum, bosted eller kontrakt krever det. For den ordinære banen, håndhev kundeisolering i gateway-reskontro- og policy-motoren, og avstem deretter leverandørposter etterpå.

Relatert lesing

• studiepoeng