LLM API Key Management for Teams: Isolation, Rotation, Spend Limits og Leak Response

Én delt LLM API-nøgle er praktisk indtil den første læk, uforklarlige regning eller produktionsafbrydelse. Det praktiske mål med API-nøglestyring er ikke kun at holde en legitimationshemmelighed. Det er for at begrænse sprængningsradius, tilskrive brug, rotere sikkert, opdage unormalt forbrug og tilbagekalde adgang uden at bryde urelaterede applikationer.

Denne vejledning giver teams en driftsmodel for LLM API-nøgler på tværs af udbydere, gateways, interne applikationer, bureauer og kundevendte produkter. Den adskiller bekræftede sikkerhedsfakta fra anbefalede implementeringsvalg og undgår at antage, at hver udbyder udsætter de samme kontroller.

Betjeningsmodellen: hver tast har brug for en grænse

En nyttig nøglestrategi starter med ét spørgsmål: hvad skulle fejle, hvis denne nøgle misbruges eller tilbagekaldes? Hvis svaret er "hele virksomheden", er nøglen for bred.

Fakta: OpenAI's API-nøglesikkerhedsvejledning anbefaler, at hvert teammedlem bruger en unik API-nøgle, siger, at deling af nøgler er imod dets brugsbetingelser, og anbefaler at tildele tilladelser til individuelle nøgler, hvor det understøttes. OpenAIs vejledning fraråder også at implementere API-nøgler i klientsidemiljøer såsom browsere eller mobilapps, fordi blotlagte nøgler kan misbruges til at fremsætte anmodninger på ejerens vegne.

Anbefaling: Opret nøgler omkring operationelle grænser, ikke omkring bekvemmelighed. Fælles grænser omfatter:

• Miljø: produktion, iscenesættelse, udvikling, sandkasse.
• Applikation: chatbot-backend, dokumentprocessor, kodningsassistent, analysearbejdsgang.
• Ejer: team, servicekonto, udvikler, bureauklient, lejer.
• Risikoniveau: offentligt vendt arbejdsgang, intern automatisering, batchjob, eksperimentel integration.
• Udbyder eller rute: opstrømsudbyder A, udbyder B, godkendt modelgruppe eller gateway-rute.

En god standard for et voksende team er: én produktionsnøgle pr. applikation eller service, én ikke-produktionsnøgle pr. miljø og separate nøgler til højrisikoautomatisering eller brug på kundeniveau. Agenturer og forhandlere bør foretrække virtuelle nøgler på kundeniveau frem for at dele opstrøms udbyderoplysninger.

Placer aldrig udbydernøgler i distribuerede klienter

Browsere, mobilapps, desktopudvidelser, offentlige plugins og kundesidescripts er fjendtlige steder for rå udbyderlegitimationsoplysninger. Selvom du slører nøglen, kan distribueret software inspiceres, kopieres eller opsnappes.

Faktum: OpenAI advarer eksplicit om ikke at implementere API-nøgler i klientsidemiljøer. Forskning i mobilapplikationer har også rapporteret vedvarende LLM API-legitimationsoplysninger i iOS-apps, hvilket understøtter den samme praktiske advarsel: legitimationsoplysninger indlejret i distribuerede klienter har en tendens til at undslippe.

Anbefaling: brug et backend- eller gatewaymønster:

1. Klienten autentificerer til din applikation ved hjælp af en brugersession, JWT, kundetoken eller kortvarig legitimationsoplysninger.
2. Din backend validerer brugeren, lejeren, planen og den anmodede operation.
3. Din backend eller AI API-gateway kalder opstrøms LLM-udbyderen ved hjælp af beskyttede loginoplysninger på serversiden.
4. Svaret returneres til klienten efter politikkontrol, logning og omkostningsregnskab.

Dette design giver dig mulighed for at håndhæve produktregler, før forbruget finder sted. For eksempel kan en bruger med gratis plan begrænses til mindre modeller, en betalt lejer kan modtage højere daglige kvoter, og en intern admin-workflow kan bruge en separat rute med strengere overvågning.

Byg et nøglelager, før du har brug for en hændelsesreaktion

Teams opdager ofte under en lækage, at ingen ved, hvilken tjeneste der ejer den synlige nøgle. Det er en opgørelsesfejl.

