Udbyderlegitimationsbokse til multi-model AI-gateways: Separat kørselstid, admin, fakturering og BYOK-adgang

Downstream API-nøgler og upstream-udbyderlegitimationsoplysninger løser forskellige problemer. En udviklernøgle udstedt af din gateway identificerer app-, team-, lejer-, budget- og politikkonteksten. En upstream-udbydernøgle lader gatewayen bruge penge og få adgang til modeller på en udbyderkonto. At behandle dem som den samme slags hemmelighed er, hvordan teams ender med én ubegrænset nøgle i et delt projekt, admin-legitimationsoplysninger i runtime-tjenester og ingen pålidelig måde at svare på, hvilken lejer der forårsagede hvilken udbydersideafgift.

Det praktiske mønster er en udbyder-legitimationsboks: et dedikeret kontrolplan til import, klassificering, lagring, udvælgelse, rotation og revision af opstrøms-legitimationsoplysninger. Den skal sidde bag routeren, faktureringshovedbogen, policy-motoren og arbejdsprocessen – ikke inde i applikationskode, modelkonfigurationsfiler, lejerregistreringer eller analysehændelser.

Læserproblemet: Opstrøms legitimationsoplysninger bliver usynlig infrastruktur

De fleste implementeringer af flere modeller starter med et simpelt mål: rute en OpenAI-kompatibel anmodning til den bedst tilgængelige udbyder. Derefter vises flere konti: et udbyderprojekt til produktion, et andet til evaluering, et antropisk arbejdsområde til en forretningsenhed, et Google Cloud-projekt til Gemini og flere kundeleverede nøgler til BYOK-kontrakter.

Risikoen er ikke kun hemmelig lækage. Det er tab af autorisationskontekst. En gyldig udbydernøgle kan teknisk set være i stand til at kalde et slutpunkt, men gatewayen skal stadig vide, om denne nøgle er tilladt for denne lejer, denne modelfamilie, denne dataopbevaringspolitik, dette budget, denne region og denne automatiseringssti.

Faktum: udbyderplatforme afslører forskellige kontogrænser og legitimationstyper. OpenAI dokumenterer projekter og servicekonti, og servicekonto API-nøgletilladelser er som standard læse- og skriveadgang for projektets API-ressourcer. OpenAI eksponerer også Admin API-nøgleobjekter separat fra almindelig projekt/runtime API-brug. Anthropic dokumenterer arbejdsområder som en organisatorisk grænse og angiver, at Admin API-slutpunkter kræver Admin API-nøgler, der er forskellige fra standard API-nøgler; Anthropic bemærker også, at API-nøgler er knyttet til det arbejdsområde, hvor de er oprettet, og kan ikke flyttes mellem arbejdsområder. Googles Gemini API-nøgledokumentation siger, at hver Gemini API-nøgle er forbundet med et Google Cloud-projekt og anbefaler API-begrænsninger for at reducere skader, hvis en nøgle kompromitteres.

Anbefaling: opbyg ikke ét generisk "provider_key"-felt og kald det færdigt. Byg en legitimationsbeholdning, der bevarer udbyderspecifikke grænser, samtidig med at en normaliseret politikmodel eksponeres for gatewayen.

Definer en legitimationstaksonomi, før du accepterer nøgler

En boks bør afvise tvetydige legitimationsoplysninger. På importtidspunktet skal operatøren eller automatiseringsarbejdsgangen klassificere legitimationsoplysningerne. Brug som minimum disse kategorier:

• Runtime-inferens-legitimationsoplysninger: bruges af gatewayen til at kalde modelslutningsendepunkter såsom chat, svar, indlejringer, moderering, transskription eller billedgenerering, afhængigt af udbyderens support.
• Administratorautomatiseringslegitimationsoplysninger: bruges til at administrere organisationer på udbydersiden, arbejdsområder, projekter, brugere, nøgler eller administrative ressourcer. Disse bør aldrig være på runtime-anmodningsstien.
• Fakturerings- og rapporteringsoplysninger: bruges til at hente brugs-, fakturaer, omkostninger eller organisationsrapporter, hvor udbydere understøtter disse API'er. Hold dem adskilt fra slutningsnøgler, så rapporteringsjob ikke kan generere modelbrug.
• Kun evalueringslegitimationsoplysninger: bruges af benchmark-, QA-, migrerings- eller iscenesættelsesarbejdsgange. De bør have lave kvoter, tydelige miljømærker og ingen produktionsstøtteberettigelse.
• Kunde BYOK-legitimationsoplysninger: kundeleverede nøgler, der er bundet til en specifik lejer, udbyderkonto, kontrakt og datapolitik. De bør ikke samles i delt routing, medmindre kunden udtrykkeligt tilmelder sig.

Denne taksonomi er ikke kun dokumentation. Det skal drive adgangskontrol, routingberettigelse, advarsler og rotationsarbejdsgange. Hvis en legitimationsoplysninger importeres uden en kategori, ejer, udbyderkontogrænse og tilladt brug, bør den forblive deaktiveret.

Gem hemmeligheder i en boks, ikke i produktregistreringer

Hvælvingen bør være den eneste komponent, der kan dekryptere opstrøms legitimationsoplysninger. Andre systemer kan gemme referencer, hashes, statusfelter og politikmetadata, men ikke selve legitimationsværdien.

Opbevar ikke upstream-hemmeligheder på disse steder

• Lejerprofilrækker.
• Model routing-konfigurationsfiler.
• Spørg logfiler eller sporingsspænd.
• Analytics-begivenhedsnyttelast.
• Udviklervendte CI-variabler.
• Supportbilletter, chatværktøjer eller skærmbilleder.

Et brugbart hvælvingsdesign har to planer. Det hemmelige fly gemmer krypteret legitimationsmateriale og kontrollerer nøje dekrypteringsoperationer. metadataplanet gemmer ikke-hemmelige attributter, der bruges af routing og styring. Routeren skal normalt kun have brug for et legitimations-id og en kortvarig hemmelig hentning i hukommelsen ved afsendelsestidspunktet, ikke bred databaseadgang til hver udbydernøgle.

Beskyt hvælvingen som infrastruktur af høj værdi: konvolutkryptering eller administreret KMS, strenge serviceidentiteter, glasbrudsprocedurer, sikkerhedskopierings- og gendannelsestest, adgangsgennemgang og advarsler om usædvanlig dekrypteringsvolumen. En central boks forenkler styring, men den koncentrerer også risiko. Det er afvejningen.

Vedhæft politik-metadata til alle legitimationsoplysninger

Metadatamodellen skal være eksplicit nok til, at gatewayen kan afgøre, om en legitimationsoplysninger er kvalificeret, før den berører et udbyderslutpunkt.

En praktisk legitimationsoplysninger omfatter:

• credential_id: intern uforanderlig identifikator.
• udbyder: OpenAI, Anthropic, Gemini, Azure OpenAI eller en anden adapter.
• provider_account_boundary: organisation, projekt, arbejdsområde, cloud-projekt, abonnement eller tilsvarende.
• credential_class: runtime, admin, fakturering, evaluering eller BYOK.
• miljø: produktion, iscenesættelse, udvikling, evaluering, sandkasse.
• tenant_binding: delt platformslegitimationsoplysninger, enkelt lejer, lejergruppe eller kunde BYOK-lejer.
• allowed_model_families: for eksempel tekstgenerering, indlejringer, vision, billede, lyd eller specifikke modelprofiler.
• allowed_endpoints: normaliserede gateway-funktioner knyttet til udbyderens slutpunkter.
• data_policy: tilladt opbevaringsklasse, logningsklasse, opholdskrav og funktionsbegrænsninger.
• budget_scope: omkostningscenter, forhandlerkunde, intern afdeling eller kontrakt.
• ejer: navngivet team eller ansvarlig person.
• created_at, expires_at, rotation_due_at, last_used_at.
• health_status: ukendt, sund, degraderet, uautoriseret, quota_exhausted, disabled.
• emergency_disable: øjeblikkelig routingblok uafhængig af normal politiktilstand.

Hold denne model udbyderneutral, men slet ikke udbyderens realiteter. En antropisk arbejdsområdebundet nøgle og en Gemini-nøgle knyttet til et Google Cloud-projekt er ikke udskiftelige, bare fordi begge kan generere tekst. Gatewayen har brug for denne oprindelse til revisioner, tilbageførsel og sikker failover.

Separat runtime, admin og faktureringsadgang

Den vigtigste regel er enkel: En nøgle, der bruges til runtime-inferens, bør ikke administrere udbyderorganisationer, arbejdsområder, brugere, projekter eller administrative ressourcer.

Kørselstrafik er stor og udsat for den største operationelle overflade. Den passerer gennem anmodningsroutere, genforsøgslogik, streaminghandlere, modeladaptere og hændelsesarbejdsgange. Admin-legitimationsoplysninger er lav frekvens og høj effekt. De bør leve bag en separat godkendelsessti med korte TTL'er, navngivet menneskelig godkendelse, hvor det er relevant, stærk logning og ingen runtime routing berettigelse.

Faktureringsoplysningerne fortjener også adskillelse. Et rapporteringsjob, der afstemmer fakturaer, bør ikke kunne generere fuldførelser, og en runtime-inferensnøgle bør ikke være den eneste måde at hente brugsrapporter på. Når en udbyder ikke tilbyder finmasket adskillelse, skal du kompensere i gatewayen: isoler legitimationsoplysningerne, begræns hvilken intern tjenesteidentitet, der kan hente den, og log hver brug.

Anbefaling: Gør legitimationsklasse til en hård godkendelsesgrænse, ikke en etiket. En runtime dispatcher bør ikke være i stand til at anmode om dekryptering af en administratorlegitimationsoplysninger, selvom en konfigurationsfejl refererer til dens ID.

Byg en politikmotor til valg af legitimationsoplysninger

Valg af legitimationsoplysninger bør ske, efter at gatewayen godkender den downstream-opkaldende person, og før et udbyderopkald forsøges. Politikmotoren bør kombinere flere input:

• Lejer-id og downstream API-nøgleomfang.
• Anmodet modelprofil eller udbyderspecifikt model-id.
• Endepunktsfunktion: chat, indlejringer, billede, lyd, batch, filer, værktøjer eller administrationsautomatisering.
• Krav til dataopbevaring og ophold.
• Budget, kreditreservation og omkostningssted.
• Satsgrænsetilstand og kvotetryk.
• Ligitimationsmetadata, sundhed, miljø og binding af lejer.

Enheden skal returnere et af tre resultater: Tillad med en valgt legitimationsoplysninger, afvis med en politikårsag eller kræve godkendelse. Afvisninger bør være præcise nok til, at driftsteams kan løse problemet uden at afsløre hemmeligt materiale til udviklere.

Eksempel på beslutning: