Kundebaserede AI API-nøgler: Isoler lejere, budgetter og misbrug uden udbyder-nøglespredning

De nøjagtige felter vil variere, men princippet bør ikke: hver indkommende anmodning løser nøglen til lejerpolitikken før afsendelse. Autentificering svarer "hvem ringer?" Politikopløsning svarer "hvad kan denne opkalder gøre, hvor meget kan de bruge, hvor kan anmodningen rute, og hvad skal logges?"

Det er også her, semantisk produktstrategi betyder noget. En platform, der sælger en AI API til bureauer, kan have behov for kunde- og kampagnedimensioner. Et udviklerværktøj kan have brug for arbejdsområde- og lagerdimensioner. En forhandler kan have brug for eksterne kunde-id'er, der matcher dens faktureringssystem.

Nøgleoprettelsesarbejdsgang

Nøgleoprettelse bør være deterministisk nok til automatisering og streng nok til sikkerhedsgennemgang.

1. Opret kundeposten først

Opret ikke forældreløse nøgler. Nøglen skal tilhøre en lejer og en kundejournal, før den findes. For forhandlerplatforme skal kunderegistreringen indeholde eksterne id'er fra forhandlerens CRM- eller faktureringssystem, planmetadata, skatte- eller fakturagruppering, hvis det er nødvendigt, og et statusfelt, der kan suspendere alle underordnede nøgler.

2. Vedhæft en modelprofil

En modelprofil kortlægger kundevendte modelnavne til udbydermodeller og -funktioner. For eksempel kan support-standard tillade en balanceret tekstmodel, billedinput og ingen kodeudførelse. research-premium tillader muligvis modeller med lang kontekst, websøgning og højere lofter pr. anmodning.

Tving ikke downstream-applikationer til hard-code-udbydermodel-id'er. Brug gateway-profilen til at administrere tilgængelighed, fallback, priser og udfasning.

3. Indstil forbrugs- og satsgrænser

Brug budgetter og satsgrænser sammen. Et månedligt budget forhindrer fakturaskader over tid. Satsgrænser forhindrer pludseligt misbrug, genforsøgsstorme eller utilsigtede sløjfer i at opbruge hele budgettet på få minutter.

Nyttige kontroller omfatter:

• Månedligt kundebudget.
• Daglig blød hætte til registrering af uregelmæssigheder.
• Anmodningshastighed pr. nøgle.
• Input- og outputtokenhastighed.
• Maksimal anslået pris pr. anmodning.
• Værktøjsspecifikke grænser for hostet søgning, filbehandling eller kodeudførelse.

Budgethåndhævelse bør reservere estimerede omkostninger før afsendelse, afregne faktiske omkostninger efter afslutning og frigive ubrugte reserver. Dette forbinder nøglepolitikken med AI API-fakturering i stedet for at behandle fakturering som en forsinket rapporteringsopgave.

4. Generer og gem hemmeligheden korrekt

Vis hemmeligheden i almindelig tekst én gang. Gem kun en stærk hash plus et kort præfiks eller fingeraftryk til supportopslag. Præfikset hjælper supportteams med at identificere "nøglen, der ender på 8F2A" uden at se hemmeligheden.

Et typisk lagermønster er:

• key_id: stabil database-id.
• secret_hash: hash af den fulde hemmelighed ved hjælp af en passende adgangskode eller token-hash-strategi.
• hemmeligt_præfiks: kort ikke-følsomt displaypræfiks.
• fingeraftryk: deterministisk identifikator for revisionsopslag.
• created_by: bruger eller Partner API-klient, der oprettede nøglen.
• status: aktiv, dræning, tilbagekaldt, karantæne, udløbet.

Opbevar aldrig opstrømsudbydernøgler på kundenøgleobjektet. Udbyderlegitimationsoplysninger hører hjemme i en separat legitimationsboks med sine egne adgangsregler.

Anmodningstidshåndhævelse

Gatewayen bør behandle hvert modelopkald som en politikbeslutning efterfulgt af en udbyderafsendelse. En praktisk anmodningssti ser sådan ud:

