Updates, ideas, and inspiration from GitHub to help developers build and design software.
GitHub expands application security coverage with AI‑powered detections
CodeQL and AI‑powered detections work together in GitHub Code Security to identify vulnerabilities across more languages and frameworks. The post GitHub expands application security coverage with AI‑powered detections appeared first on The GitHub Blog.
AI is accelerating software development and expanding the range of languages and frameworks used in modern repositories. Security teams are increasingly responsible for protecting code written across many ecosystems, not just the core enterprise languages traditionally covered by static analysis. That’s why GitHub is introducing AI-powered security detections in GitHub Code Security to expand application security coverage across more languages and frameworks. These detections complement CodeQL by surfacing potential vulnerabilities in areas that are difficult to support with traditional static analysis alone. Public preview availability is planned for early Q2. Expanding application security coverage with static analysis and AI Static analysis remains an effective way to identify vulnerabilities in supported languages, which is why GitHub Code Security continues to rely on CodeQL for deep semantic analysis. But modern codebases often include scripts, infrastructure definitions, and application components built across many additional ecosystems. To address this reality, GitHub Code Security extends coverage by pairing CodeQL with AI-powered security detections across additional languages and frameworks. This hybrid detection model helps surface vulnerabilities—and suggested fixes—directly to developers within the pull request workflow. In internal testing, the system processed more than 170,000 findings over a 30-day period, with more than 80% positive developer feedback. Early results show strong coverage for ecosystems newly supported through AI-powered detections, including Shell/Bash, Dockerfiles, Terraform configurations (HCL), and PHP. This capability sits within GitHub’s broader agentic detection platform, which powers security, code quality, and code review experiences across the developer workflow. What begins as expanded coverage establishes a foundation for evolving detections over time, pairing the precision of static analysis with deeper context and new vulnerability insights that emerge as development continues to accelerate. Bringing expanded security coverage into pull requests Pull requests are where developers already review and approve changes, making them the most effective place to surface security risks early. When a pull request is opened, GitHub Code Security automatically analyzes the changes using the most appropriate detection approach, whether that is static analysis powered by CodeQL or AI-powered security detections. The results appear directly in the pull request alongside other code scanning findings, surfacing risks such as unsafe, string built SQL queries or commands, insecure cryptographic algorithms, and infrastructure configurations that expose sensitive resources. By integrating security detections into the pull request workflow, GitHub helps teams catch and fix vulnerabilities earlier, without asking developers to leave the tools and processes they already use. Turning expanded detection into review-ready fixes with Copilot Autofix Identifying vulnerabilities early is only part of the challenge. Security teams must also ensure those issues are fixed quickly and safely. GitHub Code Security connects detection to remediation with Copilot Autofix, which can suggest fixes that developers can review, test, and apply as part of the normal code review process. Developers are already using Autofix at scale. It has fixed more than 460,000 security alerts in 2025, reaching resolution in 0.66 hours on average compared to 1.29 hours without Autofix. Together, expanded detection and Copilot Autofix help teams move faster from finding risk to fixing it. Enforce security outcomes at the point of merge Because GitHub sits at the merge point of the development workflow, security teams can enforce outcomes where code is reviewed and approved, not after it ships. By bringing detection, remediation, and policy enforcement together in pull requests, GitHub helps teams reduce risk without slowing development. At RSAC, GitHub will preview how AI-powered security detections expand application security coverage directly within pull requests. This demonstration reflects a broader direction: starting with expanded coverage today, and evolving toward deeper, AI-augmented static analysis as part of GitHub’s agentic detection platform. Visit GitHub at RSAC booth #2327 to see how hybrid detection, developer-native remediation, and platform governance work together to secure modern software development. The post GitHub expands application security coverage with AI‑powered detections appeared first on The GitHub Blog.
Rethinking open source mentorship in the AI era
As contribution volume grows, mentorship signals are harder to read. The 3 Cs framework helps maintainers mentor more strategically... without burning out. The post Rethinking open source mentorship in the AI era appeared first on The GitHub Blog.
Let me paint a picture for you. A polished pull request lands in your inbox. It looks amazing at first glance, but then you start digging in, and a few things seem off. Forty-five minutes later, you’ve crafted a thoughtful, encouraging response with a few clarifying questions. Who knows: Maybe this person might be a great new person to mentor, so it’s worth your time if they put in theirs. And then…nothing. Or the follow-up makes it clear the contributor doesn’t have the context needed to explain the change, often because AI made it easy to submit something plausible before they were ready to maintain it. Or you realize you’ve just spent your afternoon debugging someone’s LLM chat session. This is becoming more common. Not because contributors are acting in bad faith, but because it’s never been easier to generate something that looks plausible. The cost to create has dropped. The cost to review hasn’t. Open source is experiencing its own “Eternal September”: a constant influx of contributions that strains the social systems we rely on to build trust and mentor newcomers. The signals have changed Projects across the ecosystem are seeing this same occurrence. tldraw closed their pull requests. Fastify shut down their HackerOne program after inbound reports became unmanageable at scale. The overall volume keeps climbing. The Octoverse 2025 report notes that developers merged nearly 45 million pull requests per month in 2025 (up 23% year over year). More pull requests, same maintainer hours. The old signals, like clean code, fast turnaround, and handling complexity, used to mean someone had invested time into understanding the codebase. Now AI can help users generate all of that in seconds, so these signals aren’t as telling. To reduce noise and bring more trust back into open source contributions, platforms, including GitHub, are building longer-term solutions. In fact, our product team just published an RFC for community feedback. If you have thoughts on what we can do, we’d love to hear from you. But platform changes take time. And even when they arrive, you’ll still need strategies for figuring out how mentorship looks today when signals aren’t as easy to read. Here’s what’s working. Why this is urgent Mentorship is how open source communities scale. If I asked a room of open source contributors how they got started, they’d all say it began with a good mentor. When you mentor someone well, you’re not just adding one contributor. You’re multiplying yourself. They learn to onboard others who do the same. That’s the multiplier effect. Year Broadcast (1,000/year) Mentorship (2 every 6 months, they do the same) 1 1,000 9 3 3,000 729 5 5,000 59,049 But maintainers are burning out trying to mentor everyone who sends a pull request. If we lose mentoring newcomers, we lose the multiplier entirely. We can’t abandon mentorship, especially as many long-time maintainers step back from active contribution. (I wrote more about this generational challenge in Who will maintain the future?) So, we need to be strategic about who we invest in. The 3 Cs: A framework for strategic mentorship at scale So how do you decide where to invest your mentorship energy when contribution signals are harder to read? Looking at what’s working across projects, I see three filters maintainers are using. I call them the 3 Cs: Comprehension, Context, and Continuity. 1. Comprehension Do they understand the problem well enough to propose this change? Some projects now test comprehension before code is submitted. Codex and Gemini CLI, for example, both recently added guidelines: contributors must open an issue and get approval before submitting a pull request. The comprehension check happens in that conversation. I’m also seeing in-person code sprints and hackathons thriving in this area, where maintainers can have real-time conversations with potential contributors to check both interest and comprehension. I’m not expecting contributors to understand the whole project. That’s unrealistic. But you want to make sure they’re not committing code above their own comprehension level. As they grow, they can always take on more. 2. Context Do they give me what I need to review this well? Comprehension is about their understanding. Context is about your ability to do your job as a reviewer. Did they link to the issue? Explain trade-offs? Disclose AI use? The last one is becoming more common. ROOST has a simple three-principle policy. The Processing Foundation added a checkbox. Fedora landed a lightweight disclosure policy after months of discussion. Disclosing AI is about giving reviewers context. When I know a pull request was AI-assisted, I can calibrate my review. This might mean asking more clarifying questions or focusing on whether the contributor understands the trade-offs, not just whether the code runs. There’s also AGENTS.md, which provides instructions for AI coding agents, like robots.txt for Copilot. Projects like scikit-learn, Goose, and Processing use AGENTS.md to tell agents instructions, like follow our guidelines, check if an issue is assigned, or respect our norms. This can help to place the burden of gathering the context needed for a review to the contributor (or their tools). 3. Continuity Do they keep coming back? This is the mentorship filter. Drive-by contributions can be helpful but limit your mentorship investment to people who come back and engage thoughtfully. Your mentorship can scale up over time: Great first conversation in a pull request → make your review a teachable moment They keep coming back → offer to pair on something, then start suggesting harder tasks If they still keep coming back → invite them to an event, or consider commit access The takeaway Comprehension and Context get you reviewed. Continuity gets you mentored. As a maintainer, this means: don’t invest deep mentorship energy until you see all three. What this looks like: PR Lands → Follows Guidelines? NO → Close. Guilt-free. YES → Review → They Come Back? YES → Consider Mentorship Let’s compare this to our first example above. This time, a polished pull requests lands without following the guidelines. Close it. Guilt-free. Protect your time for contributions that matter. If someone comes back and is engaged in issues; if they submit a second pull request and respond thoughtfully to feedback, now you pay attention. That’s when you invest. This is how you protect the multiplier effect. You’re not abandoning newcomers. You’re being strategic. There’s another benefit too: clear criteria reduces bias. When you rely on vibes, you tend to mentor people who look like you or share your cultural context. The 3 Cs give you a rubric instead of gut feelings, and that makes your mentorship more equitable. Getting started Pick a C to implement: C Implementation Comprehension Require issue before pull request Host an in-person code sprint for live discussions Context Add AI disclosure or AGENTS.md Continuity Watch who comes back Start with one but look for all three when deciding who to mentor. This isn’t about restricting AI-assisted contributions. It’s about building guardrails that protect human mentorship and keep communities healthy. AI tools are here to stay. The question is whether we adapt our practices to maintain what makes open source work: human relationships, knowledge transfer, and the multiplier effect. The 3 Cs give us a framework for exactly that. Resources GitHub RFC for platform-level solutions OpenAI Codex contribution policy Google Gemini CLI contribution policy ROOST AI policy Fedora AI contribution policy Processing AGENTS.md scikit-learn pull request template Goose HOWTOAI.md Adapted from my FOSDEM 2026 talk. Thanks to Anne Bertucio, Ashley Wolf, Daniel Stenberg, Tim Head, Bruno Borges, Emma Irwin, Helen Hou-Sandí, Hugo van Kemenade, Jamie Tanna, John McBride, Juan Luis Cano Rodríguez, Justin Wheeler, Matteo Collina, Camilla Moraes, Raphaël de Courville, Rizel Scarlett, and everyone who shared examples online. The post Rethinking open source mentorship in the AI era appeared first on The GitHub Blog.
How Squad runs coordinated AI agents inside your repository
An inside look at repository-native orchestration with GitHub Copilot and the design patterns behind multi-agent workflows that stay inspectable, predictable, and collaborative. The post How Squad runs coordinated AI agents inside your repository appeared first on The GitHub Blog.
If you’ve used AI coding tools before, you know the pattern. You write a prompt, the model misunderstands, you refine it, and you coax better output. Progress depends more on steering the model than on building the software. As projects grow, the challenge stops being “how do I prompt?” and starts becoming “how do I coordinate design, implementation, testing, and review without losing context along the way.” Multi-agent systems are a great way to move past this plateau, but usually require a massive amount of setup. People spend hours building orchestration layers, wiring up frameworks, and configuring vector databases before they can delegate a single task. Squad, an open source project built on GitHub Copilot, initializes a preconfigured AI team directly inside your repository. It is a bet that multi-agent development can be accessible, legible, and useful without requiring heavy orchestration infrastructure or deep prompt engineering expertise. Two commands—npm install -g @bradygaster/squad-cli once globally, squad init once per repo—and Squad drops a specialized AI team: a lead, frontend developer, backend developer, and tester directly against your repository. Instead of a single chatbot switching roles, Squad demonstrates repository native multi-agent orchestration without heavy centralized infrastructure. How Squad coordinates work across agents You describe the work you need done in natural language. From there, a coordinator agent inside Squad figures out the routing, loads repository context, and spawns specialists with task-specific instructions. For example, you type: “Team, I need JWT auth—refresh tokens, bcrypt, the works.” Then you watch the team spin up in parallel. The backend specialist takes the implementation. The tester starts writing the accompanying test suite. A documentation specialist opens a pull request. Within minutes, files are written and branches are created. These specialists already know your naming conventions and what you decided about database connections last Tuesday—not because you put it in the prompt, but because agents load from shared team decisions and their own project history files committed to the repository. Instead of forcing you to manually test the output and prompt the model through multiple rounds of fixes, Squad handles iteration internally. Once the backend specialist drafts the initial implementation, the tester runs their test suite against it. If those tests fail, the tester rejects the code. Crucially, the orchestration layer prevents the original agent from revising its own work. Squad’s reviewer protocol can prevent the original author from revising rejected work, and a different agent must step in to fix it. This forces genuine independent review with a separate context window and a fresh perspective, rather than asking a single AI to review its own mistakes. In workflows where reviewer automation is enabled, you review the pull request that survives this internal loop rather than every intermediate attempt. It’s not autopilot, and it’s not magic on session one. Agents will ask clarifying questions and sometimes make reasonable but wrong assumptions. You still review and merge every pull request. It is collaborative orchestration, not autonomous execution. Architectural patterns behind repository-native orchestration Whether you use Squad or build your own multi-agent workflows, there are a few architectural patterns we’ve learned from building repository-native orchestration. These patterns move the architecture away from “black box” behavior toward something inspectable and predictable at the repository level. 1. The “Drop-box” pattern for shared memory Most AI orchestration relies on real-time chat or complex vector database lookups to keep agents in sync. We’ve found that this is often too fragile; synchronizing state across live agents is a fool’s errand. Instead, Squad uses a “drop-box” pattern. Every architectural choice, like choosing a specific library or a naming convention, is appended as a structured block to a versioned decisions.md file in the repository. This is a bet that asynchronous knowledge sharing inside the repository scales better than real-time synchronization. By treating a markdown file as the team’s shared brain, you get persistence, legibility, and a perfect audit trail of every decision the team has made. Because this memory lives in project files rather than a live session, the team can also recover context after disconnects or restarts and continue from where it left off. 2. Context replication over context splitting One of the biggest hurdles in AI development is the context window limit. When a single agent tries to do everything, the “working memory” gets crowded with meta-management, leading to hallucinations. Squad solves this by ensuring the coordinator agent remains a thin router. It doesn’t do the work; it spawns specialists. Because each specialist runs as a separate inference call with its own large context window (e.g., up to 200K tokens on supported models), you aren’t splitting one context among four agents, you’re replicating repository context across them. Running multiple specialists in parallel gives you multiple independent reasoning contexts operating simultaneously. This allows each agent to “see” the relevant parts of the repository without competing for space with the other agents’ thoughts. 3. Explicit memory in the prompt vs. implicit memory in the weights We believe an AI team’s memory should be legible and versioned. You shouldn’t have to wonder what an agent “knows” about your project. In Squad, an agent’s identity is built primarily on two repository files: a charter (who they are) and a history (what they’ve done), alongside shared team decisions. These are plain text. Because these live in your .squad/ folder, the AI’s memory is versioned right alongside your code. When you clone a repo, you aren’t just getting the code; you are getting an already “onoboarded” AI team because their memory lives alongside the code directly in the repository. Lowering the barrier to multi-agent workflows Our biggest win with Squad is that it makes it easy for anyone to get started with agentic development in a low-touch, low-ceremony way. You shouldn’t have to spend hours wrestling with infrastructure, learning complex prompt engineering, or managing convoluted CLI interactions just to get an AI team to help you write code. To see what repository-native orchestration feels like, check out the Squad repository and throw a squad at a problem to see how the workflow evolves. The post How Squad runs coordinated AI agents inside your repository appeared first on The GitHub Blog.
Investing in the people shaping open source and securing the future together
See how GitHub is investing in open source security funding maintainers, partnering with Alpha-Omega, and expanding access to help reduce burden and strengthen software supply chains. The post Investing in the people shaping open source and securing the future together appeared first on The GitHub Blog.
Open source has always been about community. It’s about maintainers who review pull requests late at night. Volunteers who respond to security reports from strangers. And communities that quietly power the world’s software. The reality behind the commits is that maintainers get stretched thin. The effort of responding to pull requests and comments, while also being expected to merge and ship, adds up quickly. Late nights turn into burnout, one-person projects become critical infrastructure overnight without even realizing it, and “thank you” doesn’t pay the bills. Plus, AI is an accelerating force that’s changing how the open source community secures the ecosystem. The requirements of always-on security take more time and energy in addition to not always having the knowledge and expertise. At GitHub, we believe supporting open source means more than hosting code. It means investing in the people who maintain it, giving them the tools they need to succeed, and standing with them as the ecosystem evolves rapidly in the AI era. Open source maintainers deserve better support and security, and we’re listening and investing. Strengthening open source security, together Today, we are joining Anthropic, Amazon Web Services (AWS), Google, and OpenAI with a combined commitment of $12.5 million to support the Linux Foundation’s Alpha-Omega initiative to advance open source security. This collaboration is aimed at helping maintainers make emerging AI security capabilities accessible and integrated into existing project workflows, and at further advancing our OSS security programs, to strengthen the security of critical open source software projects. This effort builds on years of GitHub’s work as a steward of open source and software security. Real impact comes from pairing investment with practical tools, education, and long-term support designed to help maintainers. Today, over 280,000 maintainers on GitHub across hundreds of millions of public repositories are eligible for free access to core GitHub platform services, GitHub Copilot Pro, GitHub Actions, and security capabilities, like code scanning and Autofix, secret scanning, push protection, and dependency alerts. Our GitHub Security Lab works with the open source community to educate and protect at scale against the most common threats, and it publishes security advisories that help the entire ecosystem respond faster. On top of recent and ongoing support across our core platform and GitHub Copilot, we are also reaffirming our commitment to helping maintainers to secure their open source projects by announcing: GitHub Secure Open Source Fund is adding an additional $5.5 million in Azure credits and funding to provide training and expertise; community to improve outcomes; and new partners, including Datadog, Open WebUI, Atlantic Council, and OWASP. GitHub Security Lab is investing in the security advisory experience on GitHub and Private Vulnerability Reporting (PVR) features to reduce the burden of low-quality reports to help maintainers manage the increasing volume of security reports. We have learned through programs like the GitHub Secure Open Source Fund that the most effective security outcomes happen when you link maintainer funding and resources to specific outcomes like improving security. After supporting 138 projects with over 200 maintainers across 38 countries, we have seen 191 new CVEs issued, 250+ new secrets prevented from leaking, and 600+ leaked secrets detected and resolved, impacting billions of monthly downloads from alumni projects. We also learned that providing hands-on coding with education and expertise, drives self-reported learning and action. The outcome: when maintainers are empowered rather than overwhelmed, given time to learn with space to focus, and provided access to tools that fit naturally into their workflows, security improves for everyone downstream. This creates a community reinforcement flywheel. Those lessons shape everything we are doing next. This work centers on helping maintainers defend and secure the projects that underpin the global software supply chain, at a time when AI is fundamentally changing both how vulnerabilities are discovered and how they are exploited. Putting AI to work for maintainers AI has dramatically increased the speed and scale of vulnerability discovery. That’s true for defenders and for attackers. Now, more than ever, maintainers sit on the front lines of software security. They often face a surge of automated pull requests and security reports with low signal-to-noise ratio. The result is increasing burnout. As Christian Grobmeier, maintainer for Log4j, put it: “our AI has to be better than the attacking AI.” We agree. That is why our focus is not just on finding more issues. It is on helping maintainers triage, understand, and fix them effectively, without losing the joy or sustainability of maintaining open source. For example, our recent AI-powered security research framework was open sourced because we believe it should be used to empower maintainers and not only security teams. Looking ahead, GitHub will continue investing in tools like pull request controls, while also ensuring AI is a force multiplier for maintainers from issue triage, pull request reviews, security vulnerability identification, and remediation, and more. It should not be another source of pressure. Maintainers of impactful open source projects already have access to Copilot Pro, which includes AI-assisted code review, agentic security remediation workflows, and access to a broad set of leading models all designed to help maintainers find and remediate risks faster. AI should reduce maintainer burden, not increase it. Our goals are simple: Meeting maintainers where they already work on GitHub Helping prioritize actual issues over noise Accelerating fixes, not just findings Supporting secure defaults and healthy workflows We will continue refining this alongside the community, informed by real world feedback and outcomes. Open source is a shared responsibility No single company or group can secure open source alone. The software we all depend on is built by a global community, and protecting it requires collaboration across ecosystems and global economies. By working with maintainers and partners like Alpha-Omega, we aim to scale impact without fragmenting effort. By pairing GitHub’s platform, tools, and programs with shared community governance and trust, and providing maintainers with the latest models and AI-assisted coding tools, we can achieve this. Most importantly, we are still committed to investing in people, not just projects. Because open source thrives when maintainers are supported, respected, and empowered to do their best work. We are grateful to every maintainer building the future with us. Activate the tools available, and consider applying for GitHub Secure OSS Fund. Session 4 runs late April with each project receiving $10,000, Copilot Pro, $100K of Azure Credits, and 3 weeks of security education and a dedicated community. As always, your feedback helps shape what we build next. The post Investing in the people shaping open source and securing the future together appeared first on The GitHub Blog.
GitHub for Beginners: Getting started with GitHub Actions
Set up your first GitHub Actions workflow in this how-to guide. The post GitHub for Beginners: Getting started with GitHub Actions appeared first on The GitHub Blog.
Welcome back to our ongoing GitHub for Beginners series, now in its third season! Our previous episode was the first of the season, and we talked about getting started with GitHub Issues and Projects. This time we’re jumping into another very popular GitHub feature called GitHub Actions. By the end of this post, you’ll know how to use GitHub Actions and will have created your first automated workflow. As always, if you prefer to watch the video or want to reference it, we have all of our GitHub for Beginners episodes available on YouTube. (And you can watch the full video of this tutorial above!) What are GitHub Actions? GitHub Actions is a Continuous Integration/Continuous Delivery (CI/CD) and automation platform built right into GitHub. You’ll often hear people call these “action workflows” or just “workflows.” It allows you to automate repetitive tasks and deployment processes using YAML files stored in your repository. You might use GitHub Actions for tasks like running vulnerability scans, tests, creating releases, or even reminding your team about important updates. Action workflows are triggered by GitHub events like pushes, pull requests, or schedules, and they run in a virtual environment. How workflows work Before jumping right into the details about how workflows do their job, we need to define some essential terms. Event: A specific activity that triggers a workflow (e.g., pushing code, opening a pull request, creating an issue, etc.) Hosted runners: A virtual machine that executes jobs in a workflow. GitHub provides hosted runners, or you can set up your own self-hosted runners. Jobs: A set of steps executed within the same runner. Each step is either a shell command or a prebuilt action from the GitHub Marketplace. Workflows are triggered by events in a repository. This can be something like a pull request, merging a branch, or even opening an issue. When you create the workflow, you determine what the triggering event is. When that event fires and triggers the workflow, GitHub spins up one or more jobs that execute on a runner. GitHub then follows the steps you programmed into the workflow until it reaches the end. And it does this all on its own, without any interaction necessary on your behalf. This is essentially how the GitHub Action workflow works. Want more practice creating your own workflows and getting more familiar with GitHub Actions? Try out the Hello GitHub Actions skill exercise in our skills repository. Looking at a repository’s actions Navigate to our sample repository, fork it, then select the Actions tab at the top. This page lists all of the current workflows for the repository. Select the green New workflow button in the left-hand column. This brings you to a new page, which presents several suggested workflows for this repository. Select the Configure button for one of the suggested actions. For right now, it doesn’t matter which one you select. This pulls up an editor with a template written in YAML with three main sections you need to know when building an action workflow: Name: Describes what your workflow does. On: Defines what triggers the workflow. Jobs: Where the actual work associated with this workflow happens. Building a workflow One of the best ways to learn is by doing, so let’s go ahead and create a simple workflow that will automatically label new issues created in our repository. First, head back to the main page for the sample repository and clone it to your machine. Then, navigate to the action-start branch. GitHub Actions uses YAML syntax to define workflows. Each workflow is stored in a .yml file in a special .github\workflows directory in your repository. Go ahead and navigate to that directory. When creating workflow files, you should use descriptive names that tell you what they do at a glance (e.g., build-and-test.yml, security-scanner.yml). Since we know that we want to have this workflow label new issues, create a new file in this directory and call it label-new-issue.yml. Add the following to the top of the file: Name: Label New Issues Now we need to decide what will trigger this workflow. GitHub has tons of trigger options, all of which are listed in our trigger workflows reference documentation, so you can choose based on what you’re building. In our case, we specifically want to have this workflow trigger whenever someone opens an issue. We do this by adding the following code to the bottom of the YAML file. on: issues: types: [opened] Now we get to the good stuff: the jobs section, where the actual work happens. The first thing we’ll do is give our job a title and choose what type of machine runs it. GitHub provides hosted runners with different versions of Ubuntu, Windows, and macOS. Let’s call this job label-issues and run it on ubuntu-latest. This tells GitHub to grab a machine from their pool of Ubuntu runners using the latest version available. We also need to add permissions so the action can read the content of the repository and add the label. When we use the permissions keyword inside of a job, all actions and run commands within that job gain the access rights specified. jobs: label-issues: runs-on: ubuntu-latest permissions: issues: write contents: read Okay, now we need to add the actual steps. This is where we define what happens in the job. steps: - name: Checkout repository uses: actions/checkout@v6 - name: Add triage label env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} ISSUE_NUMBER: ${{ github.event.issue.number }} LABEL: "triage" run: gh issue edit "$ISSUE_NUMBER" --add-label "$LABEL" You’ll see two main keywords here: uses and run. When you see uses, that’s pulling in a prebuilt action from the GitHub Marketplace. These are open-source reusable actions that handle common tasks, so you don’t have to write everything from scratch. Some examples of these type of actions include checking out your code or setting up NodeJS. When you see run, that’s executing a command or script. This same keyword is used if it’s just a single line of code or a script that spans multiple lines. The env section is where we define our environment variables. Since we are using the GitHub CLI in our run section, we need to provide an access token for the action to be able to access the repository. We do this by setting the GH_TOKEN environment variable. GitHub automatically provides a temporary access token when it creates this job and provides it in the GITHUB_TOKEN variable. We also need to have variables to indicate which issue we want to update, as well as which label we want to add. In order for this to work, that label needs to already exist in the repository. Congratulations! You’ve now successfully completed authoring your first workflow! Testing your workflow Now that we have the workflow, it’s time to test it. In order to do so, we first need to push these changes up to the repository and merge them into the main branch. So go ahead and do that now. Once it’s in the main branch, we can see it in action. If you have any questions about how to push your code, you can check out our earlier GitHub for Beginners episode about adding code to your repository. Once your workflow is uploaded, let’s see it work. Navigate to the repository in your browser, and select the Issues tab. In the top-right corner, select the green New issue button. Provide a title and description indicating that you’re testing the workflow, and then click Create at the bottom of the window. GitHub will create the issue and automatically bring you to the page showing the issue’s history. Assuming everything is working correctly, you’ll see the triage label added within seconds of when you created the issue. Nice work! You can now see how convenient it can be to have some actions automatically handle tasks based on specific triggers. Reviewing current workflows Select the Actions tab at the top of the window. You’ll see all of the actions listed in a column on the left-hand side of the window. Select Label New Issues to filter the view to show just the times this workflow has run. Select the top workflow, which should be for the test issue you created in the previous step. This brings you to a detail page where you can see more information about this specific instance of the workflow. Select label-issues in the main window. Now you can see all of the steps taken in order to complete the workflow. This can be very useful for debugging purposes if one of your workflows is not working as expected. If you want to rerun this workflow, you can do so by clicking the Re-run all jobs button in the top-right. If there’s ever a situation where you need to pause a workflow, you can do that from the Actions tab. Navigate back to that tab, and once again select Label New Issues in the left column. Click the three dots (…) in the window on the right, next to the search box. One of the options is Disable workflow. If you select this, it will stop the workflow from running, but it will still exist in the repository, so you can enable it later. The Actions tab is where you’ll go to see and manage all of your workflows. You can check deployments, runners, metrics, performance, and caches all from this view. You can also view and edit your workflow files directly from this tab. What’s next? GitHub Actions can do a lot more than just label your issues. You can create actions to publish packages, greet new contributors, build and test your code, and even run security checks. Keep learning about GitHub Actions by checking out our GitHub Actions documentations and start experimenting with creating your own workflows. Happy coding! Ready to level up? Check out these hands-on GitHub Skills exercises to get you building fast automate workflows with GitHub Actions > The post GitHub for Beginners: Getting started with GitHub Actions appeared first on The GitHub Blog.
Continuous AI for accessibility: How GitHub transforms feedback into inclusion
AI automates triage for accessibility feedback, allowing us to focus on fixing barriers—turning a chaotic backlog into continuous, rapid resolutions. The post Continuous AI for accessibility: How GitHub transforms feedback into inclusion appeared first on The GitHub Blog.
For years, accessibility feedback at GitHub didn’t have a clear place to go. Unlike typical product feedback, accessibility issues don’t belong to any single team—they cut across the entire ecosystem. For example, a screen reader user might report a broken workflow that touches navigation, authentication, and settings. A keyboard-only user might hit a trap in a shared component used across dozens of pages. A low vision user might flag a color contrast issue that affects every surface using a shared design element. No single team owns any of these problems—but every one of them blocks a real person. These reports require coordination that our existing processes weren’t originally built for. Feedback was often scattered across backlogs, bugs lingered without owners, and users followed up to silence. Improvements were often promised for a mythical “phase two” that rarely materialized. We knew we needed to change this. But before we could build something better, we had to lay the groundwork—centralizing scattered reports, creating templates, and triaging years of backlog. Only once we had that foundation in place could we ask: How can AI make this easier? The answer was an internal workflow, powered by GitHub Actions, GitHub Copilot, and GitHub Models, that ensures every piece of user and customer feedback becomes a tracked, prioritized issue. When someone reports an accessibility barrier, their feedback is captured, reviewed, and followed through until it’s addressed. We didn’t want AI to replace human judgment—we wanted it to handle repetitive work so humans could focus on fixing the software. This is how we went from chaos to a system where every piece of accessibility feedback is tracked, prioritized, and acted on—not eventually, but continuously. Accessibility as a living system Continuous AI for accessibility weaves inclusion into the fabric of software development. It’s not a single product or a one-time audit—it’s a living methodology that combines automation, artificial intelligence, and human expertise. This philosophy connects directly to our support for the 2025 Global Accessibility Awareness Day (GAAD) pledge: strengthening accessibility across the open source ecosystem by ensuring user and customer feedback is routed to the right teams and translated into meaningful platform improvements. The most important breakthroughs rarely come from code scanners—they come from listening to real people. But listening at scale is hard, which is why we needed technology to help amplify those voices. We built a feedback workflow that functions less like a static ticketing system and more like a dynamic engine—leveraging GitHub products to clarify, structure, and track user and customer feedback, turning it into implementation-ready solutions. Designing for people first Before jumping into solutions, we stepped back to understand who this system needed to serve: Issue submitters: Community managers, support agents, and sales reps submit issues on behalf of users and customers. They aren’t always accessibility experts, so they need a system that guides them and teaches accessibility concepts in the flow of work. Accessibility and service teams: Engineers and designers responsible for fixes need structured, actionable data—reproducible steps, WCAG mapping, severity scores, and clear ownership. Program and product managers: Leadership needs visibility into pain points by category, trends, and progress over time to allocate resources strategically. With these personas in mind, we knew we wanted to 1) treat feedback as data flowing through a pipeline and 2) build a system able to evolve with us. How feedback flows With that foundation set, we built an architecture around an event-driven pattern, where each step triggers a GitHub Action that orchestrates what comes next—ensuring consistent handling no matter where the feedback originates. We built this system largely by hand starting in mid-2024. Today, tools like Agentic Workflows let you create GitHub Actions using natural language—meaning this kind of system could be built in a fraction of the time. The workflow reacts to key events: Issue creation launches GitHub Copilot analysis via the GitHub Models API, status changes initiate hand-offs between teams, and resolution triggers submitter follow-up with the user. Every Action can also be triggered manually or re-run as needed—automation covers the common path, while humans can step in at any point. Feedback isn’t just captured—it continuously flows through the right channels, providing visibility, structure, and actionability at every stage. *Click images to enlarge. <img data-recalc-dims="1" fetchpriority="high" decoding="async" width="1395" height="244" src="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.19-PM.png?resize=1395%2C244" alt="A left-to-right flowchart showing the seven steps of the feedback workflow in sequence: Intake, Copilot Analysis, Submitter Review, Accessibility Team Review, Link Audits, Close Loop, and Improvement. Feedback loops show that Submitter Review can re-run Copilot Analysis, Close Loop can return to Accessibility Team Review, and Improvement feeds updated prompts back to Copilot Analysis." class="wp-image-94454" srcset="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.19-PM.png?w=1395 1395w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.19-PM.png?w=300 300w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.19-PM.png?w=768 768w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.19-PM.png?w=1024 1024w" sizes="(max-width: 1000px) 100vw, 1000px" /> 1. Actioning intake Feedback can come from anywhere—support tickets, social media posts, email, direct outreach—but most users choose the GitHub accessibility discussion board. It’s where they can work together and build community around shared experiences. Today, 90% of the accessibility feedback flows through that single channel. Because posts are public, other users can confirm the problem, add context, or suggest workarounds—so issues often arrive with richer detail than a support ticket ever could. Regardless of the source, every piece of feedback gets acknowledged within five business days, and even feedback we can’t act on gets a response pointing to helpful resources. When feedback requires action from internal teams, a team member manually creates a tracking issue using our custom accessibility feedback issue template. Issue templates are pre-defined forms that standardize how information is collected when opening a new issue. The template captures the initial context—what the user reported, where it came from, and which components are involved—so nothing is lost between intake and triage. This is where automation kicks in. Creating the issue triggers a GitHub Action that engages GitHub Copilot, and a second Action adds the issue to a project board, providing a centralized view of current status, surfacing trends, and helping identify emerging needs. <img data-recalc-dims="1" decoding="async" width="1393" height="580" src="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.29-PM.png?resize=1393%2C580" alt="A left-to-right flowchart where user or customer feedback enters through Discussion Board, Support Ticket, Social Media, Email, or Direct Outreach, moves to an Acknowledge and Validate step, branches at a validity decision, and either proceeds to Create Issue or loops back through Request More Details to the user." class="wp-image-94455" srcset="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.29-PM.png?w=1393 1393w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.29-PM.png?w=300 300w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.29-PM.png?w=768 768w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.29-PM.png?w=1024 1024w" sizes="(max-width: 1000px) 100vw, 1000px" /> 2. GitHub Copilot analysis With the tracking issue created, a GitHub Action workflow programmatically calls the GitHub Models API to analyze the report. We chose stored prompts over model fine-tuning so that anyone on the team can update the AI’s behavior through a pull request—no retraining pipeline, no specialized ML knowledge required. We configured GitHub Copilot using custom instructions developed by our accessibility subject matter experts. Our prompt serves two roles: triage analysis, which classifies issues by WCAG violation, severity, and affected user group, and accessibility coaching, where GitHub Copilot acts as a subject-matter expert to help teams write and review accessible code. These instruction files point to our accessibility policies, component library, and internal documentation that details how we interpret and apply WCAG success criteria. When our standards evolve, the team updates the markdown and instruction files via pull request—the AI’s behavior changes with the next run, not the next training cycle. For a detailed walkthrough of this approach, see our guide on optimizing GitHub Copilot custom instructions for accessibility. The automation works in two steps. First, an Action fires on issue creation and triggers GitHub Copilot to analyze the report. GitHub Copilot populates approximately 80% of the issue’s metadata automatically—over 40 data points including issue type, user segment, original source, affected components, and enough context to understand the user’s experience. The remaining 20% requires manual input from the team member. GitHub Copilot then posts a comment on the issue containing: A summary of the problem and user impact Suggested WCAG success criteria for potential violations Severity level (sev1 through sev4, where sev1 is critical) Impacted user groups (screen reader users, keyboard users, low vision users, etc.) Recommended team assignment (design, engineering, or both) A checklist of low-barrier accessibility tests so the submitter can verify the issue Then a second Action fires on that comment, parses the response, applies labels based on the severity GitHub Copilot assigned, updates the issue’s status on the project board, and assigns it to the submitter for review. If GitHub Copilot’s analysis seems off, anyone can flag it by opening an issue describing what it got wrong and what it should have said—feeding directly into our continuous improvement process. <img data-recalc-dims="1" decoding="async" width="1392" height="405" src="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.46-PM.png?resize=1392%2C405" alt="A left-to-right flowchart where a newly created issue triggers Action 1, which feeds the report along with custom instructions and WCAG documentation into Copilot Analysis. Copilot posts a comment with its findings, then Action 2 parses that comment and branches into four parallel outcomes: applying labels, applying metadata, adding to the project board, and assigning the submitter." class="wp-image-94457" srcset="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.46-PM.png?w=1392 1392w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.46-PM.png?w=300 300w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.46-PM.png?w=768 768w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.46-PM.png?w=1024 1024w" sizes="(max-width: 1000px) 100vw, 1000px" /> 3. Submitter review Before we act on GitHub Copilot’s recommendations, two layers of review happen—starting with the issue submitter. The submitter attempts to replicate the problem the user reported. The checklist GitHub Copilot provides in its comment guides our community managers, support agents, and sales reps through expert-level testing procedures—no accessibility expertise required. Each item includes plain-language explanations, step-by-step instructions, and links to tools and documentation. Example questions include: Can you navigate the page using only a keyboard? Press “Tab” to move through interactive elements. Can you reach all buttons, links, and form fields? Can you see where your focus is at all times? Do images have descriptive alt text? Right-click an image and select “Inspect” to view the markup. Does the alt attribute describe the image’s purpose, or is it a generic file name? Are interactive elements clearly labeled? Using a screen reader, navigate to a button or link. Is its purpose announced clearly? Alternatively, review the accessibility tree in your browser’s developer tools to inspect how elements are exposed to assistive technologies. If the submitter can replicate the problem, they mark the issue as reviewed, which triggers the next GitHub Action. If they can’t reproduce it, they reach out to the user for more details. Once new information arrives, the submitter can re-run the GitHub Copilot analysis—either by manually triggering the Action from the Actions tab or by removing and re-adding the relevant label to kick it off automatically. AI provides the draft, but humans provide the verification. <img data-recalc-dims="1" loading="lazy" decoding="async" width="1394" height="196" src="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.54-PM.png?resize=1394%2C196" alt="A left-to-right flowchart where the submitter receives the issue with Copilot’s checklist, attempts to replicate the problem, and reaches a decision. If replicable, the issue is marked as reviewed and moves to the accessibility team. If not replicable, the submitter contacts the user for more details. When new information arrives, the submitter re-runs Copilot analysis, which loops back to the replication step." class="wp-image-94458" srcset="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.54-PM.png?w=1394 1394w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.54-PM.png?w=300 300w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.54-PM.png?w=768 768w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.37.54-PM.png?w=1024 1024w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> 4. Accessibility team review Once the submitter marks the issue as reviewed, a GitHub Action updates its status on the workflow project board and adds it to a separate accessibility first responder board. This alerts the accessibility team—engineers, designers, champions, testing vendors, and managers—that GitHub Copilot’s analysis is ready for their review. The team validates GitHub Copilot’s analysis—checking the severity level, WCAG mapping, and category labels—and corrects anything the AI got wrong. When there’s a discrepancy, we assume the human is correct. We log these corrections and use them to refine the prompt files, improving future accuracy. Once validated, the team determines the resolution approach: Documentation or settings update: Provide the solution directly to the user. Code fix by the accessibility team: Create a pull request directly. Service team needed: Assign the issue to the appropriate service team and track it through resolution. With a path forward set, the team marks the issue as triaged. An Action then reassigns it to the submitter, who communicates the plan to the user—letting them know what’s being done and what to expect. <img data-recalc-dims="1" loading="lazy" decoding="async" width="1390" height="195" src="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.02-PM.png?resize=1390%2C195" alt="A left-to-right flowchart where a reviewed issue triggers an Action that updates the project board and adds it to the first responder board. The accessibility team validates Copilot’s analysis, logs any corrections, then determines a resolution: provide documentation, create a code fix, or assign to a service team. All three paths converge at marking the issue as triaged, which triggers an Action that reassigns it to the submitter to communicate the plan to the user." class="wp-image-94459" srcset="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.02-PM.png?w=1390 1390w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.02-PM.png?w=300 300w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.02-PM.png?w=768 768w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.02-PM.png?w=1024 1024w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> 5. Linking to audits As part of the review process, the team connects user and customer feedback to our formal accessibility audit system. Roughly 75–80% of the time, reported issues correspond to something we already know about from internal audits. Instead of creating duplicates, we find the existing internal audit issue and add a customer-reported label. This lets us prioritize based on real-world impact—a sev2 issue might technically be less critical than a sev1, but if multiple users are reporting it, we bump up its priority. If the feedback reveals something new, we create a new audit issue and link it to the tracking issue. <img data-recalc-dims="1" loading="lazy" decoding="async" width="1392" height="183" src="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.13-PM.png?resize=1392%2C183" alt="A left-to-right flowchart where the team checks whether an existing audit issue covers the reported problem. If one exists, they link it and add a customer-reported label. If not, they create a new audit issue and link it. Both paths converge at updating priority based on real-world impact." class="wp-image-94460" srcset="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.13-PM.png?w=1392 1392w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.13-PM.png?w=300 300w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.13-PM.png?w=768 768w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.13-PM.png?w=1024 1024w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> 6. Closing the loop This is the most critical step for trust. Users who take the time to report accessibility barriers deserve to know their feedback led to action. Once a resolution path is set, the submitter reaches out to the original user to let them know the plan—what’s being fixed, and what to expect. When the fix ships, the submitter follows up again and asks the user to test it. Because most issues originate from the community discussion board, we post confirmations there for everyone to see. If the user confirms the fix works, we close the tracking issue. If the fix doesn’t fully address the problem, the submitter gathers more details and the process loops back to the accessibility team review. We don’t close issues until the user confirms the fix works for them. <img data-recalc-dims="1" loading="lazy" decoding="async" width="1389" height="172" src="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.22-PM.png?resize=1389%2C172" alt="A left-to-right flowchart where the submitter communicates the resolution plan to the user and monitors until the fix ships. The user is asked to test the fix. If it works, the issue is closed. If it doesn’t, the submitter gathers more details and the process loops back to the accessibility team review." class="wp-image-94461" srcset="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.22-PM.png?w=1389 1389w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.22-PM.png?w=300 300w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.22-PM.png?w=768 768w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.22-PM.png?w=1024 1024w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> 7. Continuous improvement The workflow doesn’t end when an issue closes—it feeds back into itself. When submitters or accessibility team members spot inaccuracies in GitHub Copilot’s output, they open a new issue requesting a review of the results. Every GitHub Copilot analysis comment includes a link to create this issue at the bottom, so the feedback loop is built into the workflow itself. The team reviews the inaccuracy, and the correction becomes a pull request to the custom instruction and prompt files described earlier. We also automate the integration of new accessibility guidance. A separate GitHub Action scans our internal accessibility guide repository weekly and incorporates changes into GitHub Copilot’s custom instructions automatically. The goal isn’t perfection—it’s continuous improvement. Each quarter, we review accuracy metrics and refine our instructions. These reviews feed into quarterly and fiscal year reports that track resolution times, WCAG failure patterns, and feedback volume trends—giving leadership visibility into both progress and persistent gaps. The system gets smarter over time, and now we have the data to show it. <img data-recalc-dims="1" loading="lazy" decoding="async" width="1393" height="199" src="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.29-PM.png?resize=1393%2C199" alt="A left-to-right flowchart with two parallel loops. In the first, an inaccuracy is spotted, a review issue is opened, the team creates a pull request to update the prompt files, and the changes merge to improve future analyses. In the second, a weekly Action scans the accessibility guide repository and auto-updates Copilot's custom instructions. Both loops feed into quarterly reviews that produce fiscal year reports tracking resolution times, WCAG failure patterns, and feedback volume trends." class="wp-image-94462" srcset="https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.29-PM.png?w=1393 1393w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.29-PM.png?w=300 300w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.29-PM.png?w=768 768w, https://github.blog/wp-content/uploads/2026/03/Screenshot-2026-03-11-at-12.38.29-PM.png?w=1024 1024w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> Impact in numbers A year ago, nearly half of accessibility feedback sat unresolved for over 300 days. Today, that backlog isn’t just smaller—it’s gone. And the improvements don’t stop there. 89% of issues now close within 90 days (up from 21%) 62% reduction in average resolution time (118 days → 45 days) 70% reduction in manual administrative time 1,150% increase in issues resolved within 30 days (4 → 50 year-over-year) 50% reduction in critical sev1 issues 100% of issues closed within 60 days in our most recent quarter We track this through automated weekly and quarterly reports generated by GitHub Actions—surfacing which WCAG criteria fail most often and how resolution times trend over time. Beyond the numbers A user named James emailed us to report that the GitHub Copilot CLI was inaccessible. Decorative formatting created noise for screen readers, and interactive elements were impossible to navigate. A team member created a tracking issue. Within moments, GitHub Copilot analyzed the report—mapping James’s description to specific technical concepts, linking to internal documentation, and providing reproduction steps so the submitter could experience the product exactly as James did. With that context, the team member realized our engineering team had already shipped accessible CLI updates earlier in the year—James simply wasn’t aware. They replied immediately. His response? “Thanks for pointing out the –screen-reader mode, which I think will help massively.” Because the AI workflow identified the problem correctly, we turned a frustration into a resolution in hours. But the most rewarding result isn’t the speed—it’s the feedback from users. Not just that we responded, but that the fixes actually worked for them: “Huge thanks to the team for updating the contributions graph in the high contrast theme. The addition of borders around the grid edges is a small but meaningful improvement. Keep it up!” “Let’s say you want to create several labels for your GitHub-powered workflow: bug, enhancement, dependency updates… But what if you are blind? Before you had only hex codes randomly thrown at you… now it’s fixed, and those colors have meaningful English names. Well done, GitHub!” “This may not be very professional but I literally just screamed! This fix has actually made my day… Before this I was getting my wife to manage the GitHub issues but now I can actually navigate them by myself! It means a lot that I can now be a bit more independent so thank you again.” That independence is the point. Every workflow, every automation, every review—it all exists so moments like these are the expectation, not the exception. The bigger picture Stories like these remind us why the foundation matters. Design annotations, code scanners, accessibility champions, and testing with people with disabilities—these aren’t replaced by AI. They are what make AI-assisted workflows effective. Without that human foundation, AI is just a faster way to miss the point. We’re still learning, and the system is still evolving. But every piece of feedback teaches us something, and that knowledge now flows continuously back to our team, our users, and the tools we build. If you maintain a repository—whether it’s a massive enterprise project or a weekend open-source library—you can build this kind of system today. Start small. Create an issue template for accessibility. Add a .github/copilot-instructions.md file with your team’s accessibility standards. Let AI handle the triage and formatting so your team can focus on what really matters: writing more inclusive code. And if you hit an accessibility barrier while using GitHub, please share your feedback. It won’t disappear into a backlog. We’re listening—and now we have the system to follow through. The post Continuous AI for accessibility: How GitHub transforms feedback into inclusion appeared first on The GitHub Blog.
GitHub availability report: February 2026
In February, we experienced six incidents that resulted in degraded performance across GitHub services. The post GitHub availability report: February 2026 appeared first on The GitHub Blog.
In February, we experienced six incidents that resulted in degraded performance across GitHub services. We recognize the impact these outages have had on teams, workflows, and overall confidence in our platform. Earlier today, we released a blog post outlining the root causes of recent incidents and the steps GitHub is taking to make our systems more resilient moving forward. Thank you for your patience as we work through near-term and long-term investments we’re making. Below, we go over the six major incidents specific to February. February 02 17:41 UTC (lasting 1 hour and 5 minutes) From January 31, 2026, 00:30 UTC, to February 2, 2026, 18:00 UTC, Dependabot service was degraded and failed to create 10% of automated pull requests. This was due to a cluster failover that connected to a read-only database. We mitigated the incident by pausing Dependabot queues until traffic was properly routed to healthy clusters. All failed jobs were identified and restarted. We added new monitors and alerts to reduce our time to detect and prevent this in the future. February 02 19:03 UTC (lasting 5 hours and 53 minutes) On February 2, 2026, between 18:35 UTC and 22:20 UTC, GitHub Actions hosted runners and GitHub Codespaces were unavailable, with service degraded until full recovery at 23:10 UTC for standard runners, February 3, 2026 at 00:30 UTC for larger runners, and February 3 at 00:15 for codespaces. During this time, actions jobs queued and timed out while waiting to acquire a hosted runner. Other GitHub features that leverage this compute infrastructure were similarly impacted, including Copilot coding agent, Copilot code review, CodeQL, Dependabot, GitHub Enterprise Importer, and GitHub Pages. All regions and runner types were impacted. Codespaces creation and resume operations also failed in all regions. Self-hosted runners for actions on other providers were not impacted. This outage was caused by a loss in telemetry that cascaded to mistakenly applying security policies to backend storage accounts in our underlying compute provider. Those policies blocked access to critical VM metadata, causing all VM create, delete, reimage, and other operations to fail. More information is available here. This was mitigated by rolling back the policy changes, which started at 22:15 UTC. As VMs came back online, our runners worked through the backlog of requests that hadn’t timed out. We are working with our compute provider to improve our incident response and engagement time, improve early detection, and ensure safe rollout should similar changes occur in the future. February 09 16:19 UTC (lasting 1 hour and 21 minutes) and February 09 19:01 UTC (lasting 1 hour and 8 minutes) On February 9, 2026, GitHub experienced two related periods of degraded availability affecting github.com, the GitHub API, GitHub Actions, Git operations, GitHub Copilot, and other services. The first period occurred between 16:12 UTC and 17:39 UTC, and the second between 18:53 UTC and 20:09 UTC. In total, users experienced approximately 2 hours and 43 minutes of degraded service across the two incidents. During both incidents, users encountered errors loading pages on github.com, failures when pushing or pulling code over HTTPS, failures starting or completing GitHub Actions workflow runs, and errors using GitHub Copilot. Additional services including GitHub Issues, pull requests, webhooks, Dependabot, GitHub Pages, and GitHub Codespaces experienced intermittent errors. SSH-based Git operations were not affected during either incident. Our investigation determined that both incidents shared the same underlying cause: a configuration change to a user settings caching mechanism caused a large volume of cache rewrites to occur simultaneously. In the first incident, asynchronous rewrites overwhelmed a shared infrastructure component responsible for coordinating background work, which led to cascading failures and connection exhaustion in the service proxying Git operations over HTTPS. We mitigated this incident by disabling async cache rewrites and restarting the affected Git proxy service across multiple datacenters. The second incident arose when an additional source of cache updates, not addressed by the initial mitigation, introduced a high volume of synchronous writes. This caused replication delays, resulting in a similar cascade of failures and again leading to connection exhaustion in the Git HTTPS proxy. We mitigated by disabling the source of the cache rewrites and again restarting Git proxy. We are taking the following immediate steps: We optimized the caching mechanism to avoid write amplification and added self-throttling during bulk updates. We are adding safeguards to ensure the caching mechanism responds more quickly to rollbacks and strengthening how changes to these caching systems are planned, validated, and rolled out with additional checks. We are fixing the underlying cause of connection exhaustion in our Git HTTPS proxy layer so the proxy can recover from this failure mode automatically without requiring manual restarts. February 12 07:53 UTC (lasting 2 hours and 3 minutes) On February 12, 2026, between 00:51 UTC and 09:35 UTC, users attempting to create or resume Codespaces experienced elevated failure rates across Europe, Asia, and Australia, peaking at a 90% failure rate. Impact started in UK South and impacted other regions progressively. US regions were not impacted. The failures were caused by an authorization claim change in a core networking dependency, which led to codespace pool provisioning failures. Alerts detected the issue but did not have the appropriate severity, leading to delayed detection and response. Learning from this, we have improved our validation of changes to this backend service and monitoring during rollout. Our alerting thresholds have also been updated to catch issues before they impact customers and improved our automated failover mechanisms to cover this area. February 12 10:38 UTC (lasting 34 minutes) On February 12, 2026, from 09:16 to 11:01 UTC, users attempting to download repository archives (tar.gz/zip) that include Git LFS objects received errors. Standard repository archives without LFS objects were not affected. On average, the archive download error rate was 0.0042% and peaked at 0.0339% of requests to the service. This was caused by the deployment of an incorrect network configuration in the LFS Service that caused service health checks to fail and an internal service to be incorrectly marked as unreachable. We mitigated the incident by manually applying the corrected network setting. Additional checks for corruption and auto-rollback detection were added to prevent this type of configuration issue. Follow our status page for real-time updates on status changes and post-incident recaps. To learn more about what we’re working on, check out the engineering section on the GitHub Blog. The post GitHub availability report: February 2026 appeared first on The GitHub Blog.
Addressing GitHub’s recent availability issues
GitHub recently experienced several availability incidents. We understand the impact these outages have on our customers and are sharing details on the stabilization work we’re prioritizing right now. The post Addressing GitHub’s recent availability issues appeared first on The GitHub Blog.
Over the past several weeks, GitHub has experienced significant availability and performance issues affecting multiple services. Three of the most significant incidents happened on February 2, February 9, and March 5. First and foremost, we take responsibility. We have not met our own availability standards, and we know that reliability is foundational to the work you do every day. We understand the impact these outages have had on your teams, your workflows, and your confidence in our platform. Here, we’ll unpack what’s been causing these incidents and what we’re doing to make our systems more resilient moving forward. What happened These incidents have occurred during a period of extremely rapid usage growth across our platform, exposing scaling limitations in parts of our current architecture. Specifically, we’ve found that recent platform instability was primarily driven by rapid load growth, architectural coupling that allowed localized issues to cascade across critical services, and inability of the system to adequately shed load from misbehaving clients. Before we cover what we are doing to prevent these issues going forward, it is worth diving into the details of the most impactful incidents. February 9 incident On Monday, February 9, we experienced a high‑impact incident due to a core database cluster that supports authentication and user management becoming overloaded. The mistakes that led to the problem were made days and weeks earlier. In early February, two very popular client-side applications that make a significant amount of API calls against our servers were released, with unintentional changes driving a more-than-tenfold increase in read traffic they generated. Because these applications end up being updated by the users over time, the increase in usage doesn’t become evident right away; it appears as enough users upgrade. On Saturday, February 7, we deployed a new model. While trying to get it to customers as quickly as possible, we changed a refresh TTL on a cache storing user settings from 12 to 2 hours. The model was released to a narrower set of customers due to limited capacity, which made the change necessary. At this point, everything was operating normally because the weekend load is significantly lower, and we didn’t have sufficiently granular alarms to detect the looming issue. Three things then compounded on February 9: our regular peak load, many customers updating to the new version of the client apps as they were starting their week, and another new model release. At this point, the write volume due to the increased TTL and the read volume from the client apps combined to overwhelm the database cluster. While the TTL change was quickly identified as a culprit, it took much longer to understand why the read load kept increasing, which prolonged the incident. Further, due to the interaction between different services after the database cluster became overwhelmed, we needed to block the extra load further up the stack, and we didn’t have sufficiently granular switches to identify which traffic we needed to block at that level. The investigation for the February 9 incident raised a lot of important questions about why the user settings were stored in this particular database cluster and in this particular way. The architecture was originally selected for simplicity at a time when there were very few models and very few governance controls and policies related to those models. But over time, something that was a few bytes per user grew into kilobytes. We didn’t catch how dangerous that was because the load was visible only during new model or policy rollouts and was masked by the TTL. Since this database cluster houses data for authentication and user management, any services that depend on these were impacted. GitHub Actions incidents on February 2 and March 5 We also had two significant instances where our failover solution was either insufficient or didn’t function correctly: Actions hosted runners had a significant outage on February 2. Most cloud infrastructure issues in this area typically do not cause impact as they occur in a limited number of regions, and we automatically shift traffic to healthy regions. However, in this case, there was a cascading set of events triggered by a telemetry gap that caused existing security policies to be applied to key internal storage accounts affecting all regions. This blocked access to VM metadata on VM creates and halted hosted runner lifecycle operations. Another impactful incident for Actions occurred on March 5. Automated failover has been progressively rolling out across our Redis infrastructure, and on this day, a failover occurred for a Redis cluster used by Actions job orchestration. The failover performed as expected, but a latent configuration issue meant the failover left the cluster in a state with no writable primary. With writes failing and failover not available as a mitigation, we had to correct the state manually to mitigate. This was not an aggressive rollout or missing resiliency mechanism, but rather latent configuration that was only exposed by an event in production infrastructure. For both of these incidents, the investigations brought up unexpected single points of failure that we needed to protect and needed to dry run failover procedures in the production more rigorously. Across these incidents, contributing factors expanded the scope of impact to be much broader or longer than necessary, including: Insufficient isolation between critical path components in our architecture Inadequate safeguards for load shedding and throttling Gaps in end-to-end validation, monitoring for attention on earlier signals, and partner coordination during incident response What we are doing now Our engineering teams are fully engaged in both near-term mitigations and durable longer-term architecture and process investments. We are addressing two common themes: managing rapidly increasing load by focusing on resilience and isolation of critical paths and preventing localized failures from ever causing broad service degradation. In the near term, we are prioritizing stabilization work to reduce the likelihood and impact of incidents. This includes: Redesigning our user cache system, which hosts model policies and more, to accommodate significantly higher volume in a segmented database cluster. Expediting capacity planning and completing a full audit of fundamental health for critical data and compute infrastructure to address urgent growth. Further isolate key dependencies so that critical systems like GitHub Actions and Git will not be impacted by any shared infrastructure issues, reducing cascade risk. This is being done through a combination of removing or handling dependency failures where possible or isolating dependencies. Protecting downstream components during spikes to prevent cascading failures while prioritizing critical traffic loads. In parallel, we are accelerating deeper platform investments to deliver on GitHub’s commitment to supporting sustained, high-rate growth with high availability. These include: Migrating our infrastructure to Azure to accommodate rapid growth, enabling both vertical scaling within regions and horizontal scaling across regions. In the short term, this provides a hybrid approach for infrastructure resiliency. As of today, 12.5% of all GitHub traffic is served from our Azure Central US region, and we are on track to serving 50% of all GitHub traffic by July. Longer term, this enables simplification of our infrastructure architecture and more global resiliency by adopting managed services. Breaking apart the monolith into more isolated services and data domains as appropriate, so we can scale independently, enable more isolated change management, and implement localized decisions about shedding traffic when needed. We are also continuing tactical repair work from every incident. Our commitment to transparency We recognize that it’s important to provide you with clear communication and transparency when something goes wrong. We publish summaries of all incidents that result in degraded performance of GitHub services on our status page and in our monthly availability reports. The February report will publish later today with a detailed explanation of incidents that occurred last month, and our March report will publish in April. Given the scope of recent incidents, we felt it was important to address them with the community today. We know GitHub is critical digital infrastructure, and we are taking urgent action to ensure our platform is available when and where you need it. Thank you for your patience as we strengthen the stability and resilience of the GitHub platform. The post Addressing GitHub’s recent availability issues appeared first on The GitHub Blog.
The era of “AI as text” is over. Execution is the new interface.
AI is shifting from prompt-response interactions to programmable execution. See how the GitHub Copilot SDK enables agentic workflows directly inside your applications. The post The era of “AI as text” is over. Execution is the new interface. appeared first on The GitHub Blog.
Over the past two years, most teams have interacted with AI the same way: provide text input, receive text output, and manually decide what to do next. But production software doesn’t operate on isolated exchanges. Real systems execute. They plan steps, invoke tools, modify files, recover from errors, and adapt under constraints you define. As a developer, you’ve gotten used to using GitHub Copilot as your trusted AI in the IDE. But I bet you’ve thought more than once: “Why can’t I use this kind of agentic workflow inside my own apps too?” Now you can. The GitHub Copilot SDK makes that execution layer available as a programmable capability inside your software. Instead of maintaining your own orchestration stack, you can embed the same production-tested planning and execution engine that powers GitHub Copilot CLI directly into your systems. If your application can trigger logic, it can now trigger agentic execution. This shift changes the architecture of AI-powered systems. So how does it work? Here are three concrete patterns teams are using to embed agentic execution into real applications. Pattern #1: Delegate multi-step work to agents For years, teams have relied on scripts and glue code to automate repetitive tasks. But the moment a workflow depends on context, changes shape mid-run, or requires error recovery, scripts become brittle. You either hard-code edge cases, or start building a homegrown orchestration layer. With the Copilot SDK, your application can delegate intent rather than encode fixed steps. For example: Your app exposes an action like “Prepare this repository for release.” Instead of defining every step manually, you pass intent and constraints. The agent: Explores the repository Plans required steps Modifies files Runs commands Adapts if something fails All while operating within defined boundaries. Why this matters: As systems scale, fixed workflows break down. Agentic execution allows software to adapt while remaining constrained and observable, without rebuilding orchestration from scratch. View multi-step execution examples → Pattern #2: Ground execution in structured runtime context Many teams attempt to push more behavior into prompts. But encoding system logic in text makes workflows harder to test, reason about, and evolve. Over time, prompts become brittle substitutes for structured system integration. With the Copilot SDK, context becomes structured and composable. You can: Define domain-specific tools or agent skills Expose tools via Model Context Protocol (MCP) Let the execution engine retrieve context at runtime Instead of stuffing ownership data, API schemas, or dependency rules into prompts, your agents access those systems directly during planning and execution. For example, an internal agent might: Query service ownership Pull historical decision records Check dependency graphs Reference internal APIs Act under defined safety constraints Why this matters: Reliable AI workflows depend on structured, permissioned context. MCP provides the plumbing that keeps agentic execution grounded in real tools and real data, without guesswork embedded in prompts. Pattern #3: Embed execution outside the IDE Much of today’s AI tooling assumes meaningful work happens inside the IDE. But modern software ecosystems extend far beyond an editor. Teams want agentic capabilities inside: Desktop applications Internal operational tools Background services SaaS platforms Event-driven systems With the Copilot SDK, execution becomes an application-layer capability. Your system can listen for an event—such as a file change, deployment trigger, or user action—and invoke Copilot programmatically. The planning and execution loop runs inside your product, not in a separate interface or developer tool. Why this matters: When execution is embedded into your application, AI stops being a helper in a side window and becomes infrastructure. It’s available wherever your software runs, not just inside an IDE or terminal. Build your first Copilot-powered app → Execution is the new interface The shift from “AI as text” to “AI as execution” is architectural. Agentic workflows are programmable planning and execution loops that operate under constraints, integrate with real systems, and adapt at runtime. The GitHub Copilot SDK makes those execution capabilities accessible as a programmable layer. Teams can focus on defining what their software should accomplish, rather than rebuilding how orchestration works every time they introduce AI. If your application can trigger logic, it can trigger agentic execution. Explore the GitHub Copilot SDK → The post The era of “AI as text” is over. Execution is the new interface. appeared first on The GitHub Blog.
Under the hood: Security architecture of GitHub Agentic Workflows
GitHub Agentic Workflows are built with isolation, constrained outputs, and comprehensive logging. Learn how our threat model and security architecture help teams run agents safely in GitHub Actions. The post Under the hood: Security architecture of GitHub Agentic Workflows appeared first on The GitHub Blog.
Whether you’re an open-source maintainer or part of an enterprise team, waking up to documentation fixes, new unit tests, and refactoring suggestions can be a true “aha” moment. But automation also raises an important concern: how do you put guardrails on agents that have access to your repository and the internet? Will you be wondering if your agent relied on documentation from a sketchy website, or pushed a commit containing an API token? What if it decides to add noisy comments to every open issue one day? Automations must be predictable to offer durable value. But what is the safest way to add agents to existing automations like CI/CD? Agents are non-deterministic: They must consume untrusted inputs, reason over repository state, and make decisions at runtime. Letting agents operate in CI/CD without real-time supervision allows you to scale your software engineering, but it also requires novel guardrails to keep you from creating security problems. GitHub Agentic Workflows run on top of GitHub Actions. By default, everything in an action runs in the same trust domain. Rogue agents can interfere with MCP servers, access authentication secrets, and make network requests to arbitrary hosts. A buggy or prompt-injected agent with unrestricted access to these resources can act in unexpected and insecure ways. That’s why security is baked into the architecture of GitHub Agentic Workflows. We treat agent execution as an extension of the CI/CD model—not as a separate runtime. We separate open‑ended authoring from governed execution, then compile a workflow into a GitHub Action with explicit constraints such as permissions, outputs, auditability, and network access. This post explains how we built Agentic Workflows with security in mind from day one, starting with the threat model and the security architecture that it needs. Threat model There are two properties of agentic workflows that change the threat model for automation. First, agents’ ability to reason over repository state and act autonomously makes them valuable, but it also means they cannot be trusted by default—especially in the presence of untrusted inputs. Second, GitHub Actions provide a highly permissive execution environment. A shared trust domain is a feature for deterministic automation, enabling broad access, composability, and good performance. But when combined with untrusted agents, having a single trust domain can create a large blast radius if something goes wrong. Under this model, we assume an agent will try to read and write state that it shouldn’t, communicate over unintended channels, and abuse legitimate channels to perform unwanted actions. By default, GitHub Agentic Workflows run in a strict security mode with this threat model in mind, and their design is guided by four security principles: defense in depth, don’t trust agents with secrets, stage and vet all writes, and log everything. Defend in depth GitHub Agentic Workflows provide a layered security architecture consisting of substrate, configuration, and planning layers. Each layer limits the impact of failures above it by enforcing distinct security properties that are consistent with its assumptions. <img data-recalc-dims="1" loading="lazy" decoding="async" height="949" width="1024" src="https://github.blog/wp-content/uploads/2026/03/image1.jpg?resize=1024%2C949" alt="Diagram of a three-layer system architecture with labeled sections Planning layer, Configuration layer, and Substrate layer. Each layer contains three blue tiles: Planning: Safe Outputs MCP (GitHub write operations), Call filtering (call availability, volume), Output sanitization (secret removal, moderation). Configuration: Compiler (GH AW extension), Firewall policies (allowlist), MCP config (Docker image, auth token). Substrate: Action runner VM (OS, hypervisor), Docker containers (Docker daemon, network), Trusted containers (firewall, MCP gateway, API proxy)." class="wp-image-94364" srcset="https://github.blog/wp-content/uploads/2026/03/image1.jpg?w=2139 2139w, https://github.blog/wp-content/uploads/2026/03/image1.jpg?w=300 300w, https://github.blog/wp-content/uploads/2026/03/image1.jpg?w=768 768w, https://github.blog/wp-content/uploads/2026/03/image1.jpg?w=1024 1024w, https://github.blog/wp-content/uploads/2026/03/image1.jpg?w=1536 1536w, https://github.blog/wp-content/uploads/2026/03/image1.jpg?w=2048 2048w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> The substrate layer rests on a GitHub Actions runner virtual machine (VM) and several trusted containers that limit the resources an agent can access. Collectively, the substrate level provides isolation among components, mediation of privileged operations and system calls, and kernel-enforced communication boundaries. These protections hold even if an untrusted user-level component is compromised and executes arbitrary code within its container isolation boundary. Above the substrate layer is a configuration layer that includes declarative artifacts and the toolchains that interpret them to instantiate a secure system structure and connectivity. The configuration layer dictates which components are loaded, how components are connected, what communication channels are permitted, and what privileges are assigned. Externally minted tokens, such as agent API keys and GitHub access tokens, are critical inputs that bound components’ external effects—configuration controls which tokens are loaded into which containers. The final layer of defense is the planning layer. The configuration layer dictates which components exist and how they communicate, but it does not dictate which components are active over time. The planning layer’s primary responsibility is to create a staged workflow with explicit data exchanges between them. The safe outputs subsystem, which will be described in greater detail below, is the primary instance of secure planning. Don’t trust agents with secrets From the beginning, we wanted workflow agents to have zero access to secrets. Agentic workflows execute as GitHub Actions, in which components share a single trust domain on top of the runner VM. In that model, sensitive material like agent authentication tokens and MCP server API keys reside in environment variables and configuration files visible to all processes in the VM. This is dangerous because agents are susceptible to prompt injection: Attackers can craft malicious inputs like web pages or repository issues that trick agents into leaking sensitive information. For example, a prompt-injected agent with access to shell-command tools can read configuration files, SSH keys, Linux /proc state, and workflow logs to discover credentials and other secrets. It can then upload these secrets to the web or encode them within public-facing GitHub objects like repository issues, pull requests, and comments. Our first mitigation was to isolate the agent in a dedicated container with tightly controlled egress: firewalled internet access, MCP access through a trusted MCP gateway, and LLM API calls through an API proxy. To limit internet access, agentic workflows create a private network between the agent and firewall. The MCP gateway runs in a separate trusted container, launches MCP servers, and has exclusive access to MCP authentication material. Although agents like Claude, Codex, and Copilot must communicate with an LLM over an authenticated channel, we avoid exposing those tokens directly to the agent’s container. Instead, we place LLM auth tokens in an isolated API proxy and configure agents to route model traffic through that proxy. <img data-recalc-dims="1" loading="lazy" decoding="async" height="596" width="1024" src="https://github.blog/wp-content/uploads/2026/03/image2.jpg?resize=1024%2C596" alt="Architecture diagram showing several connected Docker containers. A Codex token connects to an api-proxy container, which connects to an OpenAI service icon. A separate flow shows an agent container (linked to chroot/host) communicating over http to a gh-aw-firewall container, then over http to a gh-aw-mcpg container (linked to Host Docker Socket), then over stdio to a GitHub MCP container (linked to a GitHub PAT). A GitHub icon appears above the GitHub MCP container." class="wp-image-94365" srcset="https://github.blog/wp-content/uploads/2026/03/image2.jpg?w=2139 2139w, https://github.blog/wp-content/uploads/2026/03/image2.jpg?w=300 300w, https://github.blog/wp-content/uploads/2026/03/image2.jpg?w=768 768w, https://github.blog/wp-content/uploads/2026/03/image2.jpg?w=1024 1024w, https://github.blog/wp-content/uploads/2026/03/image2.jpg?w=1536 1536w, https://github.blog/wp-content/uploads/2026/03/image2.jpg?w=2048 2048w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> Zero-secret agents require a fundamental trade-off between security and utility. Coding workloads require broad access to compilers, interpreters, scripts, and repository state, but expanding the in-container setup would duplicate existing actions provisioning logic and increase the set of network destinations that must be allowed through the firewall. Instead, we carefully expose host files and executables using container volume mounts and run the agent in a chroot jail. We start by mounting the entire VM host file system read-only at /host. We then overlay selected paths with empty tmpfs layers and launch the agent in a chroot jail rooted at /host. This approach keeps the host-side setup intact while constraining the agent’s writable and discoverable surface to what it needs for its job. Stage and vet all writes Prompt-injected agents can still do harm even if they do not have access to secrets. For example, a rogue agent could spam a repository with pointless issues and pull requests to overwhelm repository maintainers, or add objectionable URLs and other content in repository objects. To prevent this kind of behavior, the agentic workflows compiler decomposes workflows into explicit stages and defines, for each stage: The active components and permissions (read vs. write) The data artifacts emitted by that stage The admissible downstream consumers of those artifacts While the agent runs, it can read GitHub state through the GitHub MCP server and can only stage its updates through the safe outputs MCP server. Once the agent exits, write operations that have been buffered by the safe outputs MCP server are processed by a suite of safe outputs analyses. <img data-recalc-dims="1" loading="lazy" decoding="async" height="688" width="1024" src="https://github.blog/wp-content/uploads/2026/03/image3.jpg?resize=1024%2C688" alt="Diagram showing a GitHub-centric workflow with green arrows and two rows of components. At the top, a GitHub icon points down into three boxes: Agent (Untrusted), GitHub MCP (Read-only), and MCP config (Write-buffered). Below are three processing steps labeled Filter operations, Moderate content, and Remove secrets, each marked 'Deterministic analysis.' Green arrows indicate data flow from GitHub into the system, down through configuration to 'Remove secrets,' then left through 'Moderate content' and 'Filter operations,' looping back toward the agent." class="wp-image-94366" srcset="https://github.blog/wp-content/uploads/2026/03/image3.jpg?w=2139 2139w, https://github.blog/wp-content/uploads/2026/03/image3.jpg?w=300 300w, https://github.blog/wp-content/uploads/2026/03/image3.jpg?w=768 768w, https://github.blog/wp-content/uploads/2026/03/image3.jpg?w=1024 1024w, https://github.blog/wp-content/uploads/2026/03/image3.jpg?w=1536 1536w, https://github.blog/wp-content/uploads/2026/03/image3.jpg?w=2048 2048w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> First, safe outputs allow workflow authors to specify which write operations an agent can perform. Authors can choose which subset of GitHub updates are allowed, such as creating issues, comments, or pull requests. Second, safe outputs limits the number of updates that are allowed, such as restricting an agent to creating at most three pull requests in a given run. Third, safe outputs analyzes update content to remove unwanted patterns, such as output sanitization to remove URLs. Only artifacts that pass through the entire safe outputs pipeline can be passed on, ensuring that each stage’s side effects are explicit and vetted. Log everything Even with zero secrets and vetted writes, an agent can still transform repository data and invoke tools in unintended ways or try to break out of the constraints that we impose upon it. Agents are determined to accomplish their tasks by any means and have a surprisingly deep toolbox of tricks for doing so. If an agent behaves unexpectedly, post-incident analysis requires visibility into the complete execution path. Agentic workflows make observability a first-class property of the architecture by logging extensively at each trust boundary. Network and destination-level activity is recorded at the firewall layer, model request/response metadata and authenticated requests are captured by the API proxy; and tool invocations are logged by the MCP gateway and MCP servers. We also add internal instrumentation to the agent container to audit potentially sensitive actions like environment variable accesses. Together, these logs support end-to-end forensic reconstruction, policy validation, and rapid detection of anomalous agent behavior. Pervasive logging also lays the foundation for future information-flow controls. Every location where communication can be observed is also a location where it can be mediated. Agentic workflows already support the GitHub MCP server’s lockdown mode, and in the coming months, we’ll introduce additional safety controls that enforce policies across MCP servers based on visibility (public vs. private) and the role of a repository object’s author. What’s next? We’d love for you to be involved! Share your thoughts in the Community discussion or join us (and tons of other awesome makers) in the #agentic-workflows channel of the GitHub Next Discord. We look forward to seeing what you build with GitHub Agentic Workflows. Happy automating, and keep an eye out for more updates! The post Under the hood: Security architecture of GitHub Agentic Workflows appeared first on The GitHub Blog.