The secret is gone. The Copilot Actions run still needs a card.

The run finishes in four minutes, same as every other day this week. What's different is what isn't there. Scroll to the secrets list for this workflow and the long-lived personal access token that used to sit there - the one someone rotated every ninety days and hoped nobody had screenshotted - is gone. In its place: nothing to rotate, nothing to leak, nothing for a departing contractor to walk out with. The job authenticates on the token GitHub Actions already hands it for free, calls Copilot CLI, and exits clean.

That's the fix GitHub shipped on July 2, and it's a real one. Long-lived PATs sitting in Actions secrets have been a standing liability for as long as teams have automated with them - one more credential to rotate, scope, and eventually forget about until a security review finds it. GitHub's own language is direct about what this removes: teams "no longer need to create and store a personal access token (PAT), eliminating the operational and security risks of managing long-lived PATs for automations at scale."

What that fix doesn't touch is the paragraph a few lines further down the same changelog post. The run that just finished clean didn't only authenticate more safely - it spent organization AI credits, under a permission that grants it inference by default, and left behind a session record that nobody on the team necessarily routed anywhere or agreed to read. A secure token is not a budget. It is not a receipt. It is definitely not a reviewer.

What actually shipped on July 2

GitHub published four changelog entries the same day, and reading them together is more useful than reading any one alone.

The headline change: Copilot CLI can now authenticate inside GitHub Actions using the workflow's built-in GITHUB_TOKEN. Turn on the org-level policy, which GitHub labels "Allow use of Copilot CLI billed to the organization," and, per the changelog, "workflows just need the copilot-requests: write permission and can authenticate with the workflow's built-in GITHUB_TOKEN." No PAT to mint, store, or rotate. The catch sits in the next sentence, stated as plainly as the benefit: "user-level budgets are not considered when billing directly to the organization because the cost is not attributed to a user." The spend still has a source, the org's AI credit pool, but no longer a person attached to it by default.

The second entry moves in the opposite direction: visibility. Copilot agent session streaming is now in public preview for GitHub Enterprise Cloud customers on enterprise managed users, covering cloud agents on github.com and ghe.com, Copilot CLI, VS Code, Visual Studio, and partner IDEs. GitHub is offering, in its own words, "direct visibility into agent session activity (e.g., prompts, responses, and tool calls)" - through a streaming endpoint for real-time ingestion, or a REST endpoint, GET /enterprises/{enterprise}/copilot/usage-records, that lets a team "pull the last 48 hours of session data on demand." Microsoft Purview is supported as a preview destination for teams already routing enterprise data there.

The third: cost centers now support AI credit pools. Admins can cap monthly included AI credits per cost center via the REST API today, with a UI coming later, and choose whether a cost center that hits its cap gets blocked from further included usage or rolls into billed overage. The fourth: usage metrics reporting got more complete - CLI runs now report suggested lines of code, more users get IDE and plugin version data, and AI credit consumption attributes more fully across the board.

Read as one release, the shape is coherent: GitHub removed a credential risk, and in the same breath, built the scaffolding - streaming, usage records, credit pools - for the accounting problem that removal creates. The scaffolding is optional. The credential removal is not.

The workflows that already made the trade

This isn't hypothetical adoption. Within days, two public repositories show the pattern taking hold in the wild, and both are instructive for what they do and don't carry with them.

Microsoft's testfx repository merged a pull request titled "Authenticate Copilot inference via copilot-requests: write," adding the permission across roughly thirty Copilot-engine workflows and retiring an expiring PAT in favor of the per-run Actions token. The middleware project at Appwarden did the same in a smaller PR: add copilot-requests: write, remove the COPILOT_GITHUB_TOKEN secret, note in the description that admins need to enable org-billed Copilot CLI for the change to work at all.

Both PRs are exactly what you'd want a secure migration to look like - small, mechanical, easy to review. Neither PR's diff contains a cost center, a credit cap, or a name for who reads the session log. That's not a criticism of either team; the changelog doesn't ask for those things, and the permission line works fine without them. It's the point. The security fix is a one-line YAML change. The spending and oversight questions it opens don't show up in a diff at all - they show up three weeks later, in a usage report somebody finally pulled.

The new operating surface, not a new feature

The interesting part of this release was never the token swap. It's what the token swap makes ordinary: a CI job that can spend organization money on inference, on every run, without a human in the loop for any individual call.

