Parsing and detecting agentic workflow injection vulnerabilities in GitHub Actions

Core problem: LLM-based agentic workflows in GitHub Actions introduce a new injection surface: untrusted GitHub event context (such as issue bodies, PR descriptions, comments) may be incorporated into agent prompts or downstream workflow logic, causing attackers to influence agent behavior, but existing techniques cannot effectively detect such vulnerabilities.

• Problem scenario and importance: GitHub Actions is increasingly used to deploy LLM-based agents to perform repository tasks (such as issue triage, PR review, code modification). These agentic workflows extend traditional CI/CD automation but also create a new attack surface. Security reports (such as PromptPwnd, Clinejection) have documented real cases in which attackers can steal secrets or perform unauthorized operations through malicious issue or PR content.

• Inadequacy of existing methods: Existing prompt injection detection techniques (such as prompt-to-code, prompt-to-SQL) are not designed for CI/CD workflows and cannot capture workflow-specific execution semantics (such as event context, action input/output interfaces, cross-step data channels). Traditional CI/CD security tools (such as ARGUS, CodeQL) focus on deterministic workflows and do not model taint propagation through agent prompts, derived outputs, or LLM boundaries.

• Core observation: The authors propose that Agentic Workflow Injection (AWI) is a workflow-level injection flaw in which untrusted event context is incorporated into agent prompts or inputs consumed by agents and is transformed through agent tools or downstream workflow logic into behavior influenced by attackers. AWI is the intersection of prompt injection and script injection in agentic workflows, but is not fully captured by either category alone.

• Paper contributions: The authors conduct the first systematic study of AWI in GitHub Actions, characterize 1,033 real AI-assisted actions, extract AWI-specific taint specifications, and design the TAINTAWI static analysis tool to detect P2A and P2S vulnerabilities.

• Threat model:

  • Attacker goals: Through semantic influence, cause the agent to perform operations desired by the attacker, such as labeling issues, posting comments, modifying files, executing shell commands, or calling GitHub APIs.
  • Attacker knowledge: An external GitHub user or low-privilege contributor who can interact with the repository through normal collaboration channels.
  • Attacker capabilities: Can create issues, submit PRs, and post comments, but cannot modify workflow files, repository settings, protected branches, or secrets.
  • Victim system: GitHub Actions workflows that invoke LLM agents through agentic actions or CLI, which execute in the configured workflow environment and may inherit workspace access permissions, credentials, and exposed agent capabilities.

GitHub Actions and CI/CD workflow security

• Koishybayev et al. [21] characterized the security properties of GitHub CI workflows, pointing out that excessive permissions, untrusted triggers, and third-party action dependencies are widespread.
• Benedetti et al. [23] demonstrated the prevalence of workflow security weaknesses through automated evaluation; Muralee et al. [24] proposed ARGUS, a staged static taint analysis framework for GitHub workflows and actions, to detect code injection vulnerabilities.
• Recent work [22] re-examined security practices for GitHub Actions workflows, [25] compared the scope and effectiveness of workflow scanners, and [2] analyzed failed workflow executions to build a taxonomy of failure causes.

Emerging attack surfaces in LLM-integrated systems

