OpenRouter launches Security Center to find and remove risky API keys

Why OpenRouter built it

The idea behind the tool is simple: the fewer old keys exist, the fewer can leak. OpenRouter says it audited its own organization first. Because the company builds OpenRouter on OpenRouter, it found a lot to review: over 1,000 active keys for 85 employees. Many had no spend limit, and 168 had not been used in months, belonging to employees who had forgotten about them.

The company argues that if a team of its size ended up with this much key sprawl, many customers probably have the same problem.

What the Security Center shows

The tool has three tabs: Overview, Key safety, and IP allowlist. The Overview counts keys in four groups: no spend limit, never expires, unused or idle for 90+ days, and safe to remove. Below the counts it lists recommendations for what to fix first:

• Remove unused keys, after asking each owner to confirm, then archive.
• Set a spend limit, which caps what a leaked key can spend.
• Review keys without expiration and replace them with expiring keys, or remove those no one needs.
• Turn on key spend alerts, which send an email when a key crosses a share of its spend limit.
• Enforce a maximum key lifetime. Requests from keys that never expire, or outlive the limit, are rejected, including existing keys.

The Key safety tab lists every key that can still make requests across every workspace on an account. Until now, keys lived on each workspace's own page. The list includes MCP and management keys, with owner, last use, spend limit and expiration shown side by side. Admins see every key, while members see the keys they created.

Each key gets a risk score based on what a leaked copy could do, which comes down to its spend limit and expiration. Usage sets a separate status label. A key with no recorded usage, or idle for six months with under $1 of lifetime spend, is marked 'Safe' to remove. Recent or meaningful usage is 'In use'. Keys in between are labeled 'Review'. OpenRouter's example is $3 of lifetime spend and no requests in five months, a key that someone probably wired into something once, so owners should be checked before archiving.

Bulk actions and IP allowlist

Users can filter by risk or idle time, then select up to 500 keys and disable, archive, or add a spend limit to all of them. Disabling is reversible, archiving is not, and adding a limit never overwrites one that someone already set. Admins can also copy a CSV of any recommendation's keys and owners to pass to a script or an agent. OpenRouter says the Security Center works from key metadata, spend, limits and expiry, and never reads prompts or completions.

The IP allowlist, which used to sit in privacy settings, now has its own tab. It controls where a key works. Customers add the addresses their servers, office network and CI runners call from, and OpenRouter rejects any request from outside that list with a 403 Forbidden. The list applies to every key in the account or organization, including older ones, and changes take effect immediately. Entries can be a single IPv4 or IPv6 address or a CIDR range, each with a label. According to the post, the IP allowlist is available to organization admins on Enterprise plans.

Practices OpenRouter recommends

Since its audit, the company says it has adopted several habits to keep its own keys in check:

• Clean up on a schedule, starting with Safe to remove keys and confirming with owners before archiving.
• Check keys when someone leaves, by filtering by owner and archiving or auto-revoking (via SCIM) keys no one took over.
• Give every key a limit and an expiration, which contains the blast radius if a leak happens.
• Pin production keys to known addresses by placing servers and CI runners on the IP allowlist.
• Rotate keys that stay in use, following the key rotation guide.

For teams using OpenRouter, the Security Center offers a single view of key exposure that was previously spread across workspace pages, along with tools to reduce it in bulk. The company points to its docs for more detail.