Leverantörsreferensvalv för AI-gateways med flera modeller: Separat körtid, admin, fakturering och BYOK-åtkomst

Downstream-API-nycklar och uppströmsleverantörsuppgifter löser olika problem. En utvecklarnyckel utfärdad av din gateway identifierar app, team, hyresgäst, budget och policykontext. En uppströmsleverantörsnyckel låter gatewayen spendera pengar och få tillgång till modeller på ett leverantörskonto. Att behandla dessa som samma typ av hemlighet är hur team får en obegränsad nyckel i ett delat projekt, administratörsuppgifter i runtime-tjänster och inget tillförlitligt sätt att svara på vilken hyresgäst som orsakade vilken leverantörsavgift.

Det praktiska mönstret är ett leverantörsreferensvalv: ett dedikerat kontrollplan för att importera, klassificera, lagra, välja, rotera och granska uppströmsreferenser. Den ska sitta bakom routern, faktureringsreskontran, policymotorn och arbetsflödet – inte inuti programkod, modellkonfigurationsfiler, hyresgästposter eller analyshändelser.

Läsarproblemet: uppströms autentiseringsuppgifter blir osynlig infrastruktur

De flesta implementeringar av flera modeller börjar med ett enkelt mål: dirigera en OpenAI-kompatibel begäran till den bästa tillgängliga leverantören. Sedan dyker det upp fler konton: ett leverantörsprojekt för produktion, ett annat för utvärdering, en antropisk arbetsyta för en affärsenhet, ett Google Cloud-projekt för Gemini och flera kundlevererade nycklar för BYOK-kontrakt.

Risken är inte bara hemligt läckage. Det är förlust av auktorisationskontext. En giltig leverantörsnyckel kan tekniskt sett kunna anropa en slutpunkt, men gatewayen behöver fortfarande veta om den nyckeln är tillåten för den här hyresgästen, denna modellfamilj, denna datalagringspolicy, denna budget, denna region och denna automatiseringsväg.

Faktum: leverantörsplattformar exponerar olika kontogränser och autentiseringstyper. OpenAI dokumenterar projekt och tjänstekonton, och tjänstkontons API-nyckelbehörigheter är som standard läs- och skrivåtkomst för projektets API-resurser. OpenAI exponerar också Admin API-nyckelobjekt separat från vanlig projekt/runtime API-användning. Anthropic dokumenterar arbetsytor som en organisatorisk gräns och anger att Admin API-slutpunkter kräver Admin API-nycklar som skiljer sig från standard API-nycklar; Anthropic noterar också att API-nycklar är knutna till arbetsytan där de skapas och inte kan flyttas mellan arbetsytor. Googles Gemini API-nyckeldokumentation säger att varje Gemini API-nyckel är associerad med ett Google Cloud-projekt och rekommenderar API-begränsningar för att minska skadorna om en nyckel äventyras.

Rekommendation: bygg inte ett generiskt "provider_key"-fält och kalla det klart. Bygg en inloggningslista som bevarar leverantörsspecifika gränser samtidigt som du exponerar en normaliserad policymodell för gatewayen.

Definiera en autentiseringsklassificering innan du accepterar nycklar

Ett valv bör avvisa tvetydiga referenser. Vid importtillfället måste operatören eller automationsarbetsflödet klassificera autentiseringsuppgifterna. Använd åtminstone dessa kategorier:

• Runtime inferensreferenser: används av gatewayen för att anropa modellslutpunkter som chatt, svar, inbäddningar, moderering, transkription eller bildgenerering, beroende på leverantörens support.
• Autentiseringsuppgifter för administratörsautomatisering: används för att hantera organisationer på leverantörssidan, arbetsytor, projekt, användare, nycklar eller administrativa resurser. Dessa ska aldrig finnas på sökvägen för körningsförfrågan.
• Fakturerings- och rapporteringsuppgifter: används för att hämta användnings-, fakturor, kostnader eller organisationsrapporter där leverantörer stöder dessa API:er. Håll dem åtskilda från slutledningsnycklar så att rapporteringsjobb inte kan generera modellanvändning.
• Autentiseringsuppgifter endast för utvärdering: används av benchmark-, QA-, migrerings- eller iscensättningsarbetsflöden. De bör ha låga kvoter, tydliga miljömärkningar och ingen produktionsberättigande.
• Kundens BYOK-uppgifter: kundlevererade nycklar bundna till en specifik hyresgäst, leverantörskonto, kontrakt och datapolicy. De bör inte slås samman i delad routing om inte kunden uttryckligen väljer att delta.

