Forgotten API Keys: How to Revoke Them Without Taking Down a Service

OpenRouter’s internal review found more than 1,000 active API keys across 85 employees; 168 keys, the company said, had not been used for months. These figures come from OpenRouter’s self-audit, not an independent industry study. But even as an isolated example, they illustrate a familiar engineering trap: a key can be forgotten, but not the application that depends on it. The company dated its Security Center announcement September 28, 2026.

The problem is not simply to find the oldest credential and delete it. A team needs to identify its owner, find out where the key is used, and work out how to replace it without disabling an infrequent task or forgotten service. Without that information, revoking access turns cleanup into a risky experiment.

What Security Center shows—and what it doesn’t prove

According to OpenRouter’s description, Security Center brings together keys in an account and displays the owner, last use, spending limit, and expiration date; organization admins can see all keys, while members can see those they created. For bulk actions, users can select up to 500 keys to disable, archive, or set a spending limit for. Disabling is reversible; archiving is not. These are features described by the vendor itself, not an independent assessment of their effectiveness.

It is especially important to read the “safe to delete” status as a prompt to investigate, not proof that no dependencies exist. Usage metrics show past requests, but do not necessarily explain which cron job, emergency process, or seasonal workflow depends on a key. OpenRouter itself advises confirming deletion with the owner; its security settings documentation also warns users to check dependencies before disabling or archiving a key.

Network restrictions come with a separate caveat: IP allowlisting is available to Enterprise-plan admins and applies to every key in the organization. Requests from addresses outside the list are rejected with a 403 error, and changes take effect immediately. So before enabling the restriction, account for production server, office network, and CI runner addresses; otherwise, the security measure itself could interrupt legitimate calls.

A cleanup process: owner first, revocation second

1. Build an inventory. For each key, record its owner, purpose, environment, consumers, spending limit, and expiration date. If the system identifies the owner only as an individual, also assign a team or service to take responsibility if that person leaves.
2. Check usage and dependencies. Compare the time of the last request with background-job schedules, backup processes, release pipelines, and external integrations. Lack of recent activity is a reason to ask the owner, not sufficient grounds for immediate deletion.
3. Reduce risk before migration. Where supported, set a reasonable spending limit and expiration date. Follow the principle of least privilege and secret-storage practices: the OWASP Secrets Management Cheat Sheet treats credential inventory, access, and lifecycle as distinct parts of the process.
4. Create a replacement and migrate consumers. Update the secret in your vault or deployment configuration, then move applications over in stages. Do not paste the key value into tickets, logs, or source code.
5. Verify production before revoking the old key. Confirm the new key works for all known consumers, including CI and infrequent jobs. Then disable the old key first, if a reversible operation is available; archive or delete it only after confirming the migration and allowing an agreed observation period.

The sequence “create a new key → migrate applications → verify functionality → delete the old key” matches OpenRouter’s rotation guide. This is a recommended order, not a guarantee of zero downtime: the outcome depends on whether you found every system that uses the credential.

Service keys are not the organization’s only secrets

A vendor-specific dashboard helps manage keys for that service, but does not, by itself, centralize secrets from cloud platforms, databases, CI/CD, and other APIs. The broader OWASP guidance on secret lifecycles covers centralized storage, access control, auditing, rotation, and revocation. Google Cloud’s recommendations separately advise limiting key scope, removing unnecessary credentials, and monitoring usage.

OpenRouter also says Security Center uses key metadata, spending, and expiration dates, rather than reading prompts and responses. That is the vendor’s own statement; the sources reviewed contain no independent technical verification. More generally, having a dashboard does not prove that a team has already reduced incidents or costs: the materials reviewed did not show public results after launch.