---
type: "post"
id: "github-secret-scanning-now-detects-cloudflare-access-service-a3ec53"
slug: "github-secret-scanning-now-detects-cloudflare-access-service-a3ec53"
title: "GitHub secret scanning now detects Cloudflare Access service tokens"
description: "GitHub Secret Scanning now detects Cloudflare Access service tokens through a dedicated detector."
retrieval_nugget: "GitHub Secret Scanning now detects Cloudflare Access service tokens through a dedicated detector. For teams that use these credentials in code or automation, the change adds a new route for finding exposures: public findings can be reported to Cloudflare, while findings in public and private repositories can generate user alerts."
published_at: "2026-11-14"
updated_at: "2026-11-14"
record_date: "2026-11-14"
date_kind: "published_at"
topics: ["github"]
entities: ["GitHub","GitHub Secret Scanning","Cloudflare","Cloudflare Access"]
related_patterns: ["agent-security-moves-to-runtime-boundaries"]
novelty_label: "new_fact"
what_changed: "GitHub added detection for Cloudflare Access service tokens, which are automatically reported to Cloudflare when found in public repositories."
prior_refs: ["https://newruntime.com/posts/updates-to-github-secret-scanning-8b5197/"]
source_url: "https://github.blog/changelog/2026-11-12-secret-scanning-adds-a-detector-for-cloudflare"
source_urls: ["https://github.blog/changelog/2026-11-12-secret-scanning-adds-a-detector-for-cloudflare"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:github-secret-scanning-now-detects-cloudflare-access-service-a3ec53"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/github-secret-scanning-now-detects-cloudflare-access-service-a3ec53/","markdown":"https://newruntime.com/posts/github-secret-scanning-now-detects-cloudflare-access-service-a3ec53.md","json":"https://newruntime.com/posts/github-secret-scanning-now-detects-cloudflare-access-service-a3ec53.json"}
markdown_url: "https://newruntime.com/posts/github-secret-scanning-now-detects-cloudflare-access-service-a3ec53.md"
---

# GitHub secret scanning now detects Cloudflare Access service tokens

## Retrieval answer

GitHub Secret Scanning now detects Cloudflare Access service tokens through a dedicated detector. For teams that use these credentials in code or automation, the change adds a new route for finding exposures: public findings can be reported to Cloudflare, while findings in public and private repositories can generate user alerts.

## Summary
GitHub Secret Scanning now detects Cloudflare Access service tokens through a dedicated detector. For teams that use these credentials in code or automation, the change adds a new route for finding exposures: public findings can be reported to Cloudflare, while findings in public and private repositories can generate user alerts.

## What happened
GitHub’s November 12, 2026 changelog announces that Secret Scanning now automatically detects Cloudflare service tokens. The new secret type is named `cloudflare_access_service_token` in GitHub’s detector list. GitHub labels the entry an improvement and presents it as an addition to Secret Scanning’s supported secret types.

The announcement describes two different outcomes depending on the kind of secret and where it is found. Partner secrets discovered in public repositories are automatically reported to the secret issuer through GitHub’s secret-scanning partnership program. For this detector, Cloudflare is the provider named by GitHub. The announcement says the report is sent to the issuer; it does not say that GitHub revokes the token, rotates it, or otherwise removes the credential from service.

GitHub separately says that user secrets generate Secret Scanning alerts when they are found in public or private repositories. That makes the private-repository case distinct from the partner-reporting path described for public repositories. A team can therefore receive an alert for a Cloudflare Access service token in a private repository, while GitHub’s stated automatic reporting arrangement concerns partner secrets exposed publicly.

The changelog links to GitHub’s Secret Scanning documentation and its full list of supported secrets. It does not describe a new Cloudflare Access configuration workflow, a new token format, or any change to the way Cloudflare issues service tokens. Nor does it announce a preview period, a rollout timetable, pricing, plan eligibility, repository prerequisites, or a setting administrators must turn on. The bounded change is the detector itself: GitHub Secret Scanning recognizes this Cloudflare token type in repositories and applies the reporting or alert behavior stated in the announcement.

For practitioners, the operational significance is not that every Cloudflare credential is now covered. It is that one explicitly named service-token type joins the detection surface of a tool many teams already use to find committed secrets. A finding can start a response workflow, but the changelog does not represent detection as remediation. The owner of the affected system still has to determine whether the token is valid, exposed, or used, and decide whether to revoke or replace it.

## What the archive adds
New Runtime’s [October 28 coverage of GitHub secret scanning](https://newruntime.com/posts/updates-to-github-secret-scanning-8b5197/) covered product and API changes including encoded-token revocation. An [earlier New Runtime note on GitHub’s fine-tuned secret-detection model](https://newruntime.com/posts/github-brings-its-fine-tuned-secret-detection-model-03c54b/) covered its extension to push protection and Copilot security reviews. This is a new detector on a known Secret Scanning story, rather than a restatement of those changes.

## Trend signal
This supports, indirectly, [Agent security moves to runtime boundaries](https://newruntime.com/patterns/agent-security-moves-to-runtime-boundaries/). The pattern argues that durable agent security comes from constraining what systems can read, execute, remember, and authorize. Secret scanning acts later in the chain: it can identify a credential after it reaches a repository. That is valuable exposure detection, but it does not itself narrow a token’s permissions or prevent an agent from accessing it.

## Why it matters
Cloudflare Access service tokens can be part of automated access paths. When one lands in a repository, the useful question is not only whether a detector finds it, but whether the team can turn that finding into a bounded response. GitHub’s addition gives teams using this token type another automated signal in both public and private repository contexts.

The announcement’s two paths matter operationally. A public partner-secret finding is reported to Cloudflare, while user-secret findings in public or private repositories generate alerts. Those are not equivalent to remediation. Teams should decide who owns triage, who can revoke or rotate the credential, how they check its usage, and how they confirm that replacement credentials have the least necessary access. The detector expands visibility; a response process determines whether that visibility reduces risk.

## What happens next
- **GitHub will continue adding named secret detectors from providers through its partnership program.** (6 months, 70%). Watch for: additional GitHub changelog entries naming providers and secret types.
- **Teams using Cloudflare Access service tokens will formalize alert-to-rotation playbooks where Secret Scanning findings reach their repositories.** (12 months, 55%). Watch for: repository security procedures that assign credential ownership and revocation steps.

## Limits and uncertainty
GitHub’s announcement does not publish detection accuracy, false-positive rates, matching methodology, or examples of the token form it recognizes. It does not say which plans, repository settings, or account configurations are required for the detector and alerts. GitHub also does not state how quickly Cloudflare receives or acts on public-repository partner reports, whether Cloudflare automatically revokes any reported token, or how repository owners are notified of an issuer response. The scope is one named token type, not a statement of comprehensive coverage for Cloudflare credentials.

## Skill to build now
Write a short credential-exposure runbook for the service tokens your team uses. For each token type, identify its owner, the system where it can be revoked, the replacement procedure, the logs used to check possible use, and the person who closes the incident. Then test the path from a Secret Scanning alert to a rotated credential. This change makes that exercise concrete for Cloudflare Access service tokens.

## Reader takeaway
GitHub Secret Scanning now recognizes Cloudflare Access service tokens. Treat the new detector as an additional discovery control, not an automatic fix: public partner findings can reach Cloudflare and repository findings can alert users, but teams still need to investigate exposure and rotate credentials when warranted.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Github](https://newruntime.com/topics/github.md): Explore the github topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)