1. Parse den præsenterede gateway-nøgle.
2. Søg nøglehashen og status.
3. Løs lejer-, kunde-, applikations-, miljø-, ejer- og modelprofil.
4. Tjek, om lejer og kunde er aktive.
5. Valider den anmodede modelalias, modalitet, værktøjer, opbevaringstilstand, region og serviceniveau.
6. Estimer anmodningsomkostninger og reservebudget.
7. Tjek hastighedsgrænser og tærskler for misbrug.
8. Vælg opstrøms legitimationsoplysninger: samlet, lejer-bundet eller BYOK.
9. Send til udbyderen.
10. Fang brug, omkostninger, udbyderreferencer, fejl og sikkerhedssignaler.
11. Afgør budgetreservationen og skriv den endelige finansbegivenhed.

Denne sekvens holder gatewayen ansvarlig for kundekontrakten. Udbyder-dashboards bliver afstemningsinput, ikke den eneste kilde til sandhed.

Brug Ledger-felter, der faktisk hjælper senere

En gateway-reskontro skal bevare nok detaljer til at besvare spørgsmål om support, fakturering, misbrug og routing uden som standard at kræve rå promptlagring.

Nyttige felter omfatter:

• request_id og trace_id.
• tenant_id, customer_id, application_id og key_id.
• Slutbruger-id, helst pseudonym, hvor det er relevant.
• Modelalias anmodet af kunden.
• Løst upstream-udbyder og model.
• Input, output, ræsonnement, cachelagret, lyd, billede, video og brug af værktøj, hvor det er relevant.
• Anmeldt pris, reserveret beløb, afregnet pris, valuta og priskatalogversion.
• Udbyderanmodnings-id, brugsrapportreference, projekt, arbejdsområde eller API-nøglegrupperingsdimension, hvis tilgængelig.
• Opbevaringspolitik anvendt.
• Sikkerheds-, misbrugs- eller politikbeslutningskoder.
• Fejlkategori, og prøv metadata igen.

Denne struktur understøtter tilbageførsel, kundesupport, hændelsesrespons og en API-nøglestyring-workflow, der kan svare "hvad gjorde denne nøgle?" uden at afsløre ubeslægtede lejere.

Lederoplysninger: Pooled, Lejer-bundet og BYOK

Poolet udbyderoplysninger

I standardtilstanden ruter mange kundenøgler gennem et mindre sæt udbyderlegitimationsoplysninger. Dette er operativt enkelt og reducerer udbyderens sprawl. Det fungerer, når gatewayen har stærk lejertilskrivning, budgethåndhævelse, takstbegrænsning, misbrugsisolering og cache-grænsekontrol.

Afvejningen er, at rapportering på udbydersiden kun må vise gateway-legitimationsoplysningerne eller udbyderprojektet. Du skal samle udbyderregistreringer tilbage til gateway-reskontroposter for at producere fakturering og analyser på kundeniveau.

Lejer-bundet udbyder-legitimationsoplysninger

For større eller mere risikable lejere, bind en lejer til et dedikeret udbyderprojekt, arbejdsområde, servicekonto eller nøgle. Dette giver en stærkere opstrømsadskillelse og kan forenkle rapportering på udbydersiden. Det kan også give en hård kvote backstop, hvis udbyderen understøtter grænser ved den grænse.

Omkostningerne er operationel kompleksitet. Klargøring, rotation, udbydergrænser, hændelsesrespons og afstemning sker nu på tværs af mere upstream-objekter.

Medbring din egen nøgle

BYOK kan være nyttig, når kunder skal eje udbyderkontoen, forhandle deres egen udbyderkontrakt eller holde udbyderens fakturering adskilt. Gatewayen anvender stadig modelprofiler, routingpolitik, analyser og kontroller på applikationsniveau, hvor det er muligt.

Afvejningen er supportkompleksitet. Hver kundes udbyderkonto kan have forskellig modeladgang, kvoter, priser, opbevaringsindstillinger og hændelsesstatus. Gatewayen skal detektere og forklare disse forskelle klart.

Tilbagekaldelse og karantæne

Tilbagekaldelse bør straks blokere nye anmodninger om en kundenøgle uden at rotere ikke-relaterede upstream-udbyderlegitimationsoplysninger. Dette er en af de vigtigste fordele ved virtuelle nøgler.

