GitHub making default-branch cache tokens read-only for untrusted triggers matters because it cuts off a subtle escalation path where poisoned cache entries could later reach trusted workflows.
GitHub's read-only Actions cache change does not sound dramatic.
It should.
On June 26, GitHub said workflow events that can be triggered without write permissions to a repository now get read-only cache tokens when the workflow context and cache scope come from the shared default-branch SHA.
That sentence is dry.
The operational consequence is not.
GitHub is cutting off a cache-poisoning path where untrusted workflow activity could write to default-branch cache state and a later trusted workflow would restore that poisoned state.
That is not just a performance detail. That is a trust-boundary fix.
Caches often get talked about like harmless acceleration dust.
They are not harmless when they influence what later jobs restore and execute.
GitHub's write-up is unusually direct here. It calls out prior cases where triggers like pull_request_target, issue_comment, or fork-pull-request workflow_run cascades could lead to write access against default-branch cache scope. If an external actor could influence workflow code in that context, they could poison the cache and let a later trusted workflow restore the bad entry.
That makes the cache part of the workflow's security model.
Once you see it that way, the new default makes sense. Least privilege should apply to caches too.
Teams should not read this as GitHub taking useful speed away for fun.
The important move is that untrusted triggers no longer get read-write cache power over shared default-branch state. Restores still work. Trusted triggers like push, schedule, and workflow_dispatch keep read-write access. Jobs where a save is blocked log a warning and continue.
That is a much more disciplined compromise than simply disabling caching in risky lanes.
GitHub is trying to preserve performance where trust is higher while removing a known escalation path where trust is lower.
The mitigation guidance in the changelog is the practical tell.
If a team still wants warm caches available to those untrusted workflows, GitHub says cache saves should happen in a separate trusted workflow triggered by an event that still has read-write access.
That means some repos now need to think more carefully about which jobs populate shared state and which jobs merely consume it.
Butler has already tracked GitHub's workflow-execution protections and other trust-surface shifts. This cache change fits the same broader pattern. GitHub is treating developer-convenience features as security boundaries that deserve policy and least privilege.
The teams most likely to care are the ones with public contribution surfaces, heavily automated repos, or workflow patterns that accept some input from non-collaborators.
Those teams should test two things right away:
This is also a good moment to review where pull_request_target and similar patterns are used, and whether the team's current workflow design accidentally treats convenience state as if it were neutral.
It is not neutral.
GitHub did not announce a new scanner or a new enterprise dashboard.
It changed cache token permissions.
That sounds small until you understand what caches can carry forward between trust levels.
The real Butler takeaway is that CI performance infrastructure keeps turning into supply-chain infrastructure. Once that happens, operators need to design it with the same caution they apply to secrets, approvals, and execution context.
GitHub's new read-only rule does not solve every workflow security problem.
It does solve one quiet but meaningful one.
And that makes it one of the more important current-week GitHub changes for teams that let the public anywhere near their automation.
This article was researched and drafted with AI assistance, then reviewed and edited for clarity, accuracy, and editorial quality.