Fakta: OWASP API Security Top 10 2023 inkluderer ukorrekt lagerstyring som en stor API-sikkerhedsrisiko. For LLM-infrastruktur er nøglebeholdning en del af API-beholdning: du skal vide, hvilke legitimationsoplysninger der findes, hvad de har adgang til, og hvem der ejer dem.

Anbefaling: hver nøgle skal have metadata. Spor som minimum:

• Nøglenavn og intern nøgle-id.
• Ejerteam og nødkontakt.
• Miljø: produktion, iscenesættelse, udvikling, sandkasse.
• Formål: applikation, arbejdsgang, lejer, integration eller udviklerbrug.
• Tilladte udbydere, modeller, slutpunkter eller ruter, hvor de understøttes.
• Oprettet dato, sidst anvendte tidsstempel og planlagt gennemgangsdato.
• Forbrugsloft eller kvote.
• Rotationsstatus og linket implementeringskonfiguration.

Brug en navnekonvention, der forbliver læsbar i advarsler. For eksempel:

prod-supportbot-teamcx-gpt4class-2026q3stg-docprocessor-platform-lowcost-2026q3
lejer-acme-prod-standard-2026q3
dev-jlee-sandbox-2026q3

Det nøjagtige format betyder mindre end konsistens. Målet er, at en advarsel kan sige "tenant-acme-prod-standard overskred its daily threshold", og den ansvarlige ejer ved, hvad han skal gøre.

Anvend mindste privilegium, hvor platformen tillader det

Ikke alle udbydere eller gateways afslører identiske tilladelseskontroller, men princippet er konsekvent: en nøgle bør kun kunne gøre, hvad dens arbejdsbyrde har brug for.

Anbefaling: Begræns nøgler med en eller flere af følgende kontroller, hvor de understøttes:

• Projekt: binder nøgler til et projekt i stedet for en hel organisation.
• Model: tillad kun godkendte modeller; blokere dyre eller eksperimentelle modeller som standard.
• Slutpunkt: tillad fuldførelse af chat, men afvis ikke-relaterede administrative slutpunkter.
• Udbyderrute: tillad en gateway-rute i stedet for direkte adgang til alle opstrømsudbydere.
• Pris: begrænse anmodninger pr. minut eller samtidige anmodninger.
• Budget: håndhæv forbrugsgrænser pr. nøgle, pr. team eller pr. lejer.

For eksempel behøver en mellemstationsnøgle normalt ikke adgang til den dyreste produktionsmodel. En dokumentklassificeringsmedarbejder har sandsynligvis ikke brug for adgang til billedgenerering. En kundevendt lejernøgle bør ikke være i stand til at forbruge en anden lejers budget.

Design forbrugskontrol i lag

LLM API-sikkerhed og omkostningskontrol overlapper hinanden. En lækket nøgle opdages ofte som en faktureringsanomali, før den opdages som en sikkerhedshændelse.

Fakta: Sikkerhedsvejledning for OpenAI-konto anbefaler rimelige forbrugsgrænser og bemærkninger om, at separate API-nøgler kan gøre brugen nemmere at se efter funktion, team, produkt eller projekt. OpenAIs brugsrapportering understøtter også detaljeret analyse gennem felter som projekt-id, bruger-id, API-nøgle-id, model, batch og serviceniveau.

Anbefaling: Brug lagdelte grænser i stedet for én global grænse:

• Grænse pr. nøgle: forhindrer én login i at dræne hele budgettet.
• Grænse pr. team: holder afdelingsbrug synlig og ansvarlig.
• Grænse pr. lejer: isolerer kundebrug i SaaS- og bureauscenarier.
• Daglig anomaligrænse: udløser advarsler, når brugen afviger fra normale mønstre.
• Globalt nødstop: tillader hurtig afbrydelse, når misbrug er aktivt.

Hårde grænser er nyttige, men de kan afbryde lovlige batchjobs. Et mere sikkert produktionsmønster er en sekvens af kontroller:

1. Alarm ved 50 procent af det forventede daglige forbrug.
2. Eskalér med 80 procent.
3. Styr ikke-kritisk trafik med 100 procent.
4. Bloker kun den fornærmende nøgle, lejer eller rute, før du bruger en global nedlukning.

Afvejning: strenge budgetter reducerer faktureringsrisikoen, men kan skabe tilgængelighedsrisiko. Niveaugrænser efter arbejdsbyrde: interaktiv produktionstrafik, kundevendt betalt trafik, baggrundsjob, eksperimenter og udviklersandkasser bør ikke alle fejle på samme måde.

