Workflow execution protections/actions policies. Non-enterprises can't view insights

[gtjoseph]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Metrics & Insights

Discussion Details

The blog post Workflow execution protections in GitHub Actions generally available published on September 17th talks about new a new default actions policy that disables workflows triggered by pull-request-target from running. It then states that it will go into enforcing mode on November 2nd and that until then you can use policy insights to see what workflows would be affected. Unfortunately policy insights is only available to Enterprises. So...

• Will enforcement only be enabled for enterprises?
• If not, how would us mere mortals who run open-source organizations see what workflows would be affected?

[Sarvagya-24-chaturvedi]

Hi @gtjoseph,

Here are the direct answers to your two questions:

---

1. Will enforcement only be enabled for enterprises?

No, enforcement will apply to all public repositories across GitHub (including Free, Team, and Open Source organizations).

The changelog specifies:

"For public repositories that do not already have an applicable event policy, GitHub is introducing a default rule that disables pull_request_target... On November 2, 2026, we’ll automatically enforce the default rule for affected repositories that were using the default pull_request_target policy before general availability."

Because public repositories are the primary vector for "Pwn Request" attacks (untrusted fork code running with repository secrets), GitHub is enforcing this default across all public repos regardless of account tier.

---

2. How can open-source / non-enterprise organizations find affected workflows?

Since the Policy Insights dashboard is an Enterprise-tier feature, open-source maintainers can audit their repositories using the following methods:

Method A: GitHub Code Search (Fastest)

You can quickly find every workflow utilizing pull_request_target using GitHub search:

• Across your entire organization:

  org:YOUR_ORG path:.github/workflows "pull_request_target"
  

[gtjoseph]

So the only way we'll really know if our policies work is to wait for November 2nd and see what breaks?

[Sarvagya-24-chaturvedi]

No, you don't have to wait until November 2nd you can verify everything right now:

1. Check if you're affected: In your repository's Actions tab, type this in the filter box:
   event:pull_request_target
   If no runs show up, none of your workflows rely on it and nothing will break.

2. Explicit policies apply immediately: If you need a workflow to keep running, go to Settings > Actions > Policies and explicitly allowlist that workflow file today. You don't have to wait for November your policy takes effect instantly and overrides the default.

3. Test enforcement today: You can manually switch the policy to "Enforced" on a test repository right now and trigger a test PR to see exactly how it behaves.

[kit1211]

Hi @gtjoseph

Workflow execution protections for pull_request_target went to enforcing mode on the date in the September 17 2026 changelog. Non enterprise orgs cannot view the new Actions insights dashboard that shows policy violations per repo.

What you can do without enterprise insights:

1. Organization Settings, Actions, General. Review workflow execution protections setting. Note whether pull_request_target workflows from forks are blocked.

2. Audit each repo for workflows using pull_request_target. Search org wide:
   org:YOUR_ORG filename:.github/workflows pull_request_target

3. For each hit, verify the workflow does not checkout and execute untrusted fork code on pull_request_target without explicit approval gates.

4. Check recent workflow run failures for message about workflow execution protections or pull_request_target blocked.

5. Organization audit log (if available on your plan) may show policy enforcement events.

6. Open Support, GitHub Actions category. Ask for summary of repos affected by new default policy in your org if insights unavailable on Pro.

The blog post changelog entry is the authoritative source for enforcement date and default behavior. Enterprise insights is a visibility gap for Pro orgs, valid feedback to add here.

[gtjoseph]

Thank you for your suggestions. We took great care in constructing our workflows with pull_request_target and are confident we have them properly secured. I guess I was a bit put off by the fact that the changelog post says...

To prepare for the roll out of this rule, you can view the results of the evaluate rule using Insights and see which workflow runs will fail once enforcement begins.

...but doesn't mention that it's "Actions Insights" and not the repository or organization Insights and that Actions Insights are restricted to enterprises.

FYI... The only reason we use pull_request_target and not pull_request is that PRs from forked repos don't have access to repository or organization actions variables when triggered by pull_request. See #44322

[kit1211]

Hi @gtjoseph

You are right to call out the changelog wording. It says Insights without specifying Actions Insights is Enterprise only. That is confusing for Pro orgs. Valid documentation feedback.

On your pull_request_target vs pull_request issue for fork secrets:

You are correct. pull_request from forks cannot access repository or organization secrets and variables. pull_request_target runs in base repo context and can access them, which is why the pattern exists despite security risk.

Secure pattern for fork PRs needing org variables:

1. Use pull_request_target with strict guard:
   jobs:
   deploy:
   if: github.event.pull_request.head.repo.full_name == github.repository
   runs-on: ubuntu-latest
   This runs only for same repo PRs, not forks.

2. For fork PRs, use label gate:
   if: contains(github.event.pull_request.labels.*.name, 'safe-to-test')
   Maintainer adds label after manual review before workflow checks out fork code.

3. Never checkout fork head SHA and run scripts on pull_request_target without approval gate.

4. Alternative for org variables on fork PRs: use pull_request with environment secrets and manual workflow_dispatch triggered by maintainer after review. No automatic fork access.

5. Track discussion 44322 for product fix on variable access in fork pull_request events.

For enforcement prep without Enterprise insights:

1. Actions tab filter: event:pull_request_target on each repo
2. Settings, Actions, Policies: explicitly allowlist trusted workflow files before November enforcement
3. Test on one repo by setting policy to Enforced and opening test fork PR

Your workflows being properly secured is good. The gap is visibility tooling, not your security model.

[kit1211]

Hi @gtjoseph

You are right to call out the changelog wording. It says Insights without specifying Actions Insights is Enterprise only. That is confusing for Pro orgs. Valid documentation feedback.

On your pull_request_target vs pull_request issue for fork secrets:

You are correct. pull_request from forks cannot access repository or organization secrets and variables. pull_request_target runs in base repo context and can access them, which is why the pattern exists despite security risk.

Secure pattern for fork PRs needing org variables:

1. Use pull_request_target with strict guard:
   jobs:
   deploy:
   if: github.event.pull_request.head.repo.full_name == github.repository
   runs-on: ubuntu-latest
   This runs only for same repo PRs, not forks.

2. For fork PRs, use label gate:
   if: contains(github.event.pull_request.labels.*.name, 'safe-to-test')
   Maintainer adds label after manual review before workflow checks out fork code.

3. Never checkout fork head SHA and run scripts on pull_request_target without approval gate.

4. Alternative for org variables on fork PRs: use pull_request with environment secrets and manual workflow_dispatch triggered by maintainer after review. No automatic fork access.

5. Track discussion 44322 for product fix on variable access in fork pull_request events.

For enforcement prep without Enterprise insights:

1. Actions tab filter: event:pull_request_target on each repo
2. Settings, Actions, Policies: explicitly allowlist trusted workflow files before November enforcement
3. Test on one repo by setting policy to Enforced and opening test fork PR

Your workflows being properly secured is good. The gap is visibility tooling, not your security model.

[gtjoseph]

Thank you but we have already explored many options for accessing variables from fork PRs with pull_request. None of them are without issues.