What’s coming to our GitHub Actions 2026 security roadmap - Feedback & Suggestions

[samus-aran]

We recently published a blog post outlining capabilities GitHub is actively investing in and developing for Actions security:

🔗 Blog post: What’s coming to our GitHub Actions 2026 security roadmap

Capabilities highlighted in the blog:

• Workflow-level dependency locking
• Workflow execution protections
• Scoped secrets and improved secret governance
• Actions data stream
• Native egress firewall for GitHub-hosted runners

Note: The blog does not include all active investigations. We will follow up in this discussion with additional capabilities as updates become available.

We'd love your feedback:

• What are your thoughts on the capabilities listed above?
• Are there other capabilities or areas you think GitHub should mention or prioritize?

Subscribe to this discussion to stay updated as we share more. 🔔

[offensive-actions]

Cool roadmap! Will definitely dive into it. My first reaction (also regarding the dependency locking) : get rid of the whole "commit to a fork is part of the network of the forked repo" so I cannot just create my own sha in e.g. actions/checkout and then pin to that hiding my malicious code :)

[Steve-Glass]

Great call out here and noted!

[DanielRuf]

The fork network feature was often more a problem than a solution. The UI did not and probably still does not show where a single commit belongs to.

But that is just one of many things that I see and would like to see some changes.
Here is one more: aquasecurity/trivy#10425 (reply in thread)

There is a big gap between what the frontend shows and what other parts show when some error ocurs.
Not the only design flaw but one that makes it harder for users using the UI instead of the API and other interfaces.

[ViacheslavKudinov]

Hi
I'm curious how workflow-level dependency locking will coexist with enterprise org level policy for allowed Actions.
Also maintenance of these "dependencies" without support by tools like Dependabot and Renovate will be a challenge for the teams.

[DanielRuf]

And I guess (and highly hope), that any newly added uses entry with a unreferenced action in dependencies will lead to a failing pipeline run similar to how the other tools work when strictly installed from and veryfying against lockfiles.

[Steve-Glass]

And I guess (and highly hope), that any newly added uses entry with a unreferend action in dependencies will lead to a failing pipeline run similar to how the other tools work when strictly installed from and veryfying against lockfiles.

@DanielRuf That is correct. If an new uses entry is added without pining, the workflow will not run.

One thing I have been considering is a new setting that will globally require pinning for an enterprise, org, or repo. My concern is that it will cause many to workflows to fail without ensuring that teams have had time to pin dependencies. This isn't something we'd ship in an early phase, but curious what others think.

[AdnaneKhan]

The hard part with these “all or nothing” settings is onboarding teams at scale.

If there was a way to make it apply to new or modified workflows, then it’s easier to drive adoption with less developer pain.

[Steve-Glass]

If there was a way to make it apply to new or modified workflows

I will look into this 😄 We take a similar approach to policy by applying new standards to new repositories and don't touch existing repos.

[Steve-Glass]

More detail on the proposed solution, along with a demo of what we have so far has been posted in this discussion: https://github.com/orgs/community/discussions/194494

We'd ❤️ your thoughts and opinions on the direction!

[ViacheslavKudinov]

Workflow execution protections is a good one, but what is not mentioned who can cancel running workflows and who can delete workflow run logs, as for now it can be everyone with "write" access. Which is against PoLP, especially the part to delete run logs.

[gregose]

👋 thanks for commenting and highlighting this current behavior. We acknowledge the issue of workflow run logs being able to be deleted by any GITHUB_TOKEN with actions:write permission. After seeing this exploited in a number of supply chain attacks, I bounced the idea off the team of special casing this actor (the GitHub Actions bot) and preventing it from accessing this API. In our review however, there are valid use cases for workflows to delete workflow runs and logs (like cleaning up artifact storage space, etc), so we haven't shipped this change.

That said, with the forthcoming "Actions Data Stream" we are looking to make this new data stream the immutable source of truth for what workflows ran and what they did, replacing workflow run logs in their use for security investigations. While we are still actively tracking and discussing limiting the ability for the GITHUB_TOKEN to delete workflow runs, I think this new feature will fill this gap in incident response visibility.

[DanielRuf]

And there is also the part with log retention. That is much shorter for the normal GH instances compared to GH enterprise.

I know, log management costs disk space and other resources. But could there be at least an option to use your own SIEM and configure some central repo setting, so that all logs are also sent to it? Many companies already use some solution for log collection, aggregation and analysis.

[ViacheslavKudinov]

We were asking our GitHub manager(s) about the feature to keep the Actions logs optionally for more than 400 days (current max for Enterprise cloud).
Our company works under some regulations and even centralized logs not always what auditors ask us about. They want to see the logs on GitHub ecosystem for some use cases and with only 400 days it becomes for us more difficult to pass the audits.

Yes, storage costs the money, but if its an option which some companies ready to choose and pay for, it would be the option which helps us a lot with passing the external audits.

[AdnaneKhan]

For workflow-level dependency locking I think a dependency on a manual action via the CLI is going to make this hard to adopt - especially to onboard existing workflows.

could this be built into the PR flow? As a PR creator (or other user with write access to PR head) who modifies a workflow I’d like the ability to run the dependency resolution and them commit the result on top of my commit via web flow.

[Steve-Glass]

Appreciate the thoughts on this! We are starting with the CLI to get running as soon as possible 😄

I like the idea of getting this built into the PR flow. This is an avenue we need to explore, along with augmenting the existing YAML authoring experience to accommodate locking.

This portion of the experience is not set in stone and I am open to suggestions to make sure we get this experience right the first time. Keep the suggestions coming!

[fproulx-boostsecurity]

Do something about "Imposter Commits". Accepting a PR from an apparently good samaritan suggesting to pin your GitHub Actions from tag to commit SHA can be worse than not accepting if they point to uses: actions/checkout@COMMIT_SHA_IN_FORK_NETWORK - then should be a warning in the Pull Request and the ruleset policy you mentioned, should disallow pinning on commits that are not in the Git tree of the default branch of the action's repo (this is similar semantics that Go Mod's Cache uses, you cannot put in a go.sum sometimes that the Go Module Mirror was not able to indepently confirm is at least part of a branch in the repo (not from a fork)

[fproulx-boostsecurity]

Ahhh @offensive-actions got it first above ^^

[offensive-actions]

It is the most unituitive thing and everybody I show that to just looks at me like what 😅 Normally I understand where things are coming from, but I really struggle to see the upside of this behaviour. If there is any reason to do it like this I would love to learn about it :) Especially since there is no easy way (like one call) to check in the API if the commit belongs to an (even deleted!!) fork...

[gregose]

Thank you both for raising this, 100% noted and under discussion as we revisit Action dependency resolution and how we pin (and what we allow to be pinned). It is critical that these dependencies can clearly and accurately be used to determine the source of this code and allowing imposter commits make this impossible. If a workflow is compromised and the source of the dependency being loaded changes to an attacker controlled one, we have to make sure this is very clear.

Normally I understand where things are coming from, but I really struggle to see the upside of this behaviour.

There is really no upside 😄 The backstory here is unrelated to Actions dependencies, but instead broad architectural behavior about git at GitHub. All commits across parents and forks are stored in a "repo network," any commit is accessible across that network unless we do specific reachability checks for that commit in a repo. We do not do reachability checks by default, only in certain places where we specifically check it, like that "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository" warning you get in the web ui.

We had an attempt a few years ago to do this reachability check in Actions resolution, but ran into a number of existing usage of the current behavior for releases on branches, etc that lived in forks and it was decided not to break these use cases. Now with an opportunity to revisit this and be more opinionated about it, we can make dependency resolution more obvious and trustworthy.

[offensive-actions]

Sounds awesome :) Thanks for giving some backstory!

[ericcornelissen]

I would love secrets to not just be available to any action (as an environment) but only when explicitly provided using ${{ secrets.xyz }}. The scoped secrets on the roadmap are a nice idea but doesn't meaningfully address most of the historical cases of credentials being leaked. In fact, the pinning feature is more useful for that but 1) is opt-in and 2) still doesn't fully protect against secret leakage since you can still upgrade (and pin) to a malicious version.

[fproulx-boostsecurity]

I would love to get natively from GitHub something like Chainguard done to replace PATs by implemented "octo-sts"

Oh my god YES! We built something very similar to OctoSTS about a year before they did and still using it, but it would be so much better to have it as core platform !

[fproulx-boostsecurity]

I’m sure @mattmoor would be on board 😄

[mattmoor]

You're absolutely right, @fproulx-boostsecurity!

EDIT: fixed for humor 😉

[Steve-Glass]

@mattmoor We had a conversation with Dan L. from your team yesterday. Looking forward to future discussions!

[mattmoor]

@Steve-Glass Yeah, he told me. Very happy to discuss if/how we (or Chainguard) can help here.

[arianvp]

One big issue I have is that you can't use dependabot to update npm dependencies of your github actions: actions/typescript-action#986

The reply was that this would be fixed with Immutable Actions but after 4 years of development that project seems to have been canned: github/roadmap#592

Immutable Releases does not solve the same issue as Github Action authors still need to commit build artifacts to their repos making it fundamentally incompatible with Dependabot.

Any plans on solving this specific pain-point? As it makes keeping the dependencies of the actions themselves practically impossible

[Steve-Glass]

Immutable Releases does not solve the same issue as Github Action

💯 This is something we plan to address this year. We have a few approaches we've been investigating. Each has their own potential impact to authors that we do not take lightly. I will share more detail in this thread over the next few weeks.

[hfhbd]

Yeah, I hoped immutable action publishing would finally resolve the problem of git to not checkin the dist folder (as a action author) and to not checkout the whole repo like including the tests of an action (as a action user), but to only get the minified binary from a real immutable package registry, like the planned OCI registry or from the GitHub release assets.

[Munken]

Trusted reusable workflows without requiring callers to pass secrets explicitly

Love this!
We are currently using azure vault + oidc federation to achieve this, but it have a significant cognitive load.

Also we need the policies here to be quite flexible.
Currently we allow everyone access to the secrets from the workflow main branch, while dev branches are more restricted.

—-

On a similar note, we need oidc for GitHub apps.
These are heavily used in these automations, but the require a certificate without expiration.

[kahalewai]

GitHub Actions security currently relies heavily on user awareness and best practices; stronger platform guarantees will really help the community. While pinning actions to full commit SHAs is correctly recommended and does provide immutability of content, it does not guarantee provenance, and this distinction is not well understood.

As documented by GitHub, users are expected to verify that a pinned SHA originates from the intended repository and not a fork, but this is easy to miss and not validated by the platform. This creates a gap where a malicious pull request can swap in a commit from a fork without changing the apparent owner/repo reference, undermining the trust model many users assume SHA pinning provides. The solution is to make provenance a first-class concept; an enforced property: ensure that owner/repo@sha resolves only to commits that exist within that repository, or otherwise fail the workflow.

In addition, provenance signals should be surfaced directly in pull requests and workflow logs (e.g., indicating when a commit originates from a fork or is being used for the first time), and ideally backed by cryptographic attestation mechanisms.

Additional ideas for improvements: include making immutable releases the default rather than optional, enforcing least-privilege permissions for tokens and secrets by default, strengthening environment-based secret scoping, and providing optional network egress controls to detect or prevent data exfiltration.

So to wrap it all up, recommend that GitHub update its guidance and messaging to clearly communicate that SHA pinning ensures immutability but not trust, and pair that guidance with automated enforcement and visibility features so that security does not depend on manual verification alone.

I hope this is helpful!

[DanielRuf]

I see this as a first step into the right direction. Congrats on that, expect the timing could a bit better.
But I still see some relevant points, that would fundamentally ease the process in case of any problem.

And that is to implement real secrets management with bulk rotation / revocation.
Not going to add more at the current time.

I'm having a background in specific areas and worked with GH Enteprise for one customer in the past.
I still see general design flaws, but you want to solve them by adding more layers instead of addressing them correctly.

[MarawanYakout]

Your approach of using the Actions Data Stream as an immutable source of truth for security investigations is a strong forward-looking solution. By decoupling the audit trail from mutable workflow run logs, you address the core incident response gap exploited in those supply-chain attacks. Knowing that the Data Stream will retain an unalterable record of what ran and what it did provides confidence that forensic analysis won’t be undermined by post-facto log deletion.

That said, I wonder if there’s room to layer additional controls on the deletion capability itself, even while preserving legitimate cleanup use cases. For example:

• Requiring a higher permission level (e.g., admin:repo or organization-level approval) for bulk log deletion

• Implementing a minimum retention period (e.g., 24–48 hours) before logs can be deleted, allowing time for security monitoring

• Separating the “delete logs” permission from the general actions:write scope so it can be granted more selectively

Such measures wouldn’t break existing cleanup workflows (which could adapt to use the new permissions or wait for the retention window) but would raise the bar for attackers attempting to cover their tracks. Combined with the immutable Data Stream, this would create a defense-in-depth posture: the Stream ensures visibility, while stricter deletion controls reduce the likelihood that visibility is lost in the first place.

Either way, I’m encouraged that the team is actively tracking this issue and leveraging the Data Stream to mitigate the risk. It’s a thoughtful balance between operational flexibility and security resilience.

[ViacheslavKudinov]

Another feature we were requesting from GitHub to add something like "Artifact attestations"/provenance enabled by default for all Actions run logs, as it could help with our audits when we can prove that logs which we saved via what ever implementation, like webhooks, are actually from GitHub, are not tampered, not artificially generated, etc.
As there is currently no native way to prove logs were created on GitHub
But some Logs/Data streaming solutions are appreciated.
I hope GitHub will not stop with only S3/"Azure".

[Steve-Glass]

I hope GitHub will not stop with only S3/"Azure".

We plan on meeting customers where they are at. It is not difficult to create new event sinks. We will work with early preview customers and and expand the list. Expect way more support leading up to GA. If there are any you'd like to see out the gate, let me know!

[mschoettle]

Please have a look at zizmor and its audit rules. These things (especially template-injection, dangerous-triggers, excessive-permissions, impostor-commits to name a few) should not be possible in the first place!

Also see a post from Chainguard's CEO regarding that.

[deiga]

I love the idea of rulesets as policies. We've been wanting to find a scalable way to apply policies to workflows (like OPA in CircleCI).
The examples didn't mention anything in the way of policies for workflows contents.
Would something like that be in the works though?

Examples:

• We want to block execution of Ubuntu-latest
• We have base container images for workflows and would like to show a "warning" when an upgrade is available.

[wrslatz]

Came here to make this same kind of request.

I'd really like for Actions to be supported as core policy dimension, on top of Actor Rules and Event Rules. Supporting Actions as a dimension of policy for Actions would allow infinitely more capable and flexible governance, often required by enterprises and difficult or impossible to achieve natively in Actions today.

Supporting Actions as a dimension of policy that must succeed prior to the execution of further workflows or jobs (essentially a "pre-hook" or "pre-flight check") would allow

• applying OPA policies on workflow YAML contents (restrict specific runners from being used, etc.)
• blocking insecure or undesirable workflows from executing, using zimzor or a similar scanning tool
• blocking workflows from executing if a repository is using dependencies with critical vulnerabilities
• enforcing a more flexible and real-time allow-list for Actions that are allowed to be used, supporting malware scanning and vetting of Actions before they execute (not possible with the current Actions allow-list)

If this were also expanded to support enforcing policies after workflows or jobs (essentially a "post-hook"), it could support additional types of governance and compliance checks, including

• requiring that a job or workflow have produced some output, like test results or coverage info, and validate the contents
• requiring a security or compliance check to execute that depends on some dynamic workflow output (test results, coverage info, etc.)

Ideally any Actions used as policies would allow

• failure that blocks further execution for the job(s) or workflow(s)
• warning that notifies users but continues
• approval gate that requires users with specific roles to review and approve or deny

While Actions as a dimension of policy can be partially achieved with required and reusable workflows, it is difficult to actually implement and very limited functionally (hard to enforce prior to execution of user-defined workflows, or requires gating Actions behind only reusable workflows managed at the organization or enterprise level). Dynamic pre and post checks that are enforced at an organization or enterprise level and that depend on or integrate with user-defined Actions workflows are really what is needed to support a wide range of governance requirements.

Some of these ideas may be more along the lines of enterprise governance and policy enforcement than solely security, but they are critical for enterprises to secure and govern their use of GitHub Actions.

[wrslatz]

Reading through this again, I think most of my feedback here would fit better under a "governing Actions at scale" topic rather than this one specific to securing Actions. The ideas most specific to securing Actions would be

• enforcing OPA policies on Actions workflows prior to their execution
• scanning Actions for vulnerabilities and malicious intent, using the new workflow-level dependency locking proposed in the roadmap
• configuring specific Actions to execute and requiring them to succeed prior to executing workflows ("pre-hook"), which could support the first two items

[Steve-Glass]

@wrslatz I really like you ideas around pre and post job policy hooks! In addition to Event and Actor rules we are building, there was a list of about 10 other rules we scoped.

Like @deiga stated We want to block execution of Ubuntu-latest is one of them. More around the ability to limit execution based on runner type (hosted vs. self-hosted, standard vs. larger runner) and even repository visibility. Rather than build a bunch of rules nobody wanted, we wanted to start with capabilities that had strong signal and work with the community from there.

[wrslatz]

@wrslatz I really like you ideas around pre and post job policy hooks! In addition to Event and Actor rules we are building, there was a list of about 10 other rules we scoped.

Like @deiga stated We want to block execution of Ubuntu-latest is one of them. More around the ability to limit execution based on runner type (hosted vs. self-hosted, standard vs. larger runner) and even repository visibility. Rather than build a bunch of rules nobody wanted, we wanted to start with capabilities that had strong signal and work with the community from there.

@Steve-Glass starting with a smaller set of rules that are more applicable to a wider group makes sense. Being able to apply policy without needing to write custom Actions or code is really appealing.

It would be awesome if these new policy rules integrated well with the VS Code Actions workflow editing experience and/or a CLI experience. Catching and blocking these kinds of things prior to actually pushing changes up to GitHub would be great.

If OPA policy could be supported as native rules somehow and not require custom Actions workflows that would likely cover a lot of use cases. For example, I may want to enforce that workflows for Node.js projects use npm ci instead of npm install, as the preferred and more secure installation method in CI. Open to other ideas besides OPA for how to ensure CI/CD workflow best practices are followed where the content within the workflow YAML needs to be checked. We'll basically want to be able to enforce policy on any YAML content.

[ViacheslavKudinov]

I love idea of "native support of OPA", as Rego is kind of industry standard for policies as code and several vendors support native integration. It extremely flexible and could help a lot with many policies to enforce on "content" of workflow files and not only workflows, but just any files on the repo which Enterprises need to control.

[MarkVaughn]

Thanks for publishing this roadmap.

One additional capability I’d like to see prioritized: an organization/enterprise-level control to require that workflows use only approved runner classes, especially self-hosted or larger/private runners, and explicitly disallow public GitHub-hosted runners across all repositories.

Today, we can govern Actions usage, allowed actions, secrets, and self-hosted runner access, but there does not appear to be a native org-wide policy that says “workflows in this org may not use public GitHub-hosted runners.” That leaves enforcement to code review, custom linters, policy-as-code, or repository-by-repository conventions. For organizations treating CI/CD as production infrastructure, runner placement is a security boundary and should be centrally enforceable.

Concretely, it would be useful to have:

• Org/enterprise policy to allow or deny runner types:

  • GitHub-hosted public runners
  • GitHub-hosted larger/private runners
  • Self-hosted runners
  • Specific runner groups or labels

• Policy enforcement on runs-on, ideally with clear workflow validation failures before execution.

• Optional repository exceptions managed centrally.

• Audit log events when workflows are created, modified, or blocked due to runner policy violations.

I’d also like to see more native workflow auditing features. The Actions data stream sounds like a good step, but security teams also need first-class ways to answer questions such as:

• Which workflows use mutable action references instead of pinned SHAs?
• Which workflows can access org, repo, or environment secrets?
• Which workflows have broad GITHUB_TOKEN permissions?
• Which workflows run on pull requests from forks?
• Which workflows use public runners?
• Which workflows use unapproved third-party actions?
• Who changed a workflow file, when, and what security-relevant behavior changed?
• Which workflows have egress access, OIDC access, deployment access, or package publishing access?

Ideally this would be available as native org/enterprise inventory, audit log, API, and exportable reporting — not only as raw workflow YAML that every customer has to crawl and interpret independently.

The roadmap items are pointed at the right problem: CI/CD is now part of the production trust boundary. Runner policy and workflow auditability should be treated as core governance primitives alongside dependency locking, scoped secrets, execution protections, and egress controls.

[beeequeue]

is there any plan for when node 26 will be available as runs.using: node26?

it bring support for Temporal which could reduce the size or complexity of many actions, and it wouldn't be nice to wait for the next LTS version after v26 as it will release in 2027

[musaabhasan]

The roadmap items are strong, especially dependency locking, scoped secrets, egress controls, and workflow execution protections.

One area I would prioritize is policy evidence for workflow runs. For regulated or security-sensitive repositories, teams need to know not only that a workflow passed, but which dependency lock, allowed-actions policy, secret scope, egress policy, runner image, and approval rule were applied to that run.

A useful run-level security receipt could include: workflow file hash, action dependency lock ID, reusable workflow versions, permission set, secret access set, egress policy, triggering actor, approval requirement, runner class, and log-retention state. That would make Actions security much easier to audit and compare across runs.

For adoption, dependency locking should also integrate naturally into PR review and Dependabot/Renovate-style update workflows; otherwise teams may bypass it because manual maintenance becomes too heavy.

[armorer-labs]

The part of this roadmap that feels most important for agentic and automation-heavy setups is making the mutation boundary more explicit. A lot of security guidance today is still strongest at ingress (who triggered what, which SHA is pinned, what secret is scoped), but teams also need a clearer model for when a workflow crosses from observation into high-impact action.\n\nThat is why execution protections, richer signals, and better audit streams fit together so well: they help answer not only "what ran?" but "what authority became reachable, and under what conditions?"\n\nEspecially for AI-assisted or semi-autonomous workflows, I think the most valuable future state is one where approval, provenance, policy, and post-hoc evidence line up at the exact boundary where code or automation can mutate the world.

[Vaccano]

I would love to see more details in the Actions permissions (at least for Enterprise Managed Users).

These would include:

• Fire off a build run
• Re-run a build
• Edit workflows
• Create a workflow from a template
• Edit Repo Variables

I would LOVE to give my developers the ability to fire off a build run, and create a workflow from a template, and edit variables, but NOT be able re-run a build or edit the workflows.

Additionally, I would love a way to allow ONLY enterprise workflow templates to be shown in the "Create New Action" window.

I admit that these are maybe not features that the general user of GitHub wants, but for Enterprise customers, they would be fantastic!!

UPDATE:

After further review, GitHub Actions is just not "Enterprise" enough for us. While I would think these are good suggestions for you product, you don't need to do them based on my vote (not that you would have with just one vote).

Not that it matters to GitHub, but here are the ways that Actions falls short for us.

1. We need a way to pre-setup a build template, and then allow developers to select the template and use it without modifying it. ( The code owners restrictions does not allow creating builds from templates.)
2. We need to be able to control the templates that the user sees. (Right now, the standard templates cannot be removed.)
3. Build "re-runs" are a mess for an enterprise. If a developer can go and re-run any build at any time, then you cannot trust that the build is what it was when it was tested. A build runner could have changed or downloaded dependencies could have changed. Any number of things (except the code) could have changed. A build needs to be immutable. If there was a problem, then run a NEW build. (Build numbers should not be a scarce resource.)

[jsgosh]

I cannot say if the enterprisey nature of this proposal would work for @giom-l, but a ref or CODEOWNERS restriction could be viewed as an indirect way of authorizing the user identities that the restriction implicitly or explicitly excepts. More direct authorization would also be sufficient for my use case.

It's not clear to me how workflow editing would be prevented by this scheme when a developer has write access, but this may be ignorance of Enterprise features on my part.

Edit: I forgot that the original announcement mentioned rulesets as the basis for this feature, possibly enhanced to block pushes based on a combination of file path and user identity.

[david-allison]

According to the docs, Dependabot Alerts do not fire for SHA-pinned actions:

For GitHub Actions, alerts are only generated for actions that use semantic versioning, not SHA versioning.

This should be prioritized, we shouldn't need to choose between pinned SHAs and Dependabot Alerts (for actions which don't yet support immutable releases)

• https://github.com/orgs/community/discussions/154189

[fproulx-boostsecurity]

Love this https://github.blog/changelog/2026-06-18-control-who-and-what-triggers-github-actions-workflows/ But I could not find the "Actions Insights" page to monitor policy violation

[bashonly]

I find the documentation to be sorely lacking (even if the link is corrected).

How do I restrict actors only for workflow_dispatch trigger events? I've read the documentation multiple times and I still have no idea how I'm supposed to achieve this. There are no examples given.

If I only restrict actors in a policy, then all trigger events are restricted to those actors (e.g. my issue_comment-triggered workflows are failing on comments from users not in the allowlist.)

Does restricting events in the same policy where I'm restricting actors modify what the actor restriction applies to? There is no mention of this in the docs. EDIT: Nope.

[ViacheslavKudinov]

I could make it working with these settings (repo level)

Sorry, if I got your post wrong

Oh, you are right.
If I restrict only one event but have rule for other to allow it still doesn't work as expected

[bashonly]

Here's everything I've tried (resetting to a "no policy" state inbetween):

1. Added a policy that only restricted actors to my org's core team

   • Result: Any workflow triggered by any actor not in my org's core team was prevented from running (undesired)

2. Added a policy that restricted actors to my org's core team and restricted events to workflow_dispatch

   • Result: Maintainers with write access but who aren't in the core team were unable to trigger workflow_dispatch runs (desired); however, any workflow triggered by an event other than workflow_dispatch failed to run (undesired)

3. Added a policy that only restricted events to everything except workflow_dispatch, and added another policy that restricted actors to my org's core team and allowed all events

   • Result: Any workflow triggered by any actor not in my org's core team was prevented from running (undesired)

[Steve-Glass]

👋 As always, we really appreciate the feedback! Working on docs updates today + investigating the scenarios described above!

[ViacheslavKudinov]

Hi @Steve-Glass
any updates with this one ?

I have 2 Policies

Restrict workflow_dispatch

and allow everything else

But when i try something to "change" im getting

Actor is not allowed to trigger Actions workflows.

Actor is not allowed to trigger Actions workflows. Event 'push' is not allowed to trigger Actions workflows.

and so on.

What am i doing wrong there ?

Thank you in advance.

[xiaogangwen]

For the new Workflow Execution Policy at enterprise level announced from https://github.blog/changelog/2026-06-18-control-who-and-what-triggers-github-actions-workflows/, no way to choose actors?

It works good at org or repo level.

[Steve-Glass]

That is not correct. We will look into this immediately!

[Steve-Glass]

PR is out for review to fix this

[xiaogangwen]

Seems fixed already. Cool!

[audunsolemdal]

For workflow execution policies I created a few and set them in evaulate mode. I am wondering if there are currently any ogs for this? Is there no view such as repository rulesets' "Insights" or any audit logs?

https://docs.github.com/en/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/actions-policies/workflow-execution-protections

[Steve-Glass]

Insights + API access are coming with GA. We understand that you need the insights as an admin to monitor how the rules are being evaluated. We will clarify this in the docs and the changelog

[Steve-Glass]

Hi everyone, quick update from our side 😄

We've expanded the Native Egress Firewall technical preview by granting all users access to the new firewall runner label in audit mode (runs on: ubuntu-24.04-firewall). We've also made the Early Access repository public. It contains setup guidance, usage instructions, and a place to submit feature requests or report issues:

• Native Egress Firewall Early Access Repository

If you need access to larger runners, please submit an issue in the repo.

A few additional updates:

• Workflow Execution Protections entered public preview last Thursday. Learn more in the announcement:

  • Workflow Execution Protections Changelog
  • We are actively look through the feedback already submitted in this thread!

• Workflow Dependency Lock Files are entering technical preview this week. If youre interested, please respond here!

[shenanigansd]

I'm curious about workflow dependency lock files for https://github.com/enterprises/tailstory

[hfhbd]

I am also interested in the workflow dependency lock files for github.com/softwork-app

[arianvp]

We'd be interested in the Workflow Dependency lock files preview at https://github.com/MercuryTechnologies

[ViacheslavKudinov]

How "Native Egress Firewall" will coexist with "Copilot Cloud Agent firewall" ?

Are they several layers of protection ?
One replaces another ?
Something else ?

[deiga]

We'd be interested into workflow dependency lock files for @F-Secure (GHEC)

[ysknsid25]

Hi everyoune 👋 Thank you for releasing amazing feature.

I tried this feature, but it may be occured unexpected situation.

I executed schedule triggered event. This actor looks like github-merge-queue[bot]. So I would add github-merge-queue[bot] to Allowed actors but there were no options.

Are there how to add github-merge-queue[bot] to Allowed actors ? or Is my way wrong?

[bewuethr]

To confirm my understanding of workflow execution policies: if I restrict to specific actors, this applies to all workflows, correct? If so, here's a feature request: let me pick which workflows a policy applies to.

For example, I'd like to be able to have a repository with many workflows that can be triggered by anybody with write access, but select more sensitive workflows can only be triggered by a specific team.

I can work around this today by moving workflows between repositories so the same protection applies to all workflows in a repo, but it would be nice to be more flexible within one repo.