Kundanpassade AI API-nycklar: isolera hyresgäster, budgetar och missbruk utan spridning av leverantörsnyckel

När en produkt låter många kunder ringa AI-modeller är fel primitiv ofta uppströmsleverantörsnyckeln. En leverantörsnyckel representerar vanligtvis ett konto, projekt, arbetsyta eller tjänstekonto. Din produkt behöver något smalare: en kundvänd nyckel som identifierar en hyresgäst, kund, applikation, miljö, modellpolicy, budget och revisionsregel.

Det är syftet med kundanpassade AI API-nycklar. Gatewayen utfärdar nyckeln, autentiserar förfrågningar, tillämpar policy, mätareanvändning och ringer sedan uppströmsleverantörer med dolda referenser. Nedströmskunder får aldrig leverantörsnyckeln. De får ett stabilt kontrakt med din plattform.

Läsarproblem: Kundisolering utan ett leverantörsprojekt per kund

SaaS-byggare, byråer och återförsäljarplattformar behöver vanligtvis svara på praktiska frågor innan de kan avslöja AI-åtkomst nedströms:

• Vilken kund genererade denna användning?
• Vilken applikation, miljö eller integration gjorde samtalet?
• Vilka modeller och modaliteter är tillåtna?
• Hur mycket kan den här kunden spendera den här månaden?
• Vad händer om en nyckel läcker?
• Kan den här kunden stängas av utan att alla andra påverkas?
• Kan användning stämmas av mot leverantörsrapporter senare?

Projekt och arbetsytor på leverantörssidan kan hjälpa, men de är inte alltid rätt enhet för varje nedströmskund. Att skapa en uppströmsgräns per kund kan förbättra hård isolering och rapportering, men det skapar också administrationskostnader, kvotfragmentering, spridning av autentiseringsuppgifter och mer avstämningsarbete.

En gateway-utfärdad nyckel ger produkten en kontrollpunkt på kundnivå även när uppströms autentiseringsuppgifter slås samman. Det stöder också starkare lägen, som till exempel hyresgästbundna leverantörsuppgifter eller ta med din egen nyckel, när en kund behöver avtalsseparation, hemvistgränser eller direkt ägande av leverantörskonto.

Fakta, rekommendationer och förutsägelser

Fakta

• OpenAI-projekt stödjer medlemmar, tjänstekonton, API-nycklar, användningsgränser, budgetar och projektresurser med omfattning. Det gör projekt användbara som uppströmsgränser, men inte automatiskt till rätt primitiva för varje slutkund.
• OpenAI-användningsrapportering kan gruppera användning efter dimensioner som projekt, användare, API-nyckel, modell, batch och tjänstenivå. SaaS återkrav behöver fortfarande dessa leverantörsposter kopplade till produktägda kundidentifierare.
• Antropiska arbetsytor separerar API-resurser efter användningsfall, team, avdelning, projekt eller produkt. API-nycklar är knutna till arbetsytan där de skapas och kan inte flyttas mellan arbetsytor.
• Antropisk användning och kostnadsrapportering stöder gruppering efter API-nyckel, arbetsyta, modell, tjänstenivå, sammanhangsfönster, datauppehållstillstånd och hastighetsrelaterade alternativ, med kostnader som returneras i dagliga USD-hinkar.
• Google Gemini API-nyckelvägledning rekommenderar att nycklar begränsas, och Gemini API-nycklar är som standard begränsade till Generative Language API. Programbegränsningar som IP-adresser kan vara tillgängliga beroende på distributionsform.
• OWASP-vägledning behandlar API-nycklar som nödvändiga kontroller för skyddade slutpunkter och säger att nycklar ska återkallas när klienter bryter mot användningsavtal.
• Vägledning för OWASP-hemligheter betonar minsta privilegium, återkallande när hemligheter inte längre krävs eller äventyras och automatiserad rotation för att minska implementeringsfel.

Rekommendationer

