Shared Copilot Automations bill the org: what to set first

GitHub began rolling out shared Copilot Automations on Oct. 28, 2026. A shared automation belongs to the repository, acts on GitHub as Copilot, and bills its AI credits to the organization or user that owns the repository, not to the person who built it. For organizations, the decision is whether to turn on the policy that lets Copilot cloud agent bill the organization, and which limits to set before a team starts relying on these workflows.

The catch is who controls the spend. GitHub's docs say everyone with write access to the repository can edit a shared automation, including its prompt, triggers and tools. Once the organization pays, any of those people can change how often it runs and what it may touch, and the bill lands on the organization rather than the editor.

What changed with shared Copilot Automations?

Automations can now be personal or shared. Until this release, GitHub's changelog says, automations "have been personal, meaning only you could see and edit them, and they used your identity and AI credits." Shared automations change all three of those defaults.

An automation is a Copilot cloud agent task with a saved prompt, one or more triggers (a schedule, a new issue, an opened or updated pull request, or an API call) and a set of allowed tools. GitHub's examples include reproducing a bug when an issue is opened and starting an incident investigation when a monitoring tool detects a problem. The GitHub Docs page on automations sets the two types side by side:

Scroll sideways to see all 3 columns.

Comparison dimension	Personal automation	Shared automation
Who can see it	Only you	Everyone with read access to the repository
Who can edit it	Only you	Everyone with write access to the repository
Who is billed for AI credits	You	The organization or user that owns the repository
Identity used for actions on GitHub	Your identity	Copilot's identity

You pick the type when you create the automation, and you can't change it later. The rollout covers Copilot Pro, Pro+, Max, Business and Enterprise, and GitHub says availability may vary while it rolls out. Automations work only in private and internal repositories.

Shared automations fix the ownership gap in personal ones

Shared automations make the instruction visible to the whole team. In August, BaristaLabs covered how comment-triggered Copilot automations kept their definitions private to the creator, which left repository owners unable to inspect a standing instruction that could change code. A shared automation is visible to everyone with read access, and GitHub says change history shows "how the tools, triggers, and prompt have evolved."

It also outlives its author. Because the automation belongs to the repository, it "keeps running if the person who created them leaves the team." For a workflow the whole team depends on, such as triaging new issues, that is the main reason to choose shared over personal.

Two limits stay in place. GitHub's docs say automations are "stored separately from your repository's contents" and are "not committed to Git," so they are not reviewed through pull requests. For a definition that must go through code review, GitHub points to GitHub Agentic Workflows instead.

How do shared automations get billed?

Every run starts a Copilot cloud agent session that uses AI credits and GitHub Actions minutes. For a shared automation, the docs say AI credits are billed "to the organization that owns the repository, or to the repository owner's Copilot subscription if a personal account owns the repository." Actions minutes are billed separately to the repository owner.

In an organization-owned repository, a shared automation will not run until an administrator enables the "Allow use of Copilot cloud agent billed to the organization" policy. That policy is the control point. Turning it on means anyone with write access can create agent work that runs on a schedule or on repository events and bills the organization.

Each automation can carry its own AI credit limits:

• Per run: stops a run as soon as it reaches the limit. The minimum is 30 AI credits.
• Daily, weekly and monthly: stop new runs from starting once reached. They reset at 00:00 UTC each day, each Monday and on the first of the month.

GitHub's docs say the daily, weekly and monthly caps "don't stop a run that is already in progress." Only the per-run limit caps a single expensive run. Set the per-run ceiling as well as the period caps. For a related budget behavior, see how Copilot dynamic workflows keep spending against the same budget after a pause.

Who should turn on organization billing?

Organizations on Copilot Business or Enterprise with a recurring repository chore (issue reproduction, release notes, screenshot capture for review) are the clearest fit. A task that runs as a personal automation is tied to one engineer's identity and credits.

BaristaLabs' interpretation: hold off on the policy if more people have write access than you would trust to edit an unattended, organization-billed prompt, or if your Copilot budgets are already tight. Teams that already separate AI spend by setting more than one Copilot budget should treat shared automations as one more source of organization-billed agent sessions.

What GitHub already guards against

The safety defaults are reasonable, and most are worth keeping:

• Untrusted input: automations ignore events from users without write access by default, which reduces prompt injection from, for example, an outside contributor's issue. You can opt in to those events. Keep that off unless the task requires it.
• Extra pull request approval: if a repository requires at least one approval, pull requests from a shared automation need one more by default. Administrators can disable this in rulesets but not in branch protection rules.
• Workflow runs: Actions workflows do not run on an automation's pull request until someone with write access approves them.
• Transparent runs: anyone with read access can see the prompt, session logs and resulting pull requests, so never put a secret in a prompt.

One gap needs your attention. GitHub tools are limited to the automation's repository, but tools from MCP servers "can access whatever the server's configuration and credentials allow, which may include other repositories and external systems." Automations also inherit the repository's cloud agent secrets, firewall rules, custom instructions and skills.

Recommended first step

BaristaLabs recommends turning on organization billing for one repository's workflow before enabling it broadly. Pick a single recurring task, create it as a shared automation, grant only the GitHub tools it needs and no MCP tools at first, set a per-run limit and a monthly cap, and keep the default that ignores events from users without write access. Review a few weeks of sessions and credit use, then decide whether to allow more repositories. If budget increase requests start showing up from that repository, check its automations before raising the budget.

Sources and scope

• GitHub changelog, Build shared workflows for your team with Copilot Automations, Oct. 28, 2026.
• GitHub Docs, Copilot automations, read Oct. 29, 2026.

These sources describe the feature and its defaults. They don't give per-run credit costs for typical automations, and BaristaLabs has not run a shared automation for this post, so plan limits from your own first runs.