Spor brug efter nøgle og logisk aktør

En nøgle identificerer legitimationsoplysningerne. Den identificerer muligvis ikke den faktiske bruger, lejer, funktion eller arbejdsgang, der forårsagede anmodningen. Log både tekniske og forretningsmæssige dimensioner for at få nyttige analyser af AI-brug.

Anbefaling: Indsaml følgende felter for hver anmodning, hvor privatliv og politik tillader det:

• Anmod om ID og tidsstempel.
• API-nøgle-id eller virtuel nøgle-id.
• Applikations-, team-, lejer-, bruger- eller workflow-id.
• Udbyder, model, rute og serviceniveau.
• Prompt- og fuldførelsestokenantal eller tilsvarende brugsenheder.
• Anslået pris.
• Latency, statuskode, genforsøgstælling og fejlklasse.

Forvandl ikke observerbarhed af omkostninger til unødvendig dataindsamling. Undgå som standard at gemme fulde prompter, hvis de kan indeholde personlige data, kundehemmeligheder eller reguleret indhold. I mange tilfælde er hashed bruger-id'er, lejer-id'er, tokenantal og modelnavne nok til tilbageførsel og registrering af uregelmæssigheder.

Rotation uden nedetid: en sikker arbejdsgang

Faktum: NISTs nøglestyringsvejledning behandler nøglestyring som en livscyklusdisciplin, herunder generering, opbevaring, aktivering, rotation, suspension, tilbagekaldelse og destruktion. For LLM API-nøgler er rotation ikke en engangssikkerhedsopgave; det er en operationel arbejdsgang.

Anbefaling: brug denne rotationsproces uden nedetid:

1. Opret erstatningsnøglen. Match de nødvendige tilladelser, budget, rute og metadata. Tilbagekald ikke den gamle nøgle endnu.
2. Gem det i den hemmelige manager. Undgå lokale filer, chatbeskeder, billetter og indsatte miljøvariabler.
3. Implementer konfigurationen gradvist. Opdater én tjeneste, region, arbejdsgruppe eller lejersegment ad gangen.
4. Bekræft trafikbevægelse. Bekræft, at anmodninger ankommer under den nye nøgle, og at fejlfrekvenser og forsinkelser forbliver normale.
5. Frys skriver til den gamle nøgle. Stop nye implementeringer i at henvise til den.
6. Tilbagekald den gamle nøgle. Når trafikken er flyttet, skal du deaktivere den i stedet for at efterlade den som en glemt reserve.
7. Audit-stragglers. Søg i logfiler, implementeringsmanifester, hemmelige lagre, CI-variabler og runtime-fejl efter det gamle nøgle-id.

For programmer, der stadig bruger statiske miljøvariabler, vil rotation være skrøbelig. Gå mod dynamisk hemmelig indlæsning, centraliseret konfiguration eller gateway-administrerede virtuelle nøgler. Dokumenter som minimum, hvilken implementering der skal ændres før tilbagekaldelse.

Lækagesvar runbook

Når en nøgle lækker, er hastigheden vigtig. Svaret skal være skrevet før hændelsen, ikke improviseret i faktureringspanik.

Øjeblikkelig indeslutning

1. Tilbagekald eller suspender den synlige nøgle.
2. Hvis tilbagekaldelse ville bryde produktionen, skal du først udstede en erstatning og straks skifte kritisk trafik.
3. Bloker ruten, lejeren eller udbyderen, hvis misbrug stadig er aktivt.
4. Bevar logfiler, der er nødvendige for at identificere misbrug.

Undersøgelse

1. Identificer, hvor nøglen dukkede op: lager, frontend-pakke, mobilapp, logfil, supportbillet, leverandørværktøj eller chat.
2. Find den sidst kendte legitime brug.
3. Sammenlign brug før og efter mistanke om eksponering.
4. Gennemgå brugte modeller, anmod om volumen, pris, geografi, hvis de er tilgængelige, og usædvanlige statuskoder.
5. Tjek, om afhængige hemmeligheder eller tilstødende systemer også kan blive afsløret.

Genopretning og forebyggelse

