Vergeten API-sleutels: zo trek je ze in zonder een dienst stil te leggen

Een interne controle van OpenRouter vond meer dan 1.000 actieve API-sleutels voor 85 medewerkers; 168 sleutels waren volgens het bedrijf al maanden niet gebruikt. Dit zijn cijfers uit een zelfcontrole van OpenRouter, geen onafhankelijk sectoronderzoek. Maar zelfs als individueel voorbeeld laten ze een bekend technisch risico zien: een sleutel kan worden vergeten, maar niet de applicatie die ervan afhankelijk is. Het bedrijf dateerde de aankondiging van Security Center op 28 september 2026.

Het probleem is niet simpelweg de oudste inloggegevens opsporen en verwijderen. Het team moet de eigenaar vaststellen, nagaan waar de sleutel wordt gebruikt en begrijpen hoe die kan worden vervangen zonder een zeldzame taak of vergeten dienst uit te schakelen. Zonder die informatie verandert het intrekken van toegang van opruimen in een riskant experiment.

Wat Security Center laat zien — en wat het niet bewijst

Volgens OpenRouter brengt Security Center de sleutels in een account samen en toont het de eigenaar, het laatste gebruik, de bestedingslimiet en de vervaldatum; organisatiebeheerders zien alle sleutels, terwijl leden alleen de sleutels zien die ze zelf hebben aangemaakt. Voor bulkacties kun je maximaal 500 sleutels selecteren om uit te schakelen, te archiveren of een bestedingslimiet in te stellen. Uitschakelen is omkeerbaar, archiveren niet. Dit zijn kenmerken van de tool zoals beschreven door de leverancier zelf, geen onafhankelijke beoordeling van de effectiviteit ervan.

Het is vooral belangrijk om de status ‘kan worden verwijderd’ te zien als een aanwijzing om iets te controleren, niet als bewijs dat er geen afhankelijkheden zijn. Gebruiksgegevens tonen eerdere verzoeken, maar maken niet noodzakelijk duidelijk van welke geplande taak, noodprocedure of seizoensgebonden proces een sleutel deel uitmaakt. OpenRouter adviseert zelf om verwijdering bij de eigenaar te bevestigen; de documentatie over beveiligingsinstellingen waarschuwt ook dat je afhankelijkheden moet controleren voordat je een sleutel uitschakelt of archiveert.

Voor netwerkbeperkingen geldt een afzonderlijke kanttekening: IP-allowlisting is beschikbaar voor beheerders met een Enterprise-abonnement en geldt voor alle sleutels van de organisatie. Verzoeken vanaf adressen buiten de lijst worden afgewezen met een 403-fout en wijzigingen worden onmiddellijk van kracht. Houd daarom vóór het inschakelen van de beperking rekening met de adressen van productieservers, het kantoornetwerk en CI-runners; anders kan de beveiligingsmaatregel zelf legitieme aanroepen onderbreken.

Opruimen in de juiste volgorde: eerst de eigenaar, dan intrekken

1. Maak een inventaris. Leg voor elke sleutel de eigenaar, het doel, de omgeving, de gebruikers, de bestedingslimiet en de vervaldatum vast. Als het systeem de eigenaar alleen als persoon vermeldt, wijs dan ook een team of dienst aan die de verantwoordelijkheid overneemt als die persoon vertrekt.
2. Controleer het gebruik en de afhankelijkheden. Vergelijk het tijdstip van het laatste verzoek met schema’s voor achtergrondtaken, noodprocedures, releasepipelines en externe integraties. Recente inactiviteit is een reden om de eigenaar te raadplegen, geen voldoende grond om de sleutel meteen te verwijderen.
3. Verklein het risico vóór de migratie. Stel waar mogelijk een redelijke bestedingslimiet en vervaldatum in. Houd rekening met het beginsel van minimale bevoegdheden en de regels voor het bewaren van geheimen: de OWASP-richtlijn voor geheimenbeheer behandelt inventarisatie, toegang en de levenscyclus van inloggegevens als afzonderlijke onderdelen van het proces.
4. Maak een vervangende sleutel en migreer de gebruikers. Werk het geheim bij in de opslag of de configuratie van de uitrol en schakel applicaties vervolgens gefaseerd over. Zet de sleutel niet in tickets, logs of broncode.
5. Controleer productie voordat je de oude sleutel intrekt. Controleer of de nieuwe sleutel in alle bekende gebruikers werkt, waaronder CI en zeldzaam uitgevoerde taken. Schakel vervolgens eerst de oude sleutel uit als dat omkeerbaar kan; archiveer of verwijder hem pas nadat de migratie is bevestigd en de afgesproken observatieperiode is verstreken.

De volgorde ‘nieuwe sleutel maken → applicaties overschakelen → werking controleren → oude sleutel verwijderen’ komt overeen met de rotatiehandleiding van OpenRouter. Dit is de aanbevolen volgorde, geen garantie dat er geen uitval optreedt: het resultaat hangt ervan af of je alle systemen hebt gevonden die de inloggegevens gebruiken.

Dienstsleutels zijn niet alle geheimen van een organisatie

Het dashboard van een specifieke leverancier helpt de sleutels van die dienst te beheren, maar centraliseert op zichzelf geen geheimen uit cloudomgevingen, databases, CI/CD en andere API’s. De algemene OWASP-richtlijn voor de levenscyclus van geheimen behandelt gecentraliseerde opslag, toegangsbeheer, auditing, rotatie en intrekking. De richtlijnen van Google Cloud adviseren daarnaast om het bereik van sleutels te beperken, onnodige inloggegevens te verwijderen en het gebruik ervan bij te houden.

OpenRouter stelt ook dat Security Center metadata van sleutels, uitgaven en vervaldatums gebruikt en geen prompts of antwoorden leest. Dat is een bewering van de leverancier zelf; in de geraadpleegde bronnen is geen onafhankelijke technische verificatie gevonden. En in het algemeen bewijst de aanwezigheid van een dashboard niet dat het team het aantal incidenten of de kosten al heeft verlaagd: in het onderzochte materiaal zijn geen openbare resultaten na de lancering gevonden.