Denna taxonomi är inte bara dokumentation. Det bör driva arbetsflöden för åtkomstkontroll, routingbehörighet, varningar och rotation. Om en autentiseringsinformation importeras utan en kategori, ägare, leverantörskontogräns och tillåten användning, bör den förbli inaktiverad.

Lagra hemligheter i ett valv, inte i produktregister

Valvet bör vara den enda komponenten som kan dekryptera uppströms autentiseringsuppgifter. Andra system kan lagra referenser, hash, statusfält och policymetadata, men inte själva autentiseringsvärdet.

Lagra inte uppströms hemligheter på dessa platser

• Rader för hyresgästprofiler.
• Konfigurationsfiler för modellrouting.
• Fråga loggar eller spårningsintervall.
• Analytics-händelsenyttolaster.
• Utvecklarorienterade CI-variabler.
• Supportbiljetter, chattverktyg eller skärmdumpar.

En användbar valvdesign har två plan. Det hemliga planet lagrar krypterat autentiseringsmaterial och kontrollerar noggrant dekrypteringsoperationer. metadataplanet lagrar icke-hemliga attribut som används av routing och styrning. Routern ska vanligtvis bara behöva ett autentiserings-ID och en kortvarig hemlig hämtning i minnet vid leveranstid, inte bred databasåtkomst till varje leverantörsnyckel.

Skydda valvet som en högvärdig infrastruktur: kuvertkryptering eller hanterad KMS, strikta tjänsteidentiteter, brytande procedurer, säkerhetskopierings- och återställningstestning, åtkomstgranskning och varning om ovanlig dekrypteringsvolym. Ett centralt valv förenklar styrningen, men det koncentrerar också risken. Det är avvägningen.

Bifoga policymetadata till alla autentiseringsuppgifter

Metadatamodellen bör vara tillräckligt tydlig för att gatewayen kan avgöra om en referens är kvalificerad innan den rör en leverantörsändpunkt.

En praktisk referenspost inkluderar:

• credential_id: intern oföränderlig identifierare.
• leverantör: OpenAI, Anthropic, Gemini, Azure OpenAI eller annan adapter.
• provider_account_boundary: organisation, projekt, arbetsyta, molnprojekt, prenumeration eller motsvarande.
• credential_class: körtid, admin, fakturering, utvärdering eller BYOK.
• miljö: produktion, iscensättning, utveckling, utvärdering, sandlåda.
• tenant_binding: delad plattformsuppgifter, enskild hyresgäst, hyresgästgrupp eller kund BYOK-hyresgäst.
• allowed_model_families: till exempel textgenerering, inbäddningar, vision, bild, ljud eller specifika modellprofiler.
• allowed_endpoints: normaliserade gateway-funktioner mappade till leverantörens slutpunkter.
• data_policy: tillåten lagringsklass, loggningsklass, uppehållskrav och funktionsbegränsningar.
• budget_scope: kostnadsställe, återförsäljarkund, intern avdelning eller kontrakt.
• ägare: namngivet team eller ansvarig person.
• created_at, expires_at, rotation_due_at, last_used_at.
• health_status: okänd, frisk, degraderad, obehörig, quota_exhausted, disabled.
• emergency_disable: omedelbart routingblock oberoende av normal policytillstånd.

Håll den här modellen leverantörsneutral, men radera inte leverantörsverkligheten. En antropisk arbetsyta-bunden nyckel och en Gemini-nyckel kopplade till ett Google Cloud-projekt är inte utbytbara bara för att båda kan generera text. Gatewayen behöver det här ursprunget för revisioner, återkrav och säker failover.

Separat körtid, admin och faktureringsåtkomst

Den viktigaste regeln är enkel: en nyckel som används för körtidsinferens ska inte hantera leverantörsorganisationer, arbetsytor, användare, projekt eller administrativa resurser.