1. Rotér afhængige legitimationsoplysninger, hvis det samme miljø kan have lækket mere end én hemmelighed.
2. Underret ejerteamet og berørte kundeinteressenter, når det er relevant.
3. Tilføj hemmelig scanning til repositories og CI-pipelines.
4. Forebyg gentagelse ved at flytte opkald på klientsiden bag en backend eller gateway.
5. Dokumenter hændelsens tidslinje, hovedårsagen, omkostningspåvirkning og kontrolforbedringer.

Forudsigelse: efterhånden som teams forbinder flere agenter, plugins, automatiseringsværktøjer og kundespecifikke arbejdsgange til LLM'er, vil nøglelækager i stigende grad ligne omkostningshændelser først og sikkerhedshændelser derefter. Teams med tilskrivning pr. nøgle og budgetkontrol vil løse dem hurtigere end teams, der bruger én delt legitimationsoplysninger.

Gateway-administrerede nøgler til teams med flere udbydere

Hvis din organisation bruger flere LLM-udbydere, kan direkte udbydernøgler skabe spredt styring: forskellige dashboards, forskellige faktureringsvisninger, forskellige tilladelsesmodeller og inkonsekvente rotationsprocesser.

Et gateway-administreret nøglelag kan forenkle dette ved at udstede applikationsvendte nøgler, mens opstrømsudbyderens legitimationsoplysninger holdes skjult. Applikationer kalder et OpenAI-kompatibelt API-slutpunkt, mens gatewayen håndterer routing, brugsanalyse, faktureringstilskrivning og håndhævelse af politikker.

Anbefaling: Overvej en gateway eller proxy-lag, når du har brug for:

• Et sted til at administrere teamnøgler på tværs af flere udbydere.
• Unified AI API-fakturering og forbrugsrapportering pr. nøgle.
• Virtuelle nøgler på kundeniveau til bureauer, forhandlere eller SaaS-lejere.
• Central model-tilladelseslister, rutepolitikker og suspendering i nødstilfælde.
• Brugstilskrivning efter lejer, funktion, arbejdsgang eller partnerkunde.

Afvejning: en gateway forbedrer styringen og skjuler upstream-legitimationsoplysninger, men den bliver en del af anmodningsstien. Overvåg det ligesom produktionsinfrastruktur: latenstid, tilgængelighed, fejlfrekvenser, kødannelse, genforsøgsadfærd og udbyderspecifikke fejl har alle betydning.

Implementeringstjekliste

• Erstat delte nøgler i hele organisationen med nøgler, der er omfattet af app, miljø, lejer eller arbejdsgang.
• Fjern rå udbydernøgler fra browsere, mobilapps, desktop-udvidelser og offentlige scripts.
• Ruter klientanmodninger gennem en backend eller AI API-gateway.
• Vedhæft ejer, formål, miljø, tilladte modeller, budget og gennemgå metadata til hver nøgle.
• Anvend mindste privilegier: projekt-, slutpunkt-, model-, rute-, pris- og budgetkontroller, hvor de er tilgængelige.
• Indstil pr. nøgle, pr. team, pr. lejer og globale forbrugsgrænser.
• Lognøgle-id, logisk aktør, model, tokenbrug, estimerede omkostninger, latenstid og statuskode.
• Opret en rotationsarbejdsgang uden nedetid, og test den før en nødsituation.
• Skriv en lækage-respons-runbog med indeslutnings-, undersøgelses- og forebyggelsestrin.
• Gennemgå inaktive nøgler, og tilbagekald alt uden en ejer eller nylig lovlig brug.

Aktiv konklusion

Start med den højeste risikonøgle: den, der bruges i produktionen, deles af flere personer, indlejret for mange steder eller er ansvarlig for det største forbrug. Giv det en ejer, opdel det efter grænse, tilføj et budget, flyt det bag en backend eller gateway, hvis kunderne kan se det, og dokumenter, hvordan det roteres.

Gentag derefter. Stærk LLM API nøglestyring er ikke en enkelt hemmelig opbevaringsbeslutning. Det er en livscyklus: beholdning, isolation, mindste privilegium, brugstilskrivning, omkostningskontrol, rotation og lækagerespons. Udbyttet er enkelt: Når noget går galt, bør kun én applikation, lejer eller arbejdsgang være i fare – ikke hele AI-budgettet.

Relateret læsning

• production og LLM-design
• href="https://model-gate.com/da/blog/article-2-2/">tidligere Model Gate-blogbemærkninger
• indledende Model Gate-artikel