Cloudflare’s 6 November announcement adds stored-provider-key activity to AI Gateway: provider grouping, masked previews, aliases and last-used/updated dates. Key security highlights recorded activity older than 90 days. Tracking begins in November 2026.
That start date limits interpretation: missing history does not prove non-use. Treat the 90-day marker as a review prompt, not a deletion rule. The announcement provides no basis for assuming a complete history of earlier use.
Existing mechanics that affect the review
The existing BYOK documentation explains storage through Secrets Store. On provider-passthrough requests, a supplied provider authorization header takes precedence over the stored key. Deleting a key interrupts requests that depend on it, so dependencies and replacements must be reviewed first.
There is also a billing-path distinction. On Unified Billing endpoints, only the stored default alias is consulted. Without applicable request or stored credentials, allowed fallback can use Cloudflare-managed credentials and credits. Review the credential-precedence rules for the endpoint in use.
Gateway authentication remains a separate concern: Cloudflare documents cf-aig-authorization for provider-native endpoints and the standard Authorization header for its REST API. Do not remove gateway authentication while reviewing provider credentials. Authentication documentation.
A review that produces a useful decision
The following is our suggested operational checklist, not a report of hands-on testing. It follows the distinction between rotation and revocation in OWASP’s secrets lifecycle guidance.
- Give the entry an owner. Record the provider, gateway, alias, application owner and intended purpose. Keep actual secret values out of tickets and screenshots.
- Find occasional consumers. Include scheduled jobs, fallback routes and recovery procedures in the dependency list. A quiet period between monthly jobs is a poor reason to conclude that a credential is unnecessary.
- Check which credential the application selects. Compare the endpoint, request-header configuration and alias with the intended path. Use redacted configuration and appropriately protected provider records.
- Plan an authorized change. For routine retirement, agree on replacements and a recovery plan before deletion. If compromise is suspected, use the incident-response process rather than waiting for a housekeeping threshold.
- Verify the outcome. For any approved test, record successful application behavior, relevant errors and the provider or billing path actually used. A successful response alone does not establish that the intended stored key served it.
Leave each reviewed entry with a concrete outcome: keep with an identified owner, investigate a missing dependency, or retire through a tested change plan. We have not inspected a customer account or validated the new dashboard’s behavior.