Körtidstrafik är hög volym och exponerad för den största operativa ytan. Den går igenom förfrågningsroutrar, försök igen, strömningshanterare, modelladaptrar och incidentarbetsflöden. Administratörsuppgifterna är lågfrekventa och har stor effekt. De bör leva bakom en separat godkännandesökväg med korta TTL:er, namngivna mänskligt godkännande där så är lämpligt, stark loggning och ingen körtidskvalificering.

Faktureringsuppgifterna förtjänar också separation. Ett rapporteringsjobb som stämmer av fakturor bör inte kunna generera slutföranden, och en körtidsinferensnyckel bör inte vara det enda sättet att hämta användningsrapporter. När en leverantör inte erbjuder finkornig separation, kompensera i gatewayen: isolera autentiseringsuppgifterna, begränsa vilken intern tjänsteidentitet som kan hämta den och logga varje användning.

Rekommendation: gör behörighetsklass till en hård behörighetsgräns, inte en etikett. En körningssamordnare ska inte kunna begära dekryptering för en administratörsuppgifter även om ett konfigurationsfel refererar till dess ID.

Skapa en policymotor för behörighetsval

Val av autentiseringsuppgifter bör ske efter att gatewayen autentiserat nedströmsuppringaren och innan något leverantörssamtal görs. Policymotorn bör sammanfoga flera ingångar:

• Tenant ID och nedströms API-nyckelomfång.
• Begärd modellprofil eller leverantörsspecifikt modell-ID.
• Slutpunktskapacitet: chatt, inbäddningar, bild, ljud, batch, filer, verktyg eller administratörsautomatisering.
• Krav på datalagring och bosättning.
• Budget, kreditreservation och kostnadsställe.
• Taxegränstillstånd och kvottryck.
• Inloggningsmetadata, hälsa, miljö och bindning av hyresgäster.

Motorn bör returnera ett av tre resultat: tillåt med en vald referens, neka med ett policyskäl eller kräva godkännande. Avslag bör vara tillräckligt exakta för att driftsteam ska kunna åtgärda problemet utan att avslöja hemligt material för utvecklare.

Exempelbeslut:

{
  "tenant_id": "tenant_42",
  "requested_profile": "snabb-text-prod",
  "endpoint": "chat.completions",
  "data_policy": "no_prompt_logging",
  "credential_requirements": {
    "class": "runtime",
    "environment": "produktion",
    "tenant_binding": "tenant_42",
    "allowed_model_family": "text",
    "health_status": "frisk"
  },
  "decision": "tillåt",
  "credential_id": "cred_8f2...",
  "audit_reason": "hyresgästens BYOK-uppgifter matchar körtidstextprofil och datapolicy"
}

Implementera inte reserv som "försök med nästa nyckel." Reservprincipen måste köras igen. En delad plattformsuppgifter kan vara giltiga för leverantörsåtkomst men ogiltig för en BYOK-kund. En referens i ett annat projekt kan ha kvot, men det kan bryta mot kostnadstillskrivning eller lagringskrav.

Hantera BYOK som bostadsrättsägd åtkomst, inte reservkapacitet

BYOK ändrar förtroendemodellen. Kunden lämnade inloggningsuppgifterna så att deras trafik kan debiteras, styras av eller isoleras inom deras leverantörskonto. Den referensen bör vara bunden till kundens hyresgäst och leverantörskontots ursprung.

Rekommenderade BYOK-kontroller:

• En valvpost per kund, leverantör, kontogräns och miljö.
• Ingen routing mellan klienter via BYOK-uppgifter.
• Ingen användning som delad reservkapacitet om inte kunden uttryckligen väljer att delta.
• Kundsynligt hälsotillstånd som inte avslöjar rånyckeln.
• Separat rotationsarbetsflöde som gör att kunden kan lägga till en ersättning innan den gamla nyckeln inaktiveras.
• Tydlig attribution i användningsanalyser och fakturor: gateway-hyresgäst, leverantörskontogräns, autentiserings-ID, modellprofil och spårnings-ID för begäran.

För byråer, återförsäljare och Partner API-automatisering kan BYOK vara mer komplex eftersom en tjänst kan tillhandahålla hyresgäster och autentiseringsuppgifter programmatiskt. Samma regel gäller fortfarande: automatisering kan importera och binda autentiseringsuppgifter, men det bör inte sudda ut hyresgästernas ägande.

Lägg till hälsokontroller före flygning utan att läcka uppmaningar