• Använd gatewayutfärdade kundnycklar som policyhandtag, inte bara autentiseringstokens.
• Håll uppströmsleverantörsuppgifterna dolda för nedströmskunder.
• Skriv en gatewayanvändningsreskontra vid begäran innan du förlitar dig på leverantörsinstrumentpaneler.
• Använd leverantörsprojekt eller arbetsytor selektivt för kunder med hög risk, hög volym, reglerade, hemvistkänsliga eller avtalsmässigt separata kunder.
• Bygg nyckelrotation som ett överlappande arbetsflöde, inte som en omedelbar brotthändelse.

Förutsägelser

• Fler leverantörer kommer att exponera rikare användningsgruppering och budgetkontroller, men produktägd kundattribution kommer fortfarande att vara nödvändig för SaaS-fakturering och återförsäljarrapportering.
• Återförsäljare och byråplattformar kommer i allt högre grad att behandla gatewaynycklar som kommersiella objekt: kopplade till planer, kreditsaldon, omfattningar och supportarbetsflöden.
• Kunder med strikt efterlevnad eller upphandlingsbehov kommer att be om BYOK eller ägande av leverantörskonto, medan de flesta vanliga kunder föredrar ett managed gateway-kontrakt.

Gateway-nyckelobjektet

En nyckel med kundomfattning bör lösas till ett strukturerat policyobjekt. Modellera åtminstone nyckeln som mer än en hash och ett namn.

{
  "key_id": "key_01J9...",
  "tenant_id": "tenant_acme",
  "customer_id": "cust_4812","application_id": "app_support_bot",
  "environment": "produktion",
  "ägare": {
    "type": "service_account",
    "id": "svc_support_ai"
  },
  "model_profile_id": "profile_support_standard",
  "allowed_modalities": ["text", "image_input"],
  "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": "metadata_only",
  "status": "aktiv",
  "created_at": "2026-09-05T10:00:00Z",
  "last_used_at": null
}

De exakta fälten kommer att variera, men principen bör inte: varje inkommande förfrågan löser nyckeln till hyresgästpolicyn innan den skickas. Autentisering svarar "vem ringer?" Policyupplösning svarar "vad kan den här uppringaren göra, hur mycket kan de spendera, var kan förfrågan väga och vad måste loggas?"

Det är också här som semantisk produktstrategi är viktig. En plattform som säljer ett AI API för byråer kan behöva kund- och kampanjdimensioner. Ett utvecklarverktyg kan behöva arbetsyta och arkivdimensioner. En återförsäljare kan behöva externa kund-ID som matchar dess faktureringssystem.

Arbetsflöde för att skapa nyckel

Skapandet av nycklar bör vara tillräckligt deterministiskt för automatisering och tillräckligt strikt för säkerhetsgranskning.

1. Skapa kundposten först

Skapa inte föräldralösa nycklar. Nyckeln ska tillhöra en hyresgäst och ett kundregister innan den finns. För återförsäljarplattformar bör kundposten inkludera externa ID:n från återförsäljarens CRM- eller faktureringssystem, planmetadata, skatt- eller fakturagruppering vid behov och ett statusfält som kan spärra alla underordnade nycklar.

2. Bifoga en modellprofil

En modellprofil mappar kundvända modellnamn till leverantörsmodeller och möjligheter. Till exempel kan support-standard tillåta en balanserad textmodell, bildinmatning och ingen kodexekvering. research-premium kan tillåta modeller med långa sammanhang, webbsökning och högre tak per begäran.

Tvinga inte nedströmsapplikationer till hårdkodade leverantörsmodell-ID:n. Använd gatewayprofilen för att hantera tillgänglighet, reserv, prissättning och utfasning.

3. Ställ in utgifts- och skattegränser

Använd budgetar och prisgränser tillsammans. En månadsbudget förhindrar fakturaskador över tid. Prisgränser förhindrar plötslig missbruk, stormar igen eller oavsiktliga loopar från att förbruka hela budgeten på några minuter.

Användbara kontroller inkluderar:

• Månatlig kundbudget.
• Daglig mjuk keps för upptäckt av anomali.
• Fakta för begäranden per nyckel.
• Inmatnings- och utdatatokenhastighet.
• Högsta beräknade kostnad per begäran.
• Verktygsspecifika gränser för värdbaserad sökning, filbearbetning eller kodexekvering.

