Glömda API-nycklar: så återkallar du dem utan att stoppa tjänsten

En intern granskning hos OpenRouter hittade över 1 000 aktiva API-nycklar hos 85 medarbetare; 168 nycklar hade enligt företaget inte använts på flera månader. Det här är siffror från OpenRouters egen granskning, inte en oberoende branschstudie. Men även som ett enskilt exempel visar de en välbekant teknisk fälla: det går att glömma en nyckel, men inte nödvändigtvis applikationen som är beroende av den. Företaget daterade tillkännagivandet av Security Center till den 28 september 2026.

Problemet handlar inte bara om att hitta den äldsta autentiseringsuppgiften och radera den. Teamet måste identifiera ägaren, ta reda på var nyckeln används och förstå hur den kan ersättas utan att slå ut ett sällan kört jobb eller en bortglömd tjänst. Utan den informationen blir återkallandet av åtkomst ett riskabelt experiment i stället för en utrensning.

Vad Security Center visar – och vad det inte bevisar

Enligt OpenRouters beskrivning samlar Security Center nycklarna på kontot och visar ägare, senaste användning, utgiftsgräns och utgångsdatum. Organisationens administratörer kan se alla nycklar, medan medlemmar kan se nycklar de själva har skapat. För massåtgärder kan man välja upp till 500 nycklar och inaktivera, arkivera eller ange en utgiftsgräns för dem. Inaktivering går att ångra, arkivering gör det inte. Det här är egenskaper hos verktyget enligt leverantören själv, inte en oberoende bedömning av hur effektivt det är.

Det är särskilt viktigt att tolka statusen ”kan tas bort” som en uppmaning att granska, inte som ett bevis på att inga beroenden finns. Användningsmåttet visar tidigare anrop, men förklarar inte nödvändigtvis vilket schemalagt jobb, reservscenario eller säsongsberoende förlopp nyckeln hör till. OpenRouter rekommenderar självt att ägaren bekräftar borttagningen; dokumentationen om säkerhetsinställningar varnar också för att kontrollera beroenden före inaktivering eller arkivering.

Det finns en särskild reservation kring nätverksbegränsningar: IP-allowlist är tillgänglig för administratörer med Enterprise-abonnemang och gäller alla organisationens nycklar. Anrop från adresser utanför listan avvisas med fel 403, och ändringarna börjar gälla omedelbart. Innan begränsningen aktiveras bör du därför ta hänsyn till adresser för produktionsservrar, kontorsnätverk och CI-körmiljöer; annars kan själva skyddsåtgärden avbryta legitima anrop.

Rensa i rätt ordning: ägaren först, återkallandet sedan

1. Skapa en förteckning. Notera ägare, syfte, miljö, användare, utgiftsgräns och utgångsdatum för varje nyckel. Om systemet bara visar en person som ägare bör du också utse ett team eller en tjänst som tar över ansvaret om personen slutar.
2. Kontrollera användning och beroenden. Jämför tidpunkten för det senaste anropet med scheman för bakgrundsjobb, reservscenarier, releasepipelines och externa integrationer. Brist på nylig aktivitet är ett skäl att fråga ägaren, inte tillräcklig grund för att genast radera nyckeln.
3. Minska risken före migreringen. Där det stöds bör du ange en rimlig utgiftsgräns och ett utgångsdatum. Följ principen om minsta behörighet och reglerna för hemligheter: OWASP:s vägledning om hantering av hemligheter behandlar inventering, åtkomst och autentiseringsuppgifters livscykel som separata delar av processen.
4. Skapa en ersättare och flytta användarna. Uppdatera hemligheten i hemlighetslagringen eller distributionskonfigurationen och flytta sedan över applikationerna stegvis. Klistra inte in nyckelvärdet i ärenden, loggar eller källkod.
5. Verifiera produktionen före återkallandet. Kontrollera att den nya nyckeln fungerar för alla kända användare, inklusive CI och sällan körda jobb. Inaktivera sedan den gamla nyckeln först, om det finns ett reversibelt alternativ; arkivera eller radera den efter att migreringen bekräftats och den överenskomna observationsperioden har passerat.

Ordningen ”skapa en ny nyckel → flytta applikationerna → kontrollera att allt fungerar → ta bort den gamla” överensstämmer med OpenRouters instruktioner för nyckelrotation. Det är en rekommenderad ordning, inte en garanti för att undvika avbrott: resultatet beror på om du har hittat alla system som använder autentiseringsuppgiften.

Tjänstenycklar är inte organisationens alla hemligheter

En viss leverantörs kontrollpanel hjälper till att hantera nycklar för den tjänsten, men centraliserar inte i sig hemligheter från molnet, databaser, CI/CD och andra API:er. OWASP:s allmänna rekommendationer för hemligheters livscykel omfattar centraliserad lagring, åtkomstkontroll, granskning, rotation och återkallande. Googles rekommendationer för Google Cloud föreslår också att begränsa nycklarnas användningsområde, ta bort onödiga autentiseringsuppgifter och följa upp användningen.

OpenRouter hävdar också att Security Center använder nyckelmetadata, utgifter och utgångsdatum, men inte läser prompter och svar. Det är leverantörens eget påstående; bland de granskade källorna finns ingen oberoende teknisk verifiering. Och i allmänhet bevisar en kontrollpanel inte att teamet redan har minskat antalet incidenter eller kostnader: det gick inte att hitta några offentliga resultat efter lanseringen i det granskade materialet.