Account restricted due to suspected GitHub Actions misuse — need clarification and review

[tejassinghrajput]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Other

Discussion Details

Hello GitHub Community,

I’m seeking clarity and guidance regarding an account restriction that appears to be with GitHub Actions usage.

Our organization recently had an owner account restricted due to activity flagged under GitHub’s Terms of Service, specifically related to GitHub Actions usage. However, based on our internal review, we believe there may be a misunderstanding.

Here are the key points:

• We do not have any custom .github/workflows/*.yml files configured in our repositories
• We have not intentionally set up GitHub Actions for CI/CD, scraping, automation against third-party services, or general compute workloads
• Some activity may have been triggered indirectly via GitHub Copilot (cloud features), not through manually created workflows
• We want to understand whether such indirect triggers (e.g., Copilot-related automation) can result in Actions execution tied to the repository or organization

What we need clarity on:

How can GitHub Actions be triggered in a repository where no workflow files exist?
Can GitHub Copilot (cloud features) trigger Actions workflows implicitly?
Is it possible for activity by a contributor or external integration to cause enforcement actions on the organization owner?
What logs or audit mechanisms can we use to definitively identify the source of the flagged activity?
What specific patterns or signals typically lead to enforcement under “non-CI workloads” or “third-party interaction” violations?

We are fully willing to cooperate and ensure compliance. If any repository, configuration, or integration caused this issue, we would appreciate guidance on identifying and correcting it.

Additionally, if anyone has experienced a similar situation or has insight into how such enforcement is evaluated internally, your input would be very helpful.

Thank you in advance.

[EmaLica]

Hey, I've looked into this and here are some answers to your questions:

Can Actions trigger without workflow files?
Yes — if you forked a repo that has workflows, or if a dependency/integration (like a GitHub App) has permissions to create workflow runs on your behalf.

Can Copilot trigger Actions?
Copilot itself doesn't trigger Actions, but some Copilot extensions or GitHub Apps connected to your org might. Check your installed Apps under Settings > Integrations > GitHub Apps.

Can a contributor cause enforcement on the owner?
Yes. If someone with write access pushes a workflow file (even temporarily) or triggers an API-based dispatch, the billing and enforcement falls on the org owner.

How to find what triggered it:

Go to Settings > Security > Audit log and filter by:

action:workflows

This shows every workflow run, who triggered it, and from which repo.

Also check:

• github.com/<your-org>/<repo>/actions — even deleted workflows leave run history
• Settings > Billing — shows Actions minutes per repo

My recommendation:
Contact GitHub Support directly at support.github.com with your audit log export. If the activity was from a third-party app and not intentional, they're usually reasonable about it.

[tejassinghrajput]

@EmaLica Thank you for the detailed breakdown — this is exactly the kind of clarity we needed.

To respond with what we've found after a thorough internal audit:

On workflow triggers:
We confirmed there are no forked repos with inherited workflows, and no third-party GitHub Apps configured with workflow dispatch permissions across our org.

On Copilot triggering Actions:
This is our most critical finding. After auditing all Actions usage across every repository in our organization, we found that every single workflow run — without exception — is either copilot or copilot-pull-request-reviewer. Both are GitHub's own first-party Copilot workflows. We authored zero custom workflow files. No .github/workflows/*.yml files exist anywhere in our org.

The total volume across our repos came to 500+ minutes and 80+ runs — but entirely from these two GitHub-native workflows.

On contributor-caused enforcement on the owner:
This is our core concern. The restricted account is an org owner with access to the most teams. Is it documented anywhere that high-volume usage of GitHub's own copilot-pull-request-reviewer workflow can trigger the "Actions for third-party interaction" enforcement clause? That is the exact clause cited in our restriction notice, and we cannot reconcile it with usage that is entirely GitHub-native.

Our specific question for the community:
Has anyone seen GitHub's enforcement system misclassify copilot-pull-request-reviewer runs as "third-party interaction" violations? We're trying to understand whether the volume of Copilot-native runs, not the nature of the workflows, is what triggered the flag.

We have already submitted a formal support ticket and appeal. Sharing this detail here in case it helps others facing the same situation.

[EmaLica]

This is actually a really important distinction that I don't think gets enough attention in the docs.

The copilot-pull-request-reviewer workflow is a first-party GitHub feature, but under the hood it still consumes Actions minutes and gets logged as a workflow run tied to your org. The enforcement system — at least based on what I've seen discussed in previous incidents — doesn't always distinguish between who authored the workflow and who owns the compute. It flags volume and interaction patterns, not intent.

The "third-party interaction" clause is the confusing part here. My read on it is that it was written to catch people spinning up Actions to interact with external APIs, scrapers, etc. But copilot-pull-request-reviewer itself does interact with external endpoints (the Copilot inference API). Whether GitHub's automated enforcement system interprets that as the workflow doing third-party interaction — even though it's GitHub's own product initiating it — is a genuinely murky area.

A few things worth trying before your appeal gets reviewed:

Check if your org had Copilot enabled for all members vs. selected members. If it was org-wide and you had active PRs, the reviewer workflow could realistically fire dozens of times a day across repos without anyone noticing.

When you submit your audit log export to support, explicitly call out that every run ID corresponds to github/copilot-pull-request-reviewer — make them confirm in writing whether that workflow is subject to the same enforcement rules as user-authored workflows. Getting that on record matters if this escalates.

Also worth asking support directly: is there a per-org threshold for Copilot-native Actions minutes that triggers review? That answer doesn't appear to be public anywhere.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