Budgettillämpning bör reservera beräknad kostnad före avsändning, reglera faktisk kostnad efter slutförande och frigöra oanvänd reserv. Detta kopplar nyckelpolicyn till AI API-fakturering istället för att behandla fakturering som en fördröjd rapporteringsuppgift.

4. Generera och lagra hemligheten på rätt sätt

Visa hemligheten i klartext en gång. Lagra endast en stark hash, plus ett kort prefix eller fingeravtryck för stödsökning. Prefixet hjälper supportteam att identifiera "nyckeln som slutar på 8F2A" utan att se hemligheten.

Ett typiskt lagringsmönster är:

• nyckel-id: stabil databasidentifierare.
• secret_hash: hash av hela hemligheten med ett lämpligt lösenord eller token-hash-strategi.
• secret_prefix: kort okänslig visningsprefix.
• fingeravtryck: deterministisk identifierare för granskningssökning.
• created_by: användare eller Partner API-klient som skapade nyckeln.
• status: aktiv, dränering, återkallad, karantän, utgången.

Lagra aldrig uppströmsleverantörsnycklar på kundnyckelobjektet. Leverantörsuppgifterna hör hemma i ett separat autentiseringsvalv med sina egna åtkomstregler.

Begäran-tidstillämpning

Gatewayen bör behandla varje modellanrop som ett policybeslut följt av ett leverantörsutskick. En praktisk sökväg för begäran ser ut så här:

1. Parse den presenterade gatewaynyckeln.
2. Slå upp nyckelhash och status.
3. Lös profil för hyresgäst, kund, applikation, miljö, ägare och modell.
4. Kontrollera om hyresgästen och kunden är aktiva.
5. Validera begärt modellalias, modalitet, verktyg, lagringsläge, region och tjänstenivå.
6. Uppskatta kostnaden för begäran och reservera budget.
7. Kontrollera hastighetsgränser och trösklar för missbruk.
8. Välj uppströms autentiseringsläge: poolad, klientbunden eller BYOK.
9. Skicka till leverantören.
10. Fånga användning, kostnad, leverantörsreferenser, fel och säkerhetssignaler.
11. Avgör budgetreservationen och skriv den sista redovisningshändelsen.

Denna sekvens håller gatewayen ansvarig för kundkontraktet. Leverantörsinstrumentpaneler blir avstämningsindata, inte den enda källan till sanning.

Användning av Ledger-fält som faktiskt hjälper senare

En gateway-reskontra bör bevara tillräckligt med detaljer för att besvara support-, fakturerings-, missbruks- och routingfrågor utan att kräva lagring av obearbetad prompt som standard.

Användbara fält inkluderar:

• request_id och trace_id.
• tenant_id, customer_id, application_id och key_id.
• Slutanvändaridentifierare, helst pseudonym där så är lämpligt.
• Modellalias efterfrågat av kunden.
• Lös uppströmsleverantör och modell.
• Indata, utdata, resonemang, cachad, ljud-, bild-, video- och verktygsanvändning där tillämpligt.
• Offert kostnad, reserverat belopp, avräknat kostnad, valuta och priskatalogversion.
• Providerbegäran-ID, användningsrapportreferens, projekt, arbetsyta eller API-nyckelgrupperingsdimension om tillgänglig.
• Lagringspolicy tillämpad.
• Koder för säkerhet, missbruk eller policybeslut.
• Felkategori och försök med metadata igen.

Den här strukturen stöder återkrav, kundsupport, incidentrespons och ett arbetsflöde för API-nyckelhantering som kan svara "vad gjorde den här nyckeln?" utan att exponera icke-närstående hyresgäster.

Autentiseringslägen: Pooled, Tenant-Bound och BYOK

Pooled leverantörsuppgifter

I standardläget går många kundnycklar genom en mindre uppsättning leverantörsuppgifter. Detta är operativt enkelt och minskar spridningen på leverantörssidan. Det fungerar när gatewayen har stark tillskrivning av hyresgäster, budgettillämpning, hastighetsbegränsning, missbruksisolering och cachegränskontroller.

