GitHub Universe 2026: What DevOps Engineers Need to Know

GitHub Universe 2026: What DevOps Engineers Need to Know

GitHub Universe 2026 ran on 28 and 29 October at Fort Mason Center in San Francisco and online. Before the event, I wrote down the questions I wanted to take into the sessions: how agents use context, how tool permissions are enforced, how generated work is evaluated, and how CI supply chains are defended. Across the two days, GitHub announced changes spanning Actions, Copilot, security, and everyday pull-request and issue workflows.

GitHub framed the keynote around an "agentic software delivery system", with changes at every layer of the stack: Git and infrastructure, Actions, security, Copilot, and licensing. This article covers the Day 1 announcements from 28 October and the Day 2 updates and product recap available by 30 October, through a DevOps lens.

A note on status before we start. Several announcements are generally available (GA), many are in public preview, and a few are experimental or still rolling out. I have marked the status of each one, because a preview is not something to build a production platform on without a fallback.

Day 1 and Day 2 at a glance

Announcement	Status	Why DevOps teams should care
GitHub Agentic Workflows	GA	Agent workflows that compile to Actions, with layered safeguards
Actions workflow lockfiles	GA	Pin action dependencies, with a policy to require lockfiles
Actions multi-cloud compute	Rolling out	Eligible Linux jobs may run on AWS; check IP allowlists
Flexible Actions compute entitlement	GA	One dollar-based pool for runners and Copilot cloud sandboxes
Copilot Automations (shared, triggers, cost limits)	Rolling out	Team-owned agent automation with credit limits per run and period
Agent Merge on pull requests	Available on paid Copilot plans	Copilot fixes failing workflows and merge conflicts
Copilot code review Max	Public preview	Multi-model review for high-risk changes
Copilot approvals	GA	Copilot can approve PRs, scoped by admins to file paths
AI Scan for repositories	Public preview	Agentic, whole-repository vulnerability scanning
Code scanning for AI applications	Public preview	Detects prompt injection and excessive agency in agent code
AI-detected secrets in push protection	Public preview	Blocks secrets with no predefined pattern
Package firewall	Public preview	Blocks malicious or risky npm packages before installation
Dependabot reachability analysis	Public preview	Shows whether your JavaScript code calls the vulnerable function
Public monitoring for enterprises	GA	Alerts when your secrets leak anywhere in public on GitHub
Copilot Memory	GA	Persistent context on paid plans
Copilot dreaming	Public preview	Proposes memory, instruction, and skill improvements via PRs
Copilot Fusion	GA	Effort-based model routing restricted to policy-enabled models
GitHub-verified MCP servers (connectors)	Public preview	Managed MCP connections across Copilot clients
Copilot included with GitHub Enterprise	Available via account teams	Budget-based AI usage instead of seat counting
Webhook delivery IP ranges in the Meta API	Updated 29 Oct	Update static inbound allowlists, or sync from the Meta API

1. GitHub Agentic Workflows are generally available

This was the headline for me. GitHub Agentic Workflows let you describe an automation in Markdown, which then compiles into a GitHub Actions workflow. They run on your existing runner groups and policies, using Copilot or another agent engine.

What makes this interesting for platform teams is the security model, which is layered rather than prompt-based:

• Agents read GitHub content through an integrity filter.
• They run with read-only permissions by default.
• They execute in a sandboxed container behind the Agent Workflow Firewall.
• Write operations go through safe outputs rather than direct write access.
• A threat detection job inspects proposed outputs before they are applied.

New at GA:

• Support for Actions Runner Controller (ARC) and Docker-in-Docker.
• gh aw forecast, which is no longer experimental. It estimates cost, including threat-detection credits, with monthly ranges.
• Model providers per workflow, and an gh aw add-wizard for setup.
• Model routing.
• Micro-VM isolation with Cloud Hypervisor, and enclaves for cross-repository workflows.

Agentic Workflows are available on Free, Team, and Enterprise plans. The default Copilot CLI engine needs a Copilot licence. In GitHub's announcement, Accenture reports production errors falling from about 11,000 a day to under 1,000. That is a customer quote, not an independent benchmark.

DevOps take: This is the answer to my pre-event question about enforcing authorisation at the tool boundary rather than in the prompt. Read-only defaults plus safe outputs is the right shape. Before you adopt it, run gh aw forecast on a candidate workflow and decide which runner group your agents may use.

Popular posts I have covered on this topic: For a walkthrough of building a workflow with safeguards, see From Markdown to Guarded Automation: Build Your First GitHub Agentic Workflow.

2. GitHub Actions: lockfiles GA, multi-cloud compute, and a shared entitlement

Workflow lockfiles are generally available

Workflow dependency lockfiles moved from public preview (14 October) to GA on Free, Team, and Enterprise Cloud, including data residency. The capabilities carried over from preview:

• The gh actions-lock extension generates .github/workflows/actions.lock, covering transitive action dependencies.
• You can onboard workflows one at a time.
• Dependabot regenerates the lockfile entry in the same pull request as an action update.
• Enterprise, organisation, and repository admins can enforce adoption with a Require lockfile policy.
• A stale-lockfile check can run in CI without modifying files.

GitHub is clear that lockfiles protect against unexpected changes, not unsafe code. Review a dependency before you lock it.

Popular posts I have covered on this topic: For the practical lockfile workflow, see GitHub Actions Workflow Lockfiles: Pin What Actually Runs.

Multi-cloud compute for hosted runners

GitHub Actions now schedules eligible jobs across a multi-cloud compute pool. In practice, eligible Linux jobs may run on AWS as well as Azure. This applies to standard 2-core and 4-core Linux runners, and to compatible larger runners without specialised configuration. It does not apply to Windows runners or runners with private networking.

Free, Pro, and Team customers are opted in automatically. Enterprise Cloud customers opt in under Enterprise settings > Actions > Hosted compute cloud providers.

Action to take now: if you rely on IP allowlists or Microsoft Entra Conditional Access policies that only allow Azure or Microsoft ranges, update them. Sync them with the actions array from GET https://api.github.com/meta instead of using provider-specific ranges. This is a rolling change, so do it before your jobs start landing in the new pool.

One flexible compute entitlement

As part of the new connected Copilot cloud experience, your included Actions entitlement becomes one dollar-based pool instead of a fixed number of runner minutes. It covers standard hosted runners, Copilot cloud sandboxes and, on Team and Enterprise Cloud, larger runners. Each product keeps its own rate. Billing for cloud sandboxes starts in November 2026 and draws from the same entitlement.

DevOps take: CI and agent sessions now compete for the same budget. Set budgets and alerts before November, and decide whether agent sandboxes should be allowed to consume CI capacity.

3. Copilot Automations become a team platform

Copilot Automations had several announcements on Day 1:

• Shared automations are rolling out. Anyone with read access can see them, and anyone with write access can edit them. Usage is billed to the repository owner, actions are attributed to Copilot, and the automation survives the creator leaving. An organisation must allow "Copilot cloud agent billed to the organization". You cannot change an automation between personal and shared after creation.
• New triggers, tools, and cost controls add the following:
  • A REST API trigger, so Jira, Sentry, or PagerDuty events can start an automation.
  • 24 new GitHub event triggers, including code scanning, secret scanning, and Dependabot alerts.
  • Chaining automations together.
  • 20 new tools, including merging pull requests and retrying workflow runs.
  • Custom MCP server tools.
  • AI credit limits per run, day, week, or month.
• Self-improving automations learn from outcomes, such as whether people change the labels an automation applied. They then propose prompt, tool, or trigger changes for a human to accept or reject.
• Create and manage automations in VS Code.

DevOps take: Shared automations are effectively a new class of CI-like workload, and they need the same governance. Anyone with write access can edit a shared automation that merges pull requests, so treat automation changes like workflow changes. Set credit limits from day one. When chaining, be careful with the "Users and Copilot" trigger option, because it allows one automation's output to start another.

Popular posts I have covered on this topic: For a hands-on look at running Copilot CLI in CI with bounded permissions and spend, see Run GitHub Copilot CLI in GitHub Actions Without PATs or Runaway AI Costs. For instrumenting Copilot activity beyond the automation outcome signals, see Agentic DevOps Needs Observability: Trace GitHub Copilot with OpenTelemetry.

4. Pull requests: Agent Merge, code review Max, and approvals

• Agent Merge now works on pull requests on github.com. Select Watch and fix in the merge box, and Copilot fixes failing Actions workflows, merge conflicts, or both, in a cloud environment. It can be combined with auto-merge.
• Copilot code review Max (public preview) runs several independent review agents across models from different providers. An aggregation agent then reconciles their findings. Max is slower and uses more AI credits than Lite or Balanced. Admins can set a maximum review effort level for an enterprise, organisation, or repository.
• Copilot approvals are now GA. They are off by default. Repository admins can choose which file paths Copilot may approve, and an approval is dismissed when new commits are pushed.

DevOps take: I wrote about Copilot approvals and branch protection when they were in preview. My advice has not changed: scope approvals to low-risk paths, and keep a human approval on workflows, infrastructure, and authentication code. Agent Merge plus auto-merge is powerful, so check that your rulesets still require the reviews you expect.

Popular posts I have covered on this topic: For broader review workflows, see Mastering Code Reviews with GitHub Copilot. For a DevOps-focused coding-agent workflow, see Using GitHub Copilot Coding Agent for DevOps Automation.

5. Security: AI Scan, secrets, and the package firewall

Security had a strong Day 1, and much of it targets the risks that agents introduce.

• AI Scan for repositories (public preview) is an agentic scanner that analyses the latest commit on the default branch within a fixed time budget. It covers languages CodeQL does not support and skips issues CodeQL already reports. Its alerts do not close automatically when you merge a fix, so rescan after merging. It consumes Code Security AI credits and does not need a Copilot licence.
• Code scanning for AI applications (public preview, requires GitHub Advanced Security) scans pull requests for indirect prompt injection, sensitive information disclosure, and excessive agency in agent code.
• Push protection for AI-detected secrets (public preview) blocks secrets that have no predefined format. In early results, it more than doubled the number of pushes where push protection caught a secret. It is off by default and consumes AI credits. GitHub also notes that agents must get authorisation before bypassing a block.
• Package firewall (public preview) sits between your endpoints and the npm registry. It applies enterprise policies such as:
  • blocking known malware;
  • blocking packages by advisory severity;
  • blocking attestation downgrades;
  • blocking newly introduced install scripts;
  • a minimum package age.

It protects CI runners, agent sessions, and developer machines.

• Dependabot reachability analysis (public preview, JavaScript and TypeScript, Enterprise Cloud) uses CodeQL call graphs to mark alerts as reachable, potentially reachable, or unreachable. It is free during the preview.
• Public monitoring for enterprises is now GA at no extra cost with Secret Protection. It alerts you when your secrets leak anywhere in public on GitHub, such as in personal forks or gists, and attributes each finding through enterprise membership or verified domains.
• The security extension for the Copilot app (public preview) brings code scanning alerts, Explain and Fix, and /security-review of local changes into the app. Fixes stay local until you commit them.

DevOps take: The package firewall and the minimum package age control are the ones I would pilot first. Agents install dependencies faster than humans review them, and a one-day cooldown on new versions is a cheap defence against fast-moving malware campaigns. Public monitoring is GA at no extra cost, so if you have Secret Protection, turn it on today.

Popular posts I have covered on this topic: For a hands-on test of Copilot's security-finding remediation, see Can Copilot Fix Its Own Security Findings?.

6. Context as infrastructure: Memory, dreaming, and connectors

GitHub intelligence brings together several context features:

• Copilot Memory is GA on paid plans.
• Copilot dreaming (public preview, opt-in, consumes credits) curates personal memory. It also proposes changes to repository skills, instructions, and code review customisation through pull requests.
• Cross-repository code search, including semantic search, and a /research command.

GitHub-verified MCP servers, or connectors (public preview), let you sign in once to services such as Slack, Sentry, Linear, Cloudflare, and Vercel. The connection then works across the Copilot app, CLI, VS Code, cloud sessions, and Mobile. Business and Enterprise organisations must enable the Editor preview features policy, and connectors must be added to any MCP allowlist.

DevOps take: Before the event I asked whether teams could version, test, and review shared context. Dreaming answers that by routing instruction and skill changes through pull requests, which keeps context under normal change control. Connectors reduce the effort of setting up MCP servers, but they also make it easier to connect production data to agents. Review your MCP allowlist before enabling them.

Popular posts I have covered on this topic: For practical guidance on reusable agent context, see GitHub Copilot Skills: Reusable AI Workflows for DevOps and SREs and GitHub Copilot Instructions vs Prompts vs Custom Agents vs Skills. For MCP extensions, see GitHub Copilot CLI Plugins and Marketplaces.

7. Copilot Fusion and model governance

Copilot Fusion is GA. You choose an effort level (Standard, High, or Max), and Fusion decides whether to use one model or to combine several, using Single, Cascade, or Critique workflows. It only uses models enabled by your policy, and admins can make it the default through enterprise managed settings. Usage is billed at each model's rate, with a limited-time 30% discount.

Local model selection in Fusion is an experimental preview. Routing still happens in the cloud, so it does not work offline, and local models may not have the same safety protections.

DevOps take: Fusion respects model policy, so your existing model allow-list is now also your Fusion control. Review it before making Fusion the default.

Popular posts I have covered on this topic: My practical guide to evaluating LLMs in GitHub Copilot covers model assessment; Project HydraFusion explores model routing in a DevOps workflow.

8. Where agents run: cloud sessions, the Copilot app, and IDEs

• The connected Copilot cloud experience and cloud sandboxes are GA on paid Copilot plans. Sessions move between web, Mobile, CLI, the Copilot app, VS Code, Slack, and Teams. Enterprise-managed settings for agent permissions and MCP allowlists apply to the cloud experience. Users without write access get read-only Copilot in that repository.
• The Copilot app adds Copilot Projects (public preview) for multi-repository goals and parallel agents. It also adds computer use (public preview), which requires approval per app and can be disabled through managed settings.
• VS Code adds the following:
  • Agent Host, so sessions survive closing the window and can run remotely.
  • Plugin and marketplace policies that let admins require or block plugins.
  • A default Copilot harness built on the Microsoft Copilot SDK.
• The GitHub Copilot SDK is becoming the Microsoft Copilot SDK. No immediate changes are needed, but expect package and namespace changes over time.

DevOps take: Computer use and remote Agent Host extend where an agent can act. Decide your managed settings policy for them now rather than after someone enables them.

Popular posts I have covered on this topic: For managing CLI sessions across devices, see Steer GitHub Copilot CLI Sessions Remotely from Any Device. If you are building your own agent experience, see GitHub Copilot SDK: Build AI-Powered DevOps Agents for Your Own Apps.

9. Licensing: Copilot included with GitHub Enterprise

GitHub Enterprise now includes access to GitHub Copilot for every licensed user, through a GitHub or Microsoft account team. Self-serve is coming in stages.

• Users without a GitHub Enterprise licence can use Copilot Standalone at $10 per user per month.
• There are no monthly AI credits per seat: AI usage is metered from the first request against your enterprise budget.
• Code completion keeps working with no budget, but Chat, code review, and cloud agents need available budget.
• Copilot Business and Copilot Enterprise remain available.

DevOps take: This moves the operational focus from seat counts to budgets, policies, and attribution. Between this, the shared Actions entitlement, and automation credit limits, FinOps for AI is now part of platform engineering.

10. The numbers: Octoverse 2026 and platform scale

Octoverse 2026 was published on Day 1. The figures most relevant to DevOps:

• GitHub Actions ran 124 million jobs a day, about 1,440 a second, more than three times last year.
• Over 40% of pull requests started with an agent by September, up from 17% in March.
• Push protection ran 5.8 billion scans, and more than 30 million Dependabot pull requests were merged.

The keynote post also described the following infrastructure changes:

• About 4 million CPU cores added this year.
• A migration to multi-region Azure, expected to complete early next year.
• A new Git architecture that decouples storage from compute.

Day 2 (29 October): operational updates and the developer workflow

The Day 2 item with the clearest immediate infrastructure action is small but important if you enforce inbound webhook IP allowlists.

GitHub webhook IP ranges added to the Meta API

On 29 October, GitHub added three IP ranges for webhook deliveries on github.com to the hooks field returned by the Meta API:

CIDR prefix	Added for
9.234.98.160/28	GitHub webhook deliveries
9.234.98.176/28	GitHub webhook deliveries
9.234.106.48/28	GitHub webhook deliveries

These ranges apply across GitHub.com plans, including GitHub Enterprise Cloud. If your firewall or webhook receiver uses a manually maintained static allowlist, add the new prefixes or you may reject valid deliveries. If you already refresh your allowlist from the Meta API, GitHub says no change is needed for this update.

DevOps take: avoid treating published IP ranges as static configuration. Have the receiving service or network control consume the hooks values from the Meta API through a controlled update process, validate changes before applying them, and alert on failed webhook deliveries. This is especially relevant if you are also adjusting allowlists for Actions' newly announced multi-cloud compute pool: webhook delivery ranges and Actions runner ranges serve different traffic and should not be conflated.

The Universe recap: a better issue-to-merge path

GitHub's Universe recap also groups several changes around keeping work, context, and review connected. They are useful to track, but their announcement dates are not all Day 2:

• Stacked pull requests (GA since 6 October): break a large change into smaller dependent pull requests, review them independently, and merge the stack together. GitHub's GA release also describes signed replacement commits during rebases, preservation of approvals for unchanged code, merge-queue support, and improvements to the gh stack extension. Auto-merge for stacks was described as rolling out over the following weeks, so check availability before depending on it.
• Issue artifacts (public preview, announced 28 October): attach Markdown plans, research, and root-cause analyses; links to external discussions; and HTML visualisations to an issue. The new gh issue artifact command can create, edit, list, view, download, and delete artifacts. The GitHub App can attach outputs from an issue session automatically. GitHub noted that creating and viewing HTML artifacts in the app was still coming soon.
• Attach images and video from GitHub CLI: gh issue create supports repeatable --attach flags. For example, gh issue create --title "Login regression" --body "See the attached reproduction." --attach "./login-error.png#Login error state" creates an issue with an image attachment. The CLI documentation allows up to 50 files per command; if some uploads fail, the issue can still be created and the command exits non-zero.
• Repository pull-request overview (GA since 21 September): the refreshed repository pull requests page helps teams scan open work, see its status, and find what needs attention. This is a workflow improvement, not a feature first released on Day 2.

DevOps take: these are not just UI conveniences. Stacked PRs can make large changes easier to review, while issue artifacts keep the plan and investigation attached to the work as it moves between people and agents. That improves hand-off and auditability, but it does not replace review: verify the stack merge rules, retain human review where required, and treat generated issue artifacts as editable project records.

What I would do next

1. Check webhook allowlists. Add the new prefixes if you maintain static rules, or confirm that your Meta API sync includes the hooks field and applies updates safely.
2. Pilot issue artifacts. Try a plan or root-cause analysis on a non-sensitive issue and see whether the artifact history improves hand-offs without duplicating your source of truth.
3. Review stacked-PR policy. Confirm required checks, signed-commit rules, stale-approval handling, and merge-queue behaviour in a representative repository before relying on auto-merge.
4. Update CLI usage. Where teams report bugs with screenshots or recordings, gh issue create --attach can make the report reproducible. Make sure attached media does not expose secrets or customer data.

Conclusion

Across both days, GitHub Universe 2026 reinforced that AI-assisted work is becoming part of the software delivery platform, not just an editor feature. Agents can run on shared compute, act on issues and pull requests, use connected tools, and consume budget. That makes them a platform engineering concern.

The controls deserve as much attention as the new capabilities: read-only defaults and safe outputs for Agentic Workflows, lockfile policies and package filtering for supply-chain risk, explicit model and credit limits for Copilot, and review requirements for automated pull-request changes. Many features remain in public preview or are rolling out, so check the status and plan requirements before building them into a production process.

The immediate Day 2 action is to update static webhook allowlists or verify that they follow GitHub's Meta API. For the broader workflow, pilot issue artifacts and stacked pull requests in repositories with clear ownership and review rules. Measure whether they improve hand-offs, review time, and operational outcomes rather than adopting them because they appeared in a keynote recap.

Author

Marcel.LupoFollow

Microsoft MVP in DevTech - DevOps | DevOps Architect | Technical speaker focused on Microsoft technologies, Agentic AI, IaC & automation in Azure. Find me on GitHub: https://github.com/Pwd9000-ML

Like, share, follow me on: 🐙 GitHub | 🐧 X | 👾 LinkedIn

Date: 30-10-2026