Leverandørlegitimasjonshvelv for multi-modell AI-gatewayer: separat kjøretid, admin, fakturering og BYOK-tilgang

Nedstrøms API-nøkler og oppstrømsleverandørlegitimasjon løser forskjellige problemer. En utviklernøkkel utstedt av gatewayen din identifiserer app-, team-, leietaker-, budsjett- og policykontekst. En oppstrøms leverandørnøkkel lar gatewayen bruke penger og få tilgang til modeller på en leverandørkonto. Å behandle disse som den samme typen hemmelighet er hvordan team ender opp med én ubegrenset nøkkel i et delt prosjekt, administratorlegitimasjon i kjøretidstjenester og ingen pålitelig måte å svare på hvilken leietaker som forårsaket hvilken leverandørsideavgift.

Det praktiske mønsteret er et leverandørlegitimasjonshvelv: et dedikert kontrollplan for å importere, klassifisere, lagre, velge, rotere og revidere oppstrømslegitimasjon. Den skal sitte bak ruteren, faktureringsboken, policymotoren og arbeidsflyten – ikke inne i programkode, modellkonfigurasjonsfiler, leietakerposter eller analysehendelser.

Leserproblemet: oppstrøms legitimasjon blir usynlig infrastruktur

De fleste distribusjoner med flere modeller starter med et enkelt mål: rute én OpenAI-kompatibel forespørsel til den beste tilgjengelige leverandøren. Deretter vises flere kontoer: ett leverandørprosjekt for produksjon, et annet for evaluering, et antropisk arbeidsområde for en forretningsenhet, et Google Cloud-prosjekt for Gemini og flere kundeleverte nøkler for BYOK-kontrakter.

Risikoen er ikke bare hemmelig lekkasje. Det er tap av autorisasjonskontekst. En gyldig leverandørnøkkel kan være teknisk i stand til å kalle et endepunkt, men gatewayen må fortsatt vite om den nøkkelen er tillatt for denne leietakeren, denne modellfamilien, denne datalagringspolicyen, dette budsjettet, denne regionen og denne automatiseringsbanen.

Fakta: leverandørplattformer avslører ulike kontogrenser og påloggingstyper. OpenAI dokumenterer prosjekter og tjenestekontoer, og tjenestekonto API-nøkkeltillatelser er som standard lese- og skrivetilgang for prosjektets API-ressurser. OpenAI eksponerer også Admin API-nøkkelobjekter separat fra vanlig prosjekt-/runtime API-bruk. Anthropic dokumenterer arbeidsområder som en organisasjonsgrense og sier at Admin API-endepunkter krever Admin API-nøkler som er forskjellige fra standard API-nøkler; Anthropic bemerker også at API-nøkler er knyttet til arbeidsområdet der de er opprettet og ikke kan flyttes mellom arbeidsområder. Googles Gemini API-nøkkeldokumentasjon sier at hver Gemini API-nøkkel er assosiert med et Google Cloud-prosjekt og anbefaler API-begrensninger for å redusere skade hvis en nøkkel blir kompromittert.

Anbefaling: ikke bygg ett generisk «provider_key»-felt og kall det ferdig. Bygg en påloggingsbeholdning som bevarer leverandørspesifikke grenser samtidig som en normalisert policymodell eksponeres for gatewayen.

Definer en legitimasjonstaksonomi før du godtar nøkler

Et hvelv bør avvise tvetydig legitimasjon. På importtidspunktet må operatøren eller automatiseringsarbeidsflyten klassifisere legitimasjonen. Bruk som minimum disse kategoriene:

• Kjøretidsslutningslegitimasjon: brukes av gatewayen til å kalle modellslutningsendepunkter som chat, svar, innebygging, moderering, transkripsjon eller bildegenerering, avhengig av leverandørstøtte.
• Automasjonslegitimasjon for administrator: brukes til å administrere organisasjoner på leverandørsiden, arbeidsområder, prosjekter, brukere, nøkler eller administrative ressurser. Disse skal aldri være på kjøretidsforespørselsbanen.
• Fakturerings- og rapporteringslegitimasjon: brukes til å hente bruks-, fakturaer, kostnader eller organisasjonsrapporter der leverandørene støtter disse API-ene. Hold dem adskilt fra slutningsnøkler slik at rapporteringsjobber ikke kan generere modellbruk.
• Kun evalueringslegitimasjon: brukes av arbeidsflyter for benchmark, QA, migrering eller iscenesettelse. De bør ha lave kvoter, klare miljømerker og ingen reservekvalifisering for produksjon.
• Kunde-BYOK-legitimasjon: kundeleverte nøkler knyttet til en spesifikk leietaker, leverandørkonto, kontrakt og datapolicy. De bør ikke slås sammen i delt ruting med mindre kunden eksplisitt velger å delta.

Denne taksonomien er ikke bare dokumentasjon. Det skal drive arbeidsflyter for tilgangskontroll, rutingkvalifisering, varsling og rotasjon. Hvis en legitimasjon importeres uten en kategori, eier, leverandørkontogrense og tillatt bruk, skal den forbli deaktivert.

Lagre hemmeligheter i et hvelv, ikke i produktposter

Hvelvet skal være den eneste komponenten som kan dekryptere oppstrøms legitimasjon. Andre systemer kan lagre referanser, hasher, statusfelt og policy-metadata, men ikke selve legitimasjonsverdien.

Ikke lagre oppstrøms hemmeligheter på disse stedene

• Rader for leietakerprofiler.
• Konfigurasjonsfiler for modellruting.
• Spør logger eller sporingsspenn.
• Analytics-hendelsesnyttelaster.
• Utviklervendte CI-variabler.
• Støttebilletter, chatteverktøy eller skjermbilder.

Et brukbart hvelvdesign har to plan. Det hemmelige flyet lagrer kryptert legitimasjonsmateriale og kontrollerer dekrypteringsoperasjoner tett. metadataplanet lagrer ikke-hemmelige attributter som brukes av ruting og styring. Ruteren skal vanligvis bare trenge en legitimasjons-ID og en kortvarig hemmelig gjenfinning i minnet ved utsendelsestidspunktet, ikke bred databasetilgang til hver leverandørnøkkel.

Beskytt hvelvet som en infrastruktur med høy verdi: konvoluttkryptering eller administrert KMS, strenge tjenesteidentiteter, prosedyrer som bryter glass, testing av sikkerhetskopiering og gjenoppretting, tilgangsgjennomgang og varsling ved uvanlig dekrypteringsvolum. Et sentralt hvelv forenkler styring, men konsentrerer også risiko. Det er avveiningen.

Legg ved policy-metadata til hver legitimasjon

Metadatamodellen bør være eksplisitt nok til at gatewayen kan avgjøre om en legitimasjon er kvalifisert før den berører et leverandørendepunkt.

En praktisk legitimasjon inkluderer:

• credential_id: intern uforanderlig identifikator.
• leverandør: OpenAI, Anthropic, Gemini, Azure OpenAI eller en annen adapter.
• provider_account_boundary: organisasjon, prosjekt, arbeidsområde, skyprosjekt, abonnement eller tilsvarende.
• credential_class: kjøretid, admin, fakturering, evaluering eller BYOK.
• miljø: produksjon, iscenesettelse, utvikling, evaluering, sandkasse.
• tenant_binding: delt plattformlegitimasjon, enkelt leietaker, leietakergruppe eller kunde BYOK-leier.
• allowed_model_families: for eksempel tekstgenerering, innebygging, visjon, bilde, lyd eller spesifikke modellprofiler.
• allowed_endpoints: normaliserte gateway-funksjoner kartlagt til leverandørens endepunkter.
• data_policy: tillatt oppbevaringsklasse, loggingsklasse, bostedskrav og funksjonsbegrensninger.
• budget_scope: kostnadssenter, forhandlerkunde, intern avdeling eller kontrakt.
• eier: navngitt team eller ansvarlig person.
• created_at, expires_at, rotation_due_at, last_used_at.
• health_status: ukjent, sunn, degradert, uautorisert, quota_exhausted, deaktivert.
• emergency_disable: umiddelbar ruteblokkering uavhengig av normal policytilstand.