Kompromissen är att rapportering på leverantörssidan endast kan visa gateway-uppgifterna eller leverantörsprojektet. Du måste koppla leverantörsposter tillbaka till gateway-reskontraposter för att producera fakturering och analyser på kundnivå.

Inloggningsuppgifter för hyresgästbundna leverantörer

För större eller mer riskfyllda hyresgäster, bind en hyresgäst till ett dedikerat leverantörsprojekt, arbetsyta, tjänstekonto eller nyckel. Detta ger en starkare uppströmsseparering och kan förenkla rapportering på leverantörssidan. Det kan också ge en hård kvot backstop om leverantören stöder gränser vid den gränsen.

Kostnaden är operationell komplexitet. Provisionering, rotation, leverantörsgränser, incidentrespons och avstämning sker nu över fler uppströmsobjekt.

Ta med din egen nyckel

BYOK kan vara användbart när kunder måste äga leverantörskontot, förhandla om sitt eget leverantörskontrakt eller hålla leverantörsfakturering separat. Gatewayen tillämpar fortfarande modellprofiler, routingpolicy, analyser och kontroller på applikationsnivå där det är möjligt.

Kompromissen är supportens komplexitet. Varje kunds leverantörskonto kan ha olika modellåtkomst, kvoter, prissättning, lagringsinställningar och incidentstatus. Gatewayen måste upptäcka och förklara dessa skillnader tydligt.

Återkallelse och karantän

Återkallelse bör blockera nya förfrågningar omedelbart för en kundnyckel utan att rotera orelaterade uppströmsleverantörsuppgifter. Detta är en av de största fördelarna med virtuella nycklar.

Använd separata tillstånd för olika operativa åtgärder:

• aktiv: förfrågningar är tillåtna.
• dränering: gammal nyckel accepteras under ett rotationsfönster, men varningar och granskningshändelser avges.
• återkallad: nya förfrågningar avvisas permanent.
• i karantän: nya förfrågningar blockeras på grund av missbruk, betalning, policy eller incidentrespons.
• förfallit: nyckeln har överskridit sin livslängd och måste bytas ut.

Karantän bör vara reversibel när incidenten är åtgärdad. Återkallelse bör vanligtvis inte vara reversibel, eftersom att återställa gamla hemligheter ökar förvirringen och risken.

När en nyckel bryter mot användningspolicyn, logga orsaken, aktören, tiden och omfattningen av tillämpningen. Om beslutet var automatiserat, bevara regelversionen och signalerna som utlöste det. Detta håller kundsamtal sakliga.

Rotation utan att bryta produktionen

Nyckelrotation bör använda ett arbetsflöde med två tangenter överlappande:

1. Skapa en ersättningsnyckel med samma kund, applikation, modellprofil och gränser om inte operatören ändrar dem avsiktligt.
2. Visa den nya hemligheten en gång.
3. Markera den gamla nyckeln som tömning.
4. Acceptera båda nycklarna under en begränsad period, till exempel 7, 14 eller 30 dagar beroende på kundplan och risk.
5. Skriv ut användningsvarningar på tömningsnyckeln.
6. Meddela ägaren eller Partner API-klienten när den gamla nyckeln fortfarande används nära deadline.
7. Återkalla den gamla nyckeln i slutet av fönstret.
8. Behåll tillskrivning över båda nyckel-id:n under samma kund och applikation.

Detta undviker det vanliga felläget där en säkerhetsförbättring blir ett produktionsavbrott. Rotation är fortfarande en kontroll, men det blir ett operativt arbetsflöde med bevis och deadlines.

Partner API-yta

Om nedströmsplattformar hanterar kunder programmatiskt, exponera nyckeloperationer via ett Partner API. API:et bör stödja idempotensnycklar och granskningshändelser eftersom provisionering ofta sker i fakturerings-, onboarding- eller CRM-arbetsflöden.

Minsta slutpunkter:

• POST /kunder: skapa eller upphäva en kund.
• POST /customers/{customer_id}/keys: skapa en nyckel.
• GET /customers/{customer_id}/keys: lista nycklar och statusar.
• PATCH /keys/{key_id}: uppdatera omfång, ägare, gränser, modellprofil eller status.
• POST /keys/{key_id}/rotate: skapa ersättning och markera gammal nyckel som dränering.
• POST /keys/{key_id}/revoke: återkalla omedelbart.
• GET /customers/{customer_id}/usage: returnera användning och kostnad efter tidsintervall, nyckel, app, modell eller slutanvändardimension.

Varje muterande begäran bör acceptera en idempotensnyckel. Varje ändring bör skriva en granskningshändelse med aktör, mål, före- och efterfält, käll-IP eller klientidentitet och skäl där det finns tillgängligt.

När ska man använda leverantörsprojekt eller arbetsytor

Behandla inte gatewaynycklar och leverantörsgränser som ömsesidigt uteslutande. De löser olika problem.

Använd gateway-nycklar för normal kontroll på kundnivå:

• Tillskrivning per kund.
• Nycklar per applikation.
• Budget- och prisgränser.
• Snabb avstängning.
• Rotationsarbetsflöden.
• Användningsanalys och återförsäljarrapportering.

Lägg till leverantörsprojekt, arbetsytor eller dedikerade leverantörsuppgifter när kunden behöver en starkare separation:

• Hög månatlig volym som förtjänar särskilda kvoter.
• Reglad arbetsbelastning med uttryckliga krav på bosättning eller kvarhållning.
• Skillnad av kontraktsfakturor.
• Hårda leverantörsbudgetar eller kvotstoppar.
• Särskilda gränser för övervakning av missbruk eller säkerhetsgranskning.
• Kundägda leverantörskonton via BYOK.

Den praktiska standarden är gateway-påtvingad isolering med selektiva uppströms hårda gränser. Det gör den gemensamma vägen enkel samtidigt som en eskaleringsväg bevaras för kunder som behöver mer separation.

Implementeringschecklista

• Definiera ett kundnyckelschema med hyresgäst, kund, applikation, miljö, ägare, modellprofil, gränser, retentionspolicy och status.
• Hasha hemligheter i vila och visa klartext bara en gång.
• Separera gatewaynycklar från uppströms lagring av leverantörsuppgifter.
• Lös varje begäran i policyn före avsändning.
• Reservera budget innan leverantören ringer och gör upp efter att slutanvändningen är känd.
• Registrera användning med kund, nyckel, modellalias, uppströmsmodell, tokenkategorier, verktygsanvändning, noterad kostnad, avräknad kostnad och leverantörsreferenser.
• Implementera aktiva, tömda, återkallade, karantänsatta och utgångna tillstånd.
• Stöd överlappning med två knappars rotation.
• Exponera Partner API-operationer med idempotensnycklar.
• Använd endast leverantörsprojekt eller arbetsytor där deras driftskostnad är motiverad.

Aktiv slutsats

Kundisolering för AI-åtkomst bör vanligtvis börja vid gatewaynyckeln, inte vid leverantörsnyckeln. Gatewaynyckeln är det kundinriktade kontraktet: det namnger hyresgästen, kunden, applikationen, modellprofilen, budgeten, prisgränsen, bevaranderegeln och revisionspolicyn. Leverantörsnyckeln är en implementeringsdetalj bakom det kontraktet.

Denna arkitektur ger SaaS-byggare och återförsäljarplattformar snabb återkallelse, korrekt tillskrivning, budgetar per kund, kontrollerad rotation och användbar användningsanalys utan att skapa ett uppströmsleverantörsprojekt för varje kund som standard. Använd uppströmsprojekt, arbetsytor, hyresgästbundna referenser eller BYOK när risken, volymen, bosättningen eller kontraktet kräver det. För den ordinarie sökvägen, framtvinga kundisolering i gatewayreskontran och policymotorn, och stämma sedan av leverantörsposter efteråt.

Relaterad läsning

• poäng