The workflow boundary breaks because attacker-controlled input can execute in a privileged context. That lets an untrusted contribution inherit repository rights, secret access, or release permissions that should never be available during validation. The result is token leakage, unauthorized repository actions, or both, especially when pull_request_target is combined with broad permissions.
Why This Matters for Security Teams
Untrusted pull requests become dangerous the moment the workflow can write to the repository, access deployment secrets, or mint a token with broader rights than the review task requires. The problem is not just code execution. It is authority leakage across the workflow boundary, where validation logic and privileged operations share the same runtime. That is exactly the class of issue highlighted by the OWASP Non-Human Identity Top 10 and by NHIMG case studies such as Reviewdog GitHub Action supply chain attack.
When a pull request is attacker-controlled, every shell step, composite action, artifact download, and log line becomes part of the attack surface. If the workflow inherits write permissions, the attacker may not need a separate exploit to damage the repository. They can often use the platform’s own automation path to alter releases, poison build outputs, or exfiltrate secrets that were intended only for trusted branches. In practice, many security teams encounter this only after a token has already been reused, not through intentional review of workflow authority.
How It Works in Practice
The core failure is that GitHub Actions can run code from an untrusted source while the job still has permissions meant for trusted automation. That often happens when teams use pull_request_target for convenience, then forget that the workflow file executes in the context of the base repository. If permissions are broad, the workflow can read secrets, post status, create tags, upload artifacts, or push changes.
Current guidance suggests treating workflow identity as a supply-chain control point, not just a build runner. That means separating validation from privileged operations, limiting GITHUB_TOKEN permissions, and using explicit approvals before any job that touches release assets or protected environments. It also means assuming that anything the pull request can influence, including scripts and action inputs, should be treated as untrusted until the job boundary changes.
- Run untrusted code in jobs with read-only permissions and no secret access.
- Move deployment, release, and repository write actions into a separate trusted workflow.
- Scope tokens to the minimum required repository permission set.
- Use protected environments and manual approval gates for privileged steps.
- Review third-party actions as if they were dependencies with execution authority.
NHIMG’s CI/CD pipeline exploitation case study shows why this matters: once an attacker reaches the workflow’s privileged context, the pipeline itself becomes the trust boundary they are trying to cross. These controls tend to break down when teams reuse a single workflow for both pull request validation and release automation because the privilege model becomes impossible to reason about safely.
Common Variations and Edge Cases
Tighter workflow permissions often increase pipeline friction, requiring teams to balance developer speed against blast-radius reduction. That tradeoff becomes visible in monorepos, shared runners, and repositories that rely on reusable workflows, where a single mis-scoped token can affect many projects at once.
Best practice is evolving, but current guidance is clear on one point: do not assume all pull request events are equally safe. Untrusted forks, bot-generated patches, and dependency update PRs may each need different guardrails. A workflow that is acceptable for linting can be unsafe for artifact publication, and a job that only comments on issues can still be abused if it has write-scoped credentials.
The edge case most teams miss is indirect privilege. A workflow may not expose a secret in plain text, yet it can still use a write token to modify another file, trigger a follow-on workflow, or plant a malicious artifact that executes later under trusted conditions. NHIMG’s Ultimate Guide to NHIs is relevant here because the same over-privilege pattern affects all non-human identities, not just CI tokens. In environments that depend on nested reusable workflows with inherited permissions, the model breaks down because privilege propagation is harder to audit than the original pull request trigger.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Workflow code runs with delegated authority, similar to autonomous agent misuse patterns. | |
| CSA MAESTRO | Explains how execution context and privilege separation should protect autonomous automation. | |
| NIST AI RMF | GOVERN | Governance is needed to define ownership, approval, and escalation rules for workflow identity. |
Assign accountable owners for CI permissions and require explicit approval for privileged workflow paths.