Hold denne modellen leverandørnøytral, men ikke slett leverandørrealiteter. En antropisk arbeidsområde-bundet nøkkel og en Gemini-nøkkel knyttet til et Google Cloud-prosjekt er ikke utskiftbare bare fordi begge kan generere tekst. Gatewayen trenger den opprinnelsen for revisjoner, tilbakeføring og sikker failover.

Separat kjøretids-, admin- og faktureringstilgang

Den viktigste regelen er enkel: en nøkkel som brukes for kjøretidsslutning skal ikke administrere leverandørorganisasjoner, arbeidsområder, brukere, prosjekter eller administrative ressurser.

Kjøretidstrafikk er høyt volum og eksponert for den største operasjonelle overflaten. Den går gjennom forespørselsrutere, prøvelogikk på nytt, strømmebehandlere, modelladaptere og hendelsesarbeidsflyter. Administratorlegitimasjon er lavfrekvent og høy effekt. De bør leve bak en egen godkjenningsbane med korte TTL-er, kalt menneskelig godkjenning der det er hensiktsmessig, sterk logging og ingen kjøretidsruting.

Faktureringslegitimasjon fortjener også separasjon. En rapporteringsjobb som avstemmer fakturaer skal ikke kunne generere fullføringer, og en kjøretidsslutningsnøkkel skal ikke være den eneste måten å hente bruksrapporter på. Når en leverandør ikke tilbyr finmasket separasjon, kompenser i gatewayen: isoler legitimasjonen, begrens hvilken intern tjenesteidentitet som kan hente den, og logg hver bruk.

Anbefaling: gjør legitimasjonsklassen til en hard autorisasjonsgrense, ikke en etikett. En kjøretidskoordinator skal ikke kunne be om dekryptering for en administratorlegitimasjon selv om en konfigurasjonsfeil refererer til IDen.

Bygg en motor for valg av legitimasjon

Legitimasjonsvalg bør skje etter at gatewayen autentiserer nedstrømsoppringeren og før et forsøk fra leverandøranrop. Policymotoren bør slå sammen flere innganger:

• Leietaker-ID og nedstrøms API-nøkkelomfang.
• Forespurt modellprofil eller leverandørspesifikk modell-ID.
• Endepunktmulighet: chat, innebygging, bilde, lyd, batch, filer, verktøy eller adminautomatisering.
• Krav til datalagring og bosted.
• Budsjett, kredittreservasjon og kostnadssted.
• Satsgrensetilstand og kvotetrykk.
• Legitimasjonsmetadata, helse, miljø og binding av leietakere.

Motoren skal returnere ett av tre resultater: tillat med en valgt legitimasjon, avslå med en policy-årsak eller krever godkjenning. Avslag bør være presise nok til at driftsteam kan fikse problemet uten å avsløre hemmelig materiale til utviklere.

Eksempel på avgjørelse:

{
  "tenant_id": "tenant_42",
  "requested_profile": "fast-text-prod",
  "endpoint": "chat.completions",
  "data_policy": "no_prompt_logging",
  "credential_requirements": {
    "class": "runtime",
    "environment": "produksjon",
    "tenant_binding": "tenant_42",
    "allowed_model_family": "tekst",
    "health_status": "sunn"
  },
  "decision": "tillat",
  "credential_id": "cred_8f2...",
  "audit_reason": "Leier BYOK-legitimasjon samsvarer med kjøretidstekstprofil og datapolicy"
}

Ikke implementer fallback som «prøv neste nøkkel». Reservereaksjonen må kjøres på nytt. En delt plattformlegitimasjon kan være gyldig for leverandørtilgang, men ugyldig for en BYOK-kunde. En legitimasjon i et annet prosjekt kan ha kvote, men det kan være i strid med kostnadstilskriving eller oppbevaringskrav.

Håndter BYOK som leietakertilgang, ikke ledig kapasitet

BYOK endrer tillitsmodellen. Kunden oppga legitimasjonen slik at trafikken deres kan belastes, styres av eller isoleres innenfor leverandørkontoen. Denne legitimasjonen bør være bundet til kundens leietaker og leverandørkonto herkomst.

Anbefalte BYOK-kontroller:

• Én hvelvpost per kunde, leverandør, kontogrense og miljø.
• Ingen ruting på tvers av leietakere gjennom BYOK-legitimasjon.
• Ingen bruk som delt reservekapasitet med mindre kunden eksplisitt velger å delta.
• Kundesynlig helsetilstand som ikke avslører rånøkkelen.
• Separat rotasjonsarbeidsflyt som lar kunden legge til en erstatning før den gamle nøkkelen deaktiveres.
• Tydelig attribusjon i bruksanalyse og fakturaer: gateway-leietaker, leverandørkontogrense, legitimasjons-ID, modellprofil og forespørselssporings-ID.

For byråer, forhandlere og Partner API-automatisering kan BYOK være mer kompleks fordi en tjeneste kan levere leietakere og legitimasjon programmatisk. Den samme regelen gjelder fortsatt: automatisering kan importere og binde legitimasjon, men det bør ikke gjøre leietakers eierskap uskarpt.

Legg til helsesjekker før flyvningen uten å lekke forespørsler

En legitimasjon kan mislykkes av mange årsaker: tilbakekalt nøkkel, feil arbeidsområde, manglende modelltilgang, deaktivert fakturering, oppbrukt kvote, endepunktsbegrensning, regional policy-uoverensstemmelse eller leverandørbrudd. Å oppdage det først etter at en produksjonsforespørsel kommer, skaper støyende hendelser.

Bruk helsesjekker som validerer kapasitet uten å sende kundeforespørsler. En syntetisk sjekk kan kalle et minimalt endepunkt, liste tillatte modeller der det er hensiktsmessig, eller sende en ufarlig fast melding hvis det er det eneste praktiske alternativet. Hold disse sjekkene billige, takstbegrensede og merket som syntetisk trafikk i telemetri og fakturering.

Helsesjekker bør kjøres:

• Ved import av legitimasjon.
• Før du aktiverer en legitimasjon for produksjonsruting.
• Etter endringer i begrensninger på leverandørsiden.
• Under rotasjonsavskjæring.
• Periodisk for legitimasjon med produksjonskvalifisering.

Avveining: automatiserte sjekker fanger opp utløpte eller underomfangede nøkler tidlig, men dårlig utformede sjekker kan skape unødvendige leverandøranrop, faktureringsstøy eller falske alarmer under leverandøravbrudd. Lagre helseresultatet med tidsstempel, leverandørfeilklasse, testet endepunkt og testet modellfamilie. Ikke lagre hemmelige verdier eller sensitive meldinger.

Roter med to spor, ikke én risikabel erstatning

Rotering av legitimasjon bør ikke være en sletting-og-be-operasjon. Bruk en to-spors rotasjonsmodell:

1. Importer erstatningslegitimasjon som inaktiv, med fullstendige metadata og eier.
2. Kjør syntetiske helsesjekker for de tiltenkte endepunktene, modellfamiliene og kontogrensen.
3. Aktiver skyggekvalifisering for en liten del av sikker syntetisk trafikk eller trafikk med lav risiko der det er aktuelt.
4. Skift produksjonstrafikk gradvis fra gammel legitimasjon til ny legitimasjon.
5. Overvåk feil, ventetid, kvote og kostnadsattribusjon etter legitimasjons-ID.
6. Frys fallback til den gamle legitimasjonen når den nye legitimasjonen er stabil.
7. Ta tilbake den gamle legitimasjonen hos leverandøren og merk hvelvposten som opphevet.
8. Bekreft at ingen dekrypteringer eller leverandøranrop forekommer gjennom den gamle legitimasjonen etter tilbakekalling.

Rotasjonsfrister bør være synlige i driftsvisninger og varsler. Nødretasjon trenger en kortere vei: deaktiver legitimasjon, blokker ruting, aktiver godkjent erstatning og bevar alle revisjonsposter for hendelsesgjennomgang.