Before July 2, using Copilot CLI in Actions meant someone minted a PAT - a deliberate, slightly annoying, personally-accountable act. That friction was, unintentionally, a form of governance. It made "who authorized this workflow to call Copilot" a question with an obvious answer: whoever's token was in the secret. Remove the PAT and you remove the friction along with the risk. What's left is a permission line anyone can add to a workflow file, reviewed the way any other line of YAML gets reviewed - which is to say, sometimes closely, often not.

That's the trade this release actually makes: it converts an ad hoc, personally-owned spend into a standing, organizationally-billed one. Ad hoc spend is expensive per-instance and self-limiting - someone notices their own token racking up charges. Standing spend is cheap per-instance and only self-limiting if someone built the limit. GitHub gave operators every tool to build that limit: cost centers, credit pools, streaming, usage records. It did not turn any of them on by default, and nothing in the release makes a workflow author reach for them before merging copilot-requests: write.

Where it stays quiet

None of this fails loudly. A workflow with the permission and the org policy enabled runs exactly as designed, every time, for months. The first sign of trouble isn't an error - it's a credit-pool report that someone finally opens and doesn't recognize, or a finance conversation about why the AI line item moved without a corresponding headcount change.

Nobody has to do anything wrong for that to happen. A workflow that retries Copilot CLI on a flaky test, or that fans out a review call across every file in a large diff, behaves identically whether or not anyone capped its cost center - right up until the cap either blocks the run or quietly becomes overage, and the team finds out which one happened after the fact instead of before. That's the same shape of problem we've written about with agent spend circuit breakers generally: a credential can be valid and well-scoped and still have no runtime boundary around what it's allowed to cost. GitHub just built that exact scenario into CI, cleanly enough that it's easy to miss the moment it happens.

Session streaming has the same quiet-failure shape from the other direction. Prompts, responses, and tool calls are now visible on request - but visible isn't the same as reviewed. A warning budget ledger works because it names an owner for every finding a gate leaves standing instead of letting them scroll off the screen with the merge. A usage-records endpoint works the same way only if a person is assigned to pull it. Otherwise it's a 48-hour window of evidence nobody's watching, which is a strictly better problem to have than no evidence at all, but not the governance win it looks like on the changelog page.

The Copilot Actions run card

So make the workflow earn the permission the same way you'd make a person earn a production credential: with a card, filled in before the merge, not reconstructed after the invoice.

A Copilot Actions run card is one page per workflow. It doesn't replace GitHub's controls - the org policy toggle, the cost-center cap, the usage-records endpoint all still do the actual enforcing. What the card does is force someone to decide, on the record, how those controls apply to this specific workflow before copilot-requests: write ships.

Ten fields. What they buy you is the same thing the warning budget ledger buys a merge decision: a place where "we decided this was fine" is a specific, dated, ownable claim instead of an assumption baked into a YAML file nobody revisits. If the review bot's credit pool doubles its usage next quarter, the card already says whose budget that's coming from and who gets paged when it hits the cap. Without the card, that conversation starts from zero, weeks after the spend already happened.

Bring one workflow, not a policy document

You don't need to govern every workflow in the org this week. You need one card, for the workflow closest to getting copilot-requests: write merged, or the one that already has it.

Pull that workflow's file. Confirm the permission is scoped to the job, not inherited. Confirm the org-billed policy is actually on, and find out who turned it on. Name the cost center it charges and put a credit cap on that cost center today, even a generous one - a cap you never hit costs nothing; a workflow with no cap at all is one retry loop away from a number nobody predicted. Decide, in writing, whether hitting that cap blocks the run or becomes overage, and who owns that call. Point the usage-records endpoint or the audit-log stream somewhere a specific person actually checks. And write down how to pull the permission back in one move if any of that goes sideways.

That's not a compliance exercise. It's the same discipline behind an agent receipt - not just proof that a workflow ran, but who owns what it spent and what it saw. If your org is already tracking Copilot adoption by cohort, the run card is the natural next layer down: cohorts tell you who's using Copilot; the run card tells you what each CI workflow using it on the org's behalf is actually allowed to cost.

GitHub did the hard part. The token is gone, and that's a genuine security win worth taking. What's left is the part no vendor release notes can do for you: deciding, workflow by workflow, what "billed to the organization" is actually supposed to mean. If you're rolling out org-billed Copilot CLI in Actions, or you already have copilot-requests: write sitting in a workflow file somewhere, bring us that one workflow. We'll help you write its run card - the cost center, the credit cap, the review owner, and the rollback path - as part of how we already scope process automation work. Build a Copilot Actions run card.