Brug separate tilstande til forskellige operationelle handlinger:

• aktiv: anmodninger er tilladt.
• tømmer: gammel nøgle accepteres under et rotationsvindue, men advarsler og revisionshændelser udsendes.
• tilbagekaldt: nye anmodninger afvises permanent.
• karantæne: nye anmodninger blokeres på grund af misbrug, betaling, politik eller hændelsesreaktion.
• udløbet: Nøglen har overskredet sin levetid og skal udskiftes.

Karantæne bør være reversibel, når hændelsen er løst. Tilbagekaldelse bør normalt ikke være reversibel, fordi gendannelse af gamle hemmeligheder øger forvirring og risiko.

Når en nøgle overtræder brugspolitikken, skal du logge årsagen, aktøren, tidspunktet og omfanget af håndhævelsen. Hvis beslutningen var automatiseret, bevar regelversionen og signaler, der udløste den. Dette holder kundesamtaler faktuelle.

Rotation uden at bryde produktionen

Nøglerotation skal bruge en to-nøgles overlapningsarbejdsgang:

1. Opret en erstatningsnøgle med den samme kunde, applikation, modelprofil og begrænsninger, medmindre operatøren ændrer dem med vilje.
2. Vis den nye hemmelighed én gang.
3. Marker den gamle nøgle som tømmende.
4. Accepter begge nøgler i en begrænset periode, såsom 7, 14 eller 30 dage afhængigt af kundeplan og risiko.
5. Udgiv brugsadvarsler på aftapningsnøglen.
6. Giv ejeren eller Partner API-klienten besked, når den gamle nøgle stadig bruges tæt på deadline.
7. Tilbagekald den gamle nøgle i slutningen af vinduet.
8. Behold tilskrivning på tværs af begge nøgle-id'er under samme kunde og applikation.

Dette undgår den almindelige fejltilstand, hvor en sikkerhedsforbedring bliver en produktionsafbrydelse. Rotation er stadig en kontrol, men det bliver en operationel arbejdsgang med beviser og deadlines.

Partner API-overflade

Hvis downstream-platforme administrerer kunder programmatisk, skal du blotlægge nøgleoperationer gennem en Partner API. API'en bør understøtte idempotensnøgler og revisionsbegivenheder, fordi klargøring ofte sker inden for fakturering, onboarding eller CRM-arbejdsgange.

Minimum slutpunkter:

• POST /kunder: Opret eller opret en kunde.
• POST /customers/{customer_id}/keys: opret en nøgle.
• GET /customers/{customer_id}/keys: liste nøgler og statusser.
• PATCH /keys/{key_id}: Opdater omfang, ejer, begrænsninger, modelprofil eller status.
• POST /keys/{key_id}/rotate: Opret erstatning og marker gammel nøgle som drænende.
• POST /keys/{key_id}/revoke: tilbagekald straks.
• GET /customers/{customer_id}/usage: returner brug og pris efter tidsinterval, nøgle, app, model eller slutbrugerdimension.

Hver muterende anmodning bør acceptere en idempotensnøgle. Hver ændring skal skrive en revisionsbegivenhed med aktør, mål, før-og-efter-felter, kilde-IP eller klientidentitet og årsag, hvor det er tilgængeligt.

Hvornår skal du bruge udbyderprojekter eller arbejdsområder

Undgå at behandle gatewaynøgler og udbydergrænser som gensidigt udelukkende. De løser forskellige problemer.

Brug gateway-nøgler til normal kontrol på kundeniveau:

• Tilskrivning pr. kunde.
• Per-applikation nøgler.
• Budget- og satsgrænser.
• Hurtig suspension.
• Rotationsarbejdsgange.
• Brugsanalyse og forhandlerrapportering.

Tilføj udbyderprojekter, arbejdsområder eller dedikerede udbyderlegitimationsoplysninger, når kunden har brug for stærkere adskillelse:

• Høj månedlige volumen, der fortjener dedikerede kvoter.
• Regulerede arbejdsbelastninger med eksplicitte opholds- eller fastholdelseskrav.
• Kontraktmæssig fakturaadskillelse.
• Hårde udbydersidebudgetter eller -kvoter.
• Dedikeret misbrugsovervågning eller grænser for sikkerhedsgennemgang.
• Kundeejede udbyderkonti via BYOK.

Den praktiske standard er gateway-tvungen isolering med selektive opstrøms hårde grænser. Det holder den fælles vej enkel, samtidig med at en eskaleringssti bevares for kunder, der har brug for mere adskillelse.

Implementeringstjekliste

• Definer et kundenøgleskema med lejer, kunde, applikation, miljø, ejer, modelprofil, begrænsninger, opbevaringspolitik og status.
• Hash hemmeligheder i hvile og vis kun almindelig tekst én gang.
• Adskil gatewaynøgler fra opstrøms udbyderlegitimationslager.
• Løs hver anmodning i politikken før afsendelse.
• Reserver budget, før udbyderen ringer, og afgør, når den endelige brug er kendt.
• Registrer brug med kunde, nøgle, modelalias, opstrømsmodel, tokenkategorier, værktøjsbrug, angivne omkostninger, afregnet pris og udbyderreferencer.
• Implementer aktive, drænende, tilbagekaldte, karantæne- og udløbstilstande.
• Understøtter to-tasts rotation overlapning.
• Afslør Partner API-handlinger med idempotensnøgler.
• Brug kun udbyderprojekter eller -arbejdsområder, hvor deres driftsomkostninger er berettigede.

Aktiv konklusion

Kundeisolering for AI-adgang bør normalt starte ved gatewaynøglen, ikke ved udbydernøglen. Gatewaynøglen er den kundevendte kontrakt: den navngiver lejeren, kunden, applikationen, modelprofilen, budgettet, satsgrænsen, opbevaringsregelen og revisionspolitikken. Udbydernøglen er en implementeringsdetalje bag denne kontrakt.

Denne arkitektur giver SaaS-byggere og forhandlerplatforme hurtig tilbagekaldelse, nøjagtig tilskrivning, budgetter pr. kunde, kontrolleret rotation og nyttig brugsanalyse uden at oprette ét opstrømsudbyderprojekt for hver kunde som standard. Brug upstream-projekter, arbejdsområder, lejer-bundne legitimationsoplysninger eller BYOK, når risikoen, volumen, bopæl eller kontrakt kræver det. For den almindelige sti skal du håndhæve kundeisolering i gateway-reskontro- og politikmotoren, og derefter afstemme udbyderregistreringer bagefter.

Relateret læsning

• FAQ

  Ofte stillede spørgsmål

  Er kundespecifikke AI API-nøgler det samme som udbyder-API-nøgler?

  Nej. En nøgle med kundeomfang udstedes af gatewayen og knytter sig til produktejet politik: lejer, kunde, applikation, modelprofil, budget, takstgrænse, fastholdelse og revisionsregler. En udbyder-API-nøgle er en opstrøms-legitimationsoplysninger, der bruges af gatewayen til at kalde en modeludbyder.

  Skal hver kunde have et separat udbyderprojekt eller arbejdsområde?

  Normalt nej. Separate udbyderprojekter eller -arbejdsområder er nyttige for højrisiko-, højvolumen-, regulerede, bopælsfølsomme eller kontraktligt adskilte kunder. For almindelige kunder er gatewaynøgler med stærke regnskaber og håndhævelse af politikker enklere og mere fleksible.

  Hvordan skal lækkede kundenøgler håndteres?

  Bloker nye anmodninger ved at tilbagekalde eller sætte gatewaynøglen i karantæne med det samme, bevar revisionsregistreringer, opret en erstatningsnøgle, hvis det er relevant, og gennemgå nylig brug efter nøgle-id, kunde-id, applikations-id, model, pris og politiksignaler.

  Hvordan passer BYOK ind i denne model?

  BYOK lader en kunde levere udbyderejede legitimationsoplysninger, mens gatewayen stadig håndhæver applikationspolitik, brugsanalyse og routingkontroller, hvor det er muligt. Det reducerer udbyderens legitimationsoplysninger for platformen, men øger support- og afstemningskompleksiteten.