The 30-Second Brief
- Source report Cloudflare AI Gateway now displays activity information for stored provider keys; usage tracking begins in November 2026. [1]
- Analysis Use key activity as an investigation aid, then confirm ownership and dependencies before cleanup.
What Changed
The Provider Keys view groups credentials by provider and shows masked previews, aliases, last-used dates and last-updated dates. Cloudflare says its Key security section highlights keys with recorded activity older than 90 days and advises checking dependencies before deletion. [1]
Why It Matters
Analysis A quiet credential might belong to a recovery job that runs only during an incident. The operational question is whether a responsible owner can explain its purpose and demonstrate that a replacement works. Last-use information helps direct that conversation, but an inventory still needs an application name, an owner and a recovery path.
Worked example: review one stored key
Hypothetical example — no customer account or feature test is represented. A small team finds an OpenAI key with the alias recovery in its gateway. It has no recorded activity in the new tracking window. Before treating it as unused, the team builds this review record.
| Review field | Example finding or next check |
|---|---|
| Owner | Operations lead owns the credential; the application maintainer must confirm every consumer. An unidentified owner is an unresolved investigation, not permission to delete. |
| Dependent applications | An incident-summary tool calls the direct OpenAI provider endpoint through AI Gateway and selects recovery. Check its deployed request configuration, scheduled jobs and runbook references. |
| Activity evidence | No activity appears in the new tracking window. Record the inspection date and tracking limit, then compare application records and available gateway/provider evidence. This does not establish earlier non-use. |
| Occasional or recovery work | The tool is reserved for incidents and a quarterly recovery exercise. Confirm that the runbook still needs it and schedule an authorized exercise. |
| Proposed decision | Retain pending dependency confirmation and the exercise. Rotate if required by the team's credential policy or a security incident; consider removal only after retirement or a verified replacement. |
| Verification | Pending, not passed: test the real request path, verify the intended credential and billing route, exercise the recovery workload, and record evidence plus an owner-approved outcome. |
BriefSpire analysis: Retention needs a defensible purpose; rotation changes a credential while preserving a needed capability; removal retires a dependency. Activity age alone does not answer which action is appropriate. Suspected compromise also needs incident handling: retaining a compromised old key as a rollback option is not a safe recovery plan.
Check the request path before rotating
For direct provider-passthrough requests, a recognized provider credential takes precedence over stored BYOK; a placeholder provider header can break authentication. When stored BYOK is used, the key is default unless the request selects another alias with cf-aig-byok-alias. Updating a stored key will not replace a credential still supplied by an application. Check the provider and endpoint's credential format in credential precedence and BYOK configuration.
The Unified Billing path differs: env.AI.run() and /ai/v1/chat/completions consult the stored default alias, not an arbitrary alias header. If no applicable credential exists, allowed fallback can use Cloudflare-managed credentials and credit balance. A successful response alone therefore does not prove the intended stored key worked. Review credential precedence and the documented Require provider credentials setting or per-request cf-aig-no-wholesale: true when testing must exclude that fallback.
Proposed verification and recovery sequence
These are checks for an authorized operator to perform; BriefSpire has not performed them on a Cloudflare account.
- Record the baseline. Identify the account, gateway, provider, endpoint, alias, consumers and current fallback settings without copying secrets into the review record. Check gateway authentication and the operator's Secrets Store permissions. For provider-native endpoints, Cloudflare authentication uses
cf-aig-authorization; the newer Cloudflare REST API uses the standardAuthorizationheader for the Cloudflare token. Keep that distinction separate from provider credentials. Authentication reference. - Prepare the replacement and recovery route. Cloudflare's documented stored-key rotation is to generate a replacement at the provider and replace the existing entry. Multiple stored keys can support staged migration, but selecting a new alias is appropriate only for a request path that supports it. For the hypothetical direct request, test a separate alias first; for a
default-only path, arrange a controlled change and an independently usable recovery credential. Rotation reference. - Make an observable test request. Use a non-sensitive sample through the application's actual endpoint and credential configuration. Bypass cached responses with the documented
cf-aig-skip-cache: trueheader so a cached answer cannot substitute for a provider call. Caching reference. - Check more than HTTP success. Correlate the request time with available gateway and provider records; inspect provider, status, cost and the expected billing route. Check logging configuration before interpreting a missing entry. Cloudflare supports metadata-only logging through
cf-aig-collect-log-payload: false; do not put API keys into prompts or evidence. Logging reference. - Exercise the less frequent dependency. Run the authorized recovery job and, where configured, inspect fallback branches as well as the normal route. Dynamic routes can send failed or timed-out requests to another model, so a working final response may conceal a failed primary path. Dynamic-routing reference.
- Close or recover the change. If checks fail, stop retirement and restore the documented working configuration with a valid, uncompromised credential, then repeat the checks. If a key is genuinely retired, remove it only after consumers are migrated: Cloudflare warns that deletion immediately disrupts requests depending on it. Treat provider-side revocation as a separate provider-specific task; do not assume deleting the stored entry revokes the original provider credential. Record the outcome and follow-up date.
Evidence & Uncertainty
The tracking start date limits the history available now. Do not read a missing recent activity record as proof that a key has never been used. The announcement does not establish compromise detection or automatic safe removal. BriefSpire has not independently tested the feature. [1]
Action Center
Suggested checks from BriefSpire. Selections remain in this browser.
Evidence Explorer
Does an old activity date prove a key is safe to delete?
No. BriefSpire recommends checking infrequent workloads and recovery dependencies first.
Is this evidence of a leaked credential?
No. The release describes an activity-review feature, not a finding of compromise.
Sources & Transparency
Sources checked . Substantive update November 8, 2026: added a hypothetical key-review record and configuration-aware verification steps. Original publication date retained. Source findings are attributed above; implications, examples and suggested checks are BriefSpire analysis.
- Cloudflare: Review provider key activity in AI Gateway (November 6, 2026).