Give Your OpenAI and Cloudflare Credentials an Expiry Plan

By Greg Nowak. Updated 15 September 2026.

A credential becomes difficult to replace long before it becomes technically obsolete. Someone adds an OpenAI key to a workflow, an agency creates a Cloudflare token, and the automation starts doing useful work. Later, changing that secret feels risky because nobody knows everything that depends on it.

For a business owner or operations lead, that uncertainty is the problem to fix. Every production credential needs an owner, a defined purpose, and a replacement procedure. An expiry date belongs in that plan, alongside a check for whether the integration still needs a stored secret.

Start with the job the credential supports

Before changing settings, ask your team to identify what would stop working if each credential disappeared. Include scheduled tasks, deployment pipelines, agency tooling, and recovery scripts. A successful daily job tells you little about a forgotten monthly task using the same key.

Create a shared inventory containing the credential’s name or identifier, responsible team, consumers, allowed resources, storage location, expiry or review date, and replacement instructions. Record the location of the secret, never its value. Assign a backup owner so renewal does not depend on someone being available during their holiday.

OpenAI: replace stored keys where federation fits

OpenAI documents workload identity federation for GitHub Actions: a workflow exchanges a GitHub-issued identity token for a short-lived OpenAI access token. This can remove a stored OpenAI API key from the workflow.

Configure an OpenAI Workload Identity Provider and map it to a service account. Match the issuer and audience, then constrain access by repository, Git ref, and workflow_ref; include the environment when used. For privileged mappings, workflow_ref identifies the workflow file and ref more precisely than its display name. Narrow the mapping’s API permissions as needed. Follow the official OpenAI setup and SDK examples.

The relevant GitHub job needs these permissions:

permissions:
  id-token: write
  contents: read

id-token: write permits requesting an identity token; it does not grant repository write access. The workflow also needs code that requests and exchanges that token. Adding this YAML alone does not complete authentication. GitHub’s OIDC guidance explains the sequence and recommends environment protection rules.

Store the provider ID, service-account ID, and audience as Actions variables. Keep the identity and access tokens out of logs. Use separate service accounts for build pipelines and production applications, and test the new authentication before removing the old key.

Cloudflare: narrow the token before setting its expiry

Give each automation only the permissions and resources it needs. For example, a DNS reporting job needs read access to the relevant zone; changing DNS records requires edit access. Check template permissions before accepting them.

For business automation, consider an account-owned token when the required endpoints support it. This avoids associating the credential with an individual user. Cloudflare’s token creation guide covers ownership, permissions, and resource selection.

Cloudflare tokens do not expire unless an end time is configured. Dashboard dates take effect at 00:00 UTC; use the API when a precise time is necessary. Client IP filtering can further restrict use, but first establish the runner’s actual outbound addresses. See Cloudflare’s token restrictions.

For a user-owned token, check its status with this command, supplying CLOUDFLARE_API_TOKEN through your secret store or protected environment:

curl "https://api.cloudflare.com/client/v4/user/tokens/verify" \
  --header "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}"

An active token is only the first check. Verification does not prove that the token has the permissions your job requires, and Cloudflare does not apply client IP filtering to the verification endpoint. Test the intended operation from the actual runner as well.

Rotate credentials without surprising the business

Expiry ends a credential’s validity. Rotation replaces its secret. Cloudflare’s Roll operation invalidates the previous secret while retaining its access and permissions. Consumers still using the old value will need updating.

For planned replacement, I recommend a short, controlled overlap:

1. Create the replacement. Confirm its scope and lifetime, then store it securely.
2. Update each consumer. Check whether it needs a restart, redeployment, or fresh workflow run to load the value.
3. Exercise the real work. Test deployments and scheduled operations, including infrequent jobs.
4. Revoke the old credential. Confirm successful operation and record completion in the inventory.

Agree on recovery steps before starting. During routine rotation, a still-valid old credential may provide a temporary fallback. If it is suspected to be compromised, revoke or roll it promptly and recover using fresh credentials.

Make renewal part of normal operations

Choose a lifetime your team can reliably maintain. Temporary supplier access should end with the work; ongoing automation needs renewal reminders early enough to investigate failures and test replacements. A calendar reminder is useful only if someone owns the response.

Start with one important integration and produce three things: a dependency inventory, a tested replacement procedure, and a named renewal owner. Repeat when suppliers, repositories, or responsibilities change.

If your team has inherited integrations that feel too fragile to change, talk to Greg about a credential review. We can map the dependencies, identify suitable federation migrations, and plan replacement around your operating schedule.

Related on GrN.dk

• Cloudflare Service Keys Stop in September: Find Every Caller
• Not Every AI Job Needs an Instant Answer: Batch the Backlog
• Background AI Tasks Need Queues—not Just Longer API Calls

Need help with this kind of work?

Discuss a credential review with Greg Get in touch with Greg.

Sources

• Configuring workload identity federation for GitHub Actions — OpenAI
• Configuring OpenID Connect in cloud providers — GitHub Docs
• Create API token — Cloudflare
• Restrict tokens — Cloudflare
• Roll tokens — Cloudflare