Michael JohnsonHow can you tell whether a long-stored model API key can be deleted? Since November 6, 2026, Cloudflare AI Gateway has shown the alias, last-used date, and last-updated date for saved provider keys. In the Key security section, the dashboard flags keys with no recorded activity in more than 90 days. For teams managing several keys through the gateway, this provides a concrete list of entries to audit. However, usage tracking itself only began in November 2026.
What exactly has changed?
The update applies to provider keys saved in AI Gateway. The Cloudflare announcement says the keys are grouped by provider; masked values, aliases, and last-used and last-modified dates appear alongside them. The Key security section flags entries whose last recorded activity was more than 90 days ago. Cloudflare says usage tracking began in November 2026.
The last-used date tells you when the gateway last recorded use of a key. The modified date shows when the entry was updated. Masking and aliases help identify an entry without displaying its secret value in the list. This is an inventory and a signal to investigate, not an automatic decision about what to do with a key.
How should you interpret the activity date?
Keys often remain after an experiment, a provider change, or an application migration. When a team stores them in a central gateway, it can become difficult over time to remember the purpose of every entry. Activity dates help prioritize the review: first check keys that have gone unused for a long time, then verify them with the application owner and environment.
The 90-day threshold applies to activity the system has recorded since tracking began in November 2026. So the flag does not describe the full usage history for earlier months. In addition, an infrequent task, a backup route, or an application that contacts a provider outside AI Gateway requires a separate check. For example, a backup key may not be needed for months but still be part of a recovery plan.
The BYOK documentation describes storing keys in Secrets Store and using them through AI Gateway. Deleting a key will immediately stop requests that depend on it. So delete an entry only after determining its purpose and dependencies, not simply because of the age of its activity flag.
How can you audit keys safely?
- Start with flagged keys. Make a list of entries whose last recorded activity was more than 90 days ago. Don’t delete anything yet.
- Identify the owner and purpose. Compare the alias with gateway configurations and team documentation; find out who is responsible for the application. If the purpose is unknown, determine it first.
- Check where the key is used. Find out whether it serves an infrequent report, a backup route, or an environment outside AI Gateway. The gateway’s activity record does not answer these questions.
- If the key is needed, prepare to rotate it. Create a new key with the provider and replace the secret in the existing AI Gateway entry. According to the documentation, applications will continue using the updated key through the same entry; after replacing it, test real requests.
- Delete only after checking dependencies. Make sure applications have been switched over or the key has been decommissioned. Deleting it will stop requests that depend on it.
Suppose a team sees a key whose last recorded activity was more than 90 days ago. The owner discovers that the entry was for a test environment and that the tests have already been switched to another key. After checking the configuration, the team can delete it. If the key is needed as a backup in case the primary provider fails, the team should document its purpose and owner and keep the entry.
What does this change for a team?
Instead of a general reminder to “check old keys,” the team now gets the last recorded activity date for each entry. This helps teams decide where to begin an access review, especially when they manage keys for multiple providers through AI Gateway.
Use a flag for more than 90 days of inactivity as a reason to check a key, not as an instruction to delete it. Verify the entry with its owner and application, and check backup scenarios; then confirm whether it is needed, replace the secret during rotation, or delete it after checking dependencies. That way, the log helps uncover forgotten entries without putting working applications at risk.