En autentiseringsinformation kan misslyckas av många anledningar: återkallad nyckel, fel arbetsyta, saknad modellåtkomst, inaktiverad fakturering, slutpunktsbegränsning, regional policyfelmatchning eller leverantörsavbrott. Att upptäcka det först efter att en produktionsförfrågan har kommit fram skapar bullriga incidenter.

Använd hälsokontroller som validerar kapacitet utan att skicka kundmeddelanden. En syntetisk kontroll kan kalla en minimal endpoint, lista tillåtna modeller där så är lämpligt, eller skicka en ofarlig fast prompt om det är det enda praktiska alternativet. Håll dessa kontroller billiga, satsbegränsade och märkta som syntetisk trafik i telemetri och fakturering.

Hälsokontroller bör köras:

• Vid import av autentiseringsuppgifter.
• Innan du aktiverar en autentiseringsinformation för produktionsdirigering.
• Efter ändringar av begränsningar på leverantörssidan.
• Under rotationsbrytning.
• Med jämna mellanrum för autentiseringsuppgifter med produktionsberättigande.

Avvägning: automatiska kontroller fångar utgångna eller underomfattade nycklar tidigt, men dåligt utformade kontroller kan skapa onödiga leverantörssamtal, faktureringsljud eller falska larm under leverantörsavbrott. Lagra hälsoresultatet med tidsstämpel, leverantörsfelklass, testad slutpunkt och testad modellfamilj. Lagra inte hemliga värden eller känsliga uppmaningar.

Rotera med två platser, inte en riskabel ersättning

Rotering av autentiseringsuppgifter bör inte vara en radera-och-be-operation. Använd en modell med två luckor:

1. Importera ersättningsuppgifter som inaktivt, med fullständig metadata och ägare.
2. Kör syntetiska hälsokontroller för de avsedda slutpunkterna, modellfamiljerna och kontogränsen.
3. Aktivera skuggkvalificering för en liten del av säker syntetisk trafik eller trafik med låg risk där så är lämpligt.
4. Förskjut produktionstrafiken gradvis från gamla referenser till nya referenser.
5. Övervaka fel, latens, kvot och kostnadstillskrivning efter autentiserings-ID.
6. Frysta reserv till den gamla användarinformationen när den nya användarinformationen är stabil.
7. Återkalla den gamla legitimationen hos leverantören och markera valvposten som återkallad.
8. Verifiera att inga dekrypterar eller leverantörssamtal sker via den gamla autentiseringsinformationen efter återkallelse.

Deadlines för rotation bör vara synliga i driftvyer och varningar. Nödrotation behöver en kortare väg: inaktivera autentiseringsuppgifter, blockera routing, aktivera godkänd ersättning och bevara alla revisionsposter för incidentgranskning.

Begränsa leverantörsnycklar där leverantören stöder det

Gatewaypolicy är nödvändig, men begränsningar på leverantörssidan minskar sprängradien om en nyckel äventyras eller missbrukas. För Gemini och andra API-nycklar för molnplattformar, använd API/tjänstrestriktioner och lämpliga programbegränsningar där sådana finns. För leverantörsprojekt, arbetsytor och tjänstekonton, undvik omfattande organisatoriska privilegier när det räcker med en projektomfattad runtime-nyckel.

Rekommendation: upprätthåll en checklista för begränsningar på leverantörssidan för varje behörighetsklass. Checklistan bör vara en del av importgodkännande och rotationsgodkännande, inte en separat säkerhetsuppgift som kan hoppa över under press.

Avvägning: Restriktioner på leverantörssidan lägger till driftskostnader. Nya slutpunkter, modellfamiljer, regioner eller automationsfunktioner kan kräva policy- och begränsningsändringar. Det är att föredra framför att upptäcka efter en läcka att en nyckel kan komma åt varje arbetsbelastning i ett delat projekt.

Håll en granskningslogg för autentiseringsuppgifter som endast kan läggas till

Ett granskningsspår bör ge svar på vem som importerade en referens, vad den fick göra, vilka routingbeslut som valde den, när den misslyckades och när den roterades eller återkallades.

Logga dessa händelser:

• Autentiseringsuppgifter skapade eller importerade.
• Metadata har ändrats, inklusive tillåtna slutpunkter, klientbindning eller datapolicy.
• Hälsokontroll utförd och resultat registrerat.
• Autentiseringsuppgifter har valts av routingpolicy för en begäran.
• Avkryptering av autentiseringsuppgifter begärd av en intern tjänstidentitet.
• Providersamtal misslyckades på grund av autentisering, auktorisering, kvot eller begränsningsfel.
• Rotation startade, trafiken ändrades, gamla autentiseringsuppgifter återkallades.
• Nödavaktivering aktiverad eller avmarkerad.
• Autentiseringsuppgifter för administratör eller break-glass.

Placera inte råa autentiseringsvärden i granskningshändelser. Använd autentiserings-ID:n, leverantörskontogränser, begärande spårnings-ID:n, aktörsidentiteter och skäl för policybeslut. För körtidstrafik med stora volymer kan du ta prov på detaljerad dekrypteringstelemetri, men val av rutt och kostnadstillskrivning bör förbli tillräckligt fullständiga för fakturering och incidentrespons.

Checklista för implementering

• Skapa en autentiseringsklassificering och avvisa oklassificerade importer.
• Flytta alla leverantörshemligheter till ett dedikerat krypterat valv.
• Lagra routingmetadata separat från hemligt material.
• Gör runtime-, admin-, fakturerings-, utvärderings- och BYOK-inloggningsuppgifter separata behörighetsklasser.
• Bind BYOK-uppgifter till hyresgäst- och leverantörskontots ursprung.
• Kräv godkännande från policymotorn innan du väljer uppströmsuppgifter.
• Kör snabba hälsokontroller innan produktionen är kvalificerad.
• Använd rotation med två platser med gradvis trafikförskjutning och återkallelse från leverantörssidan.
• Tillämpa begränsningar på leverantörssidan där det är möjligt.
• Underhåll granskningsloggar för import, användning, fel, rotation och återkallelse.
• Håll administratörsuppgifter bakom glasögonkontroller: kort TTL, namngiven godkännande, stark loggning, ingen körningstid.

Aktiv slutsats

Börja med att inventera alla uppströmsleverantörsuppgifter som för närvarande används av gatewayen, skript, CI-jobb, utvärderingsledningar och partnerautomatisering. Tilldela var och en en klass, ägare, leverantörskontogräns, hyresgästbindning, tillåtna slutpunkter, tillåtna modellfamiljer, rotationsdeadline och nödlägesinaktiveringsstatus. Allt du inte kan klassificera bör inaktiveras eller sättas i karantän tills det har ett tydligt syfte.

Använd sedan en arkitektonisk regel: nedströmsutvecklare får gateway-omfattade nycklar; Enbart gatewayen styr uppströms leverantörsåtkomst. Den separationen låter dig bevara minsta privilegium, hyresgästtillskrivning, faktureringsnoggrannhet, datapolicy routing och säker automatisering även när leverantörer, projekt, arbetsytor och BYOK-kunder förökar sig.

Relaterad läsning

• team-facing API-nyckelhantering och läckagesvar
• data-retention-aware routingpolicyer
• FAQ

  Vanliga frågor

  Bör leverantörsuppgifter lagras i hyresgästregister?

  Nej. Förvara det krypterade autentiseringsmaterialet i ett dedikerat valv. Hyresgästposter kan referera till ett autentiserings-ID och policymetadata, men de bör inte innehålla uppströmsleverantörshemligheter.

  Kan en leverantörsnyckel användas för både körtidsinferens och adminautomatisering?

  Undvik det. Runtime-nycklar exponeras för sökvägar för höga volymer, medan administratörsnycklar kan ändra organisation, arbetsyta eller projektresurser. Separera dem med olika behörighetsklasser, tjänsteidentiteter, godkännanden och revisionsspår.

  Hur ska BYOK-referenser hanteras i en multi-tenant gateway?

  Bind varje BYOK-referens till kundens hyresgäst, leverantörskontogräns, miljö och tillåten användning. Använd inte kundlevererade nycklar som delad reservkapacitet om inte kunden uttryckligen väljer att delta.

  Vad är det säkraste sättet att rotera uppströmsleverantörsnycklar?

  Använd en process med två luckor: importera ersättningen som inaktiv, kör hälsokontroller, skift gradvis trafik, övervaka fel och kostnadstillskrivning, återkalla den gamla leverantörsuppgifterna och verifiera att ingen trafik fortfarande använder den.