• Empirical studies identified prompt-to-code execution [13], prompt-to-SQL injection [11], prompt-to-anything vulnerabilities [12], and taint-style attacks in tool-using agents [10].
• Subsequent work studied prompt injection in tool selection [14], cross-tool collection and contamination [20], and multi-tool vulnerabilities in LLM agents [19].
• Benchmarks and audit frameworks (such as Agent Security Bench [46] and AgentAuditor [47]) have begun to systematize agent security evaluation; emerging audit and scanning tools (such as Trail of Bits' Agentic Actions Auditor [48], Prompt Injection Scanner [37], and Aikido OpenGrep Rules [38]) reflect attention to such risks.

Baseline methods and benchmarks

• The paper compares four baseline tools: PROMPT INJECTION SCANNER (PISCANNER) [37], a heuristic workflow scanner that detects unsafe patterns where AI agents process untrusted user input; Aikido's OPENGREP RULES [38], a lightweight pattern-matching baseline; ARGUS [24] and CODEQL [39], two general GitHub Actions taint analyzers. The latter two were provided with the same agentic-action prompt vocabulary taint specifications as TAINTAWI to detect P2A flows, but no derived-output specifications or P2S propagation rules were added.

Authors' positioning The authors point out that existing research mainly focuses on LLM-integrated applications and agents in general settings, and has not sufficiently explored their interaction with CI/CD workflow semantics. This paper fills this gap by systematically studying how, in real GitHub Actions workflows, LLM capabilities allow untrusted input to influence downstream workflow behavior.

The authors first define the Agentic Workflow Injection (AWI) vulnerability type and identify two core patterns: Prompt-to-Agent (P2A) and Prompt-to-Script (P2S). On this basis, they design the TAINTAWI static analyzer, which detects AWI vulnerabilities through four stages: inferring action-level taint specifications, building a workflow intermediate representation (IR), generating an Agentic Workflow Dependency Graph (AWDG), and performing taint propagation and reachability analysis.

Problem Setting and Formalization

• AWI definition: A workflow-level injection flaw in which untrusted GitHub event context is incorporated into agent prompts or inputs consumed by agents, thereby influencing agent behavior or downstream workflow logic. Unlike traditional script injection, AWI relies on semantic influence rather than syntactically valid code injection.
• Two core patterns:
  • P2A (Prompt-to-Agent): Untrusted content reaches the agent prompt boundary and may manipulate the agent's privileged capabilities.
  • P2S (Prompt-to-Script): Attacker influence first propagates through model- or agent-derived output and is later consumed by downstream workflow logic.
• Four security properties: Agentic Capability, Prompt Configurability, Access Control, Output Exposure. These properties are not vulnerabilities in themselves, but when a workflow combines untrusted event context with them, AWI risk may be exposed.

Action-Level Taint Specification Inference

• Data collection: Candidate AI-assisted actions were collected from the ai-assisted category and keyword searches on the GitHub Actions Marketplace; after deduplication, 1,035 unique action repositories were obtained, of which 1,033 contained analyzable action metadata files.
• LLM-assisted analysis: An LLM-assisted analyzer was used to infer four security properties, including action type (agentic/LLM-assisted/non-LLM), prompt boundary, derived output, and access control interface. The analysis focused on the action metadata interface exposed to workflow authors.
• Manual validation: The first two authors independently reviewed 100 random samples; the agreement rate between LLM-inferred fields and manual labels was 95.9%. A full manual review was conducted for 22 widely adopted actions with more than 100 downstream references.

Workflow IR Construction

• Three-level hierarchy: GitHub Actions workflow YAML files are lifted into an intermediate representation (IR) that preserves execution semantics, including WorkflowIR (recording trigger events, inputs, environment variables, permissions, job list), JobIR (recording job identifier, needs dependencies, conditions, environment variables, permissions, outputs, step list), and StepIR (recording step key, ID, uses action, run script, with inputs, environment variables, conditions).
• Semantic preservation: The IR normalizes raw YAML syntax and captures trigger entry points, job-level control flow, and step-level data interfaces, providing analysis-ready workflow semantics for subsequent taint analysis.

AWDG Generation and Taint Propagation

• AWDG construction: A directed graph G_W = (V, E_cf, E_df, α) is constructed, where nodes represent workflow-level values or execution sites, and edges represent potential control flow or data flow. A control-flow edge indicates that execution may proceed from u to v, and a data-flow edge indicates that the value of u may flow into v.
• Taint specification: Taint sources (Src) are defined as workflow values controllable by attackers (e.g., issue.title, issue.body, comment.body, pull_request.title, pull_request.body, branch/commit metadata, serialized event context); sinks (Snk) are divided into P2A sinks (prompt input interfaces of agentic actions) and P2S sinks (downstream workflow operations that consume model/agent-derived data, such as gh issue edit, git push); sanitizers (San) include action-level guards (e.g., allow-users, allowed_non_write_users) and workflow-level guards (e.g., sender allowlists, author association checks).
• Propagation rules: These include source initialization, workflow data propagation, P2A detection (reported when taint reaches the prompt boundary of an agentic action), model/agent output bridging (when taint reaches the prompt boundary, the derived output of the same invocation is treated as tainted), and P2S detection (reported when tainted derived output reaches a security-sensitive downstream sink).
• Reachability analysis: Checks whether reported paths are reachable by an attacker under workflow execution conditions and action invocation guards, filtering out unreachable paths. A vulnerability is reported only when a taint path exists and remains attacker-reachable after applying action-level and workflow-level guards.

Experimental Setup

• Subjects under test: 13,392 real GitHub Actions workflows from 10,792 repositories, which directly invoke at least one agentic or AI-assisted action.
• Action characterization: 1,033 AI-assisted actions, of which 160 are agentic and 572 are LLM-assisted; 292 are AWI-related candidates (113 agentic, 179 LLM-assisted).
• Baseline tools: PISCANNER, OPENGREP, ARGUS, CODEQL. ARGUS and CODEQL were provided with the same agentic-action prompt vocabulary points specification as TAINTAWI.
• Implementation and environment: TAINTAWI is implemented in Python, with the online analyzer at 3.6 KLoC and the full implementation at approximately 4.5 KLoC. Experiments were conducted on a single Ubuntu 22.04.5 LTS server with 256 CPU cores, 1.0 TiB of memory, and Python 3.9.15.
• Evaluation metrics: precision, true positives (TP), false positives (FP), coverage. Because real-world vulnerability detection lacks complete ground truth, full precision or recall is not reported; instead, the number of workflow-level alerts across the full corpus and the coverage of 496 confirmed TP cases are reported.
• Manual verification: the authors manually reviewed all reported cases, confirming 496 as exploitable and 23 as false positives. For false negatives, 100 cases reported only by each baseline tool were randomly sampled (400 in total), and manual review identified 13 false negatives of TAINTAWI.

Main Results

Swipe horizontally to read the table

Tool	#Alerts	#TP Cov.	#P2A	#P2S	#Missed
PISCANNER	2,079	78	78	0	418
OPENGREP	1,658	73	73	0	423
ARGUS	831	66	66	0	430
CODEQL	1,486	76	76	0	420
TAINTAWI	519	496	103	419	0

According to Table V

• Authors' interpretation: PISCANNER and OPENGREP report many alerts but low coverage because they only heuristically identify AI-like usage or match untrusted expressions embedded directly in prompt fields, without building workflow-level dependency graphs or modeling derived outputs. ARGUS and CODEQL can recover some P2A flows after being provided with AI prompt inputs as sinks, but they remain at the prompt boundary and miss P2S cases. By modeling prompt-boundary flows and derived-output propagation, TAINTAWI covers 418 more TPs than the strongest baseline.

Zero-Day Vulnerability Disclosure

• Overall results: TAINTAWI initially reported 519 potential AWI vulnerabilities; manual review confirmed 496 as exploitable (precision 95.6%) and 23 as false positives. Of the 496 confirmed TPs, 153 had already been reported by the community but not fixed, and 343 were zero-days.
• Disclosure status: 187 zero-day cases were prioritized for disclosure (repositories with GitHub stars or at least one successful workflow run history). Of these, 102 repositories had no available private disclosure channel, and 85 were formally reported via GitHub Security Advisories, email, or repository-specific channels. Responses were received from 26 maintainers, and 24 cases were accepted or fixed. These fixed or accepted cases affect 23 unique repositories with over 130K total stars, involving multiple AI-assisted actions (according to Table IV).

Ablation Study

Swipe horizontally to read the table

Variant	#Report	#Covered	#P2A	#P2S
Full TAINTAWI	519	496	103	419
w/o Derived-output Bridging	117	103	103	0
w/o Workflow Bridges	102	89	89	0
w/o Script Analysis	462	442	89	372
w/o Guard Analysis	881	496	103	419

According to Table VI

• Authors' interpretation: derived-output bridging is critical for P2S detection; disabling it reduces coverage from 496 to 103 and makes P2S cases undetectable. Removing workflow bridging further reduces coverage to 89, indicating that many AWI paths depend on workflow data channels. Script analysis also contributes; disabling it reduces coverage from 496 to 442 and P2S coverage from 419 to 372. Disabling guard analysis increases the number of reports from 519 to 881, indicating that reachability analysis helps control false positives.

Efficiency Evaluation

• Performance: TAINTAWI completes online analysis of 13,392 workflows in 12.32 minutes, averaging 0.054 seconds per workflow, with a median of 0.008 seconds and a maximum of 11.360 seconds, at a throughput of 18.12 workflows/second. Peak memory is 0.276 GB, with an average of 1.11 CPU cores used.

Characterization Analysis (RQ3)

• Guard paths: of the 881 workflows with AWI-related taint paths, 362 (41.1%) contain effective guards; 306 (34.7%) use only action-level guards, 27 (3.1%) use only workflow-level guards, and 29 (3.3%) use both.
• AWI patterns: of the 496 confirmed cases, issue titles/bodies are the primary source (429 cases, 86.5%), followed by PR fields (50 cases, 10.1%) and comment/review bodies (24 cases, 4.8%). P2S is the primary sink pattern (419 cases, 84.5%), and P2A occurs in 103 cases (20.8%).
• Security impact: GitHub write/API operations appear in 391 cases (78.8%), shell or tool execution in 307 cases (61.9%), and file/workspace writes in 81 cases (16.3%).
• Ecosystem distribution: the 496 confirmed cases span 440 unique repositories with 421,098 total stars. The largest cluster comes from actions/ai-inference (393 cases, 79.2%).

Limitations and Future Directions Noted by the Authors

• Static over-approximation: TAINTAWI is a static analyzer and may report paths that are syntactically feasible but difficult to exploit in practice (due to repository-specific policies, unavailable secrets, failed workflow runs, or undocumented runtime behavior of third-party actions). The authors mitigate this through reachability analysis and manual validation, but fully modeling GitHub runtime behavior and the internal implementation of each action remains challenging (§ VII-B).
• Incomplete action semantics: TAINTAWI relies on action-level taint specifications, but the GitHub Actions ecosystem evolves rapidly, and long-tail or newly released actions may expose prompt or output interfaces that have not yet been modeled. Missing or outdated specifications may lead to false negatives (§ VII-B).
• Limited embedded script analysis: TAINTAWI currently performs lightweight analysis of common shell run steps and uses YASA to analyze inline JavaScript in actions/github-script, but does not provide full data-flow analysis. Complex shell semantics, cross-file scripts, and dynamically generated commands may be missed. The authors consider more complete multilingual script analysis to be important future work (§ VII-B).

Experimental Coverage

• Workflows tested: 13,392 real GitHub Actions workflows from 10,792 repositories, which directly invoke at least one agentic or AI-assisted action (§ VI-A).
• Action characterization: 1,033 AI-assisted actions, of which 292 are AWI-relevant candidates (113 agentic, 179 LLM-assisted) (§ IV-B).
• Baseline comparison: Compared with four baseline tools (PISCANNER, OPENGREP, ARGUS, CODEQL) on the full corpus; ARGUS and CODEQL were provided with the same agentic-action prompt sink specifications (§ VI-A).
• Manual validation scale: All 519 reported cases were manually reviewed; 400 cases reported only by baseline tools were sampled for false-negative evaluation (§ VI-C).
• Not reported in the paper: Complete ground truth (therefore complete precision or recall is not reported); the specific LLM model name or version used by TAINTAWI (described only as an "LLM-assisted analyzer"); detailed error analysis of the false-negative evaluation (attributed only to incomplete taint specifications, script-level sink patterns, and propagation semantics).

This paper studies the security of LLM-based agentic workflows in GitHub Actions. The authors define Agentic Workflow Injection (AWI), a new type of workflow-level injection vulnerability in which untrusted GitHub event context (such as issue bodies, PR descriptions) is incorporated into agent prompts or downstream workflow logic, causing attackers to influence agent behavior. AWI includes two patterns: Prompt-to-Agent (P2A) and Prompt-to-Script (P2S).

The authors characterize 1,033 real AI-assisted actions and find that only 21 provide explicit caller identity access control. Based on this, they design the TAINTAWI static analyzer, which detects AWI vulnerabilities by inferring action-level taint specifications, building a workflow intermediate representation (IR) and an Agentic Workflow Dependency Graph (AWDG), and performing taint propagation and reachability analysis.

Evaluation on 13,392 real workflows shows that TAINTAWI reports 519 potential vulnerabilities, of which 496 are manually confirmed exploitable (precision 95.6%), including 343 zero-day vulnerabilities. Compared with four baseline tools, TAINTAWI covers 418 more confirmed cases. An ablation study shows that derived output bridging is critical for P2S detection. The authors prioritized disclosure of 187 zero-day cases, 24 of which have been accepted or fixed.

The authors argue that AWI is a practical risk caused by reusable agentic actions and requires secure-by-default action interfaces and safer workflow composition practices. For action developers, they should provide built-in access control, separate trusted instructions from untrusted content, and expose typed outputs; for workflow developers, they should treat GitHub event context as untrusted, implement workflow-level access control, and validate model-derived outputs.