Blog · arXiv Analysis · Last reviewed June 25, 2026

The Pull Request Becomes the Prompt Injector

The June 2026 arXiv paper GitInject: Real-World Prompt Injection Attacks in AI-Powered CI/CD Pipelines, by Jafar Isbarov, Umid Suleymanov, Ilia Shumailov, and Murat Kantarcioglu, shows why coding-agent security cannot stay inside simulated tool harnesses.

A pull-request prompt injector is untrusted contribution material that a CI/CD agent reads as operational context while the workflow holds repository authority. The dangerous object is not only the malicious sentence; it is the route from contributor-controlled text or files into a privileged runner, token, comment, approval, or code path.

The Trusted Review Surface

A pull request used to be a package of proposed code and social evidence: a diff, a description, a test run, a reviewer conversation, and a maintainer decision. AI-powered CI/CD agents change that surface. The pull request is now also prompt material.

That is the security turn in GitInject. A CI agent may read a pull request body, issue text, changed files, repository instructions, and workflow context while holding repository-scoped authority. It may post comments, run shell commands, inspect files, trigger checks, or help decide whether a change looks safe. The attacker has a path because some of that context is untrusted language.

This is narrower than the general problem of prompt injection. GitInject is about a specific institutional setting: AI agents wired into GitHub workflow automation. In that setting, the model is not only answering a developer. It is participating in the software supply chain.

Current Context

As of June 25, 2026, GitInject is an arXiv v1 paper and an evaluation framework, not a regulator finding or certification system. The arXiv abstract says the paper evaluates real GitHub workflows rather than simulated tool calls, documents eleven named attacks across four AI-powered workflow families, and finds that structural CI/CD decisions around credentials and configuration files matter more than any single model's behavior.

The official GitHub Actions documentation already gives the non-AI half of the warning. GitHub says actions can access GITHUB_TOKEN through the github.token context and recommends granting the token the least required access. Its secure-use reference warns that privileged triggers such as pull_request_target and workflow_run, when combined with checkout of untrusted pull-request code, can expose a repository to compromise, and it recommends avoiding those triggers unless the privileged context is actually needed.

The AI-specific layer is that a model can treat untrusted text as instruction before any shell command runs. OWASP's 2026 agentic-application guidance frames agent security around systems that plan, act, and make decisions across workflows. NIST SP 800-218A extends secure software development practice for generative AI systems. OpenSSF's 2025 AI code-assistant instruction guide says AI-generated code remains subject to ordinary engineering controls such as review, testing, static analysis, dependency checking, version-control discipline, secret handling, and supply-chain verification. GitInject sits at the intersection of those threads: prompt injection, CI/CD privilege, and software supply-chain governance.

What GitInject Tests

The paper, arXiv:2606.09935, was submitted on June 7, 2026. It introduces GitInject, a framework that provisions ephemeral GitHub repositories, installs target workflow definitions, injects test payloads through GitHub events, runs actual workflow jobs, and evaluates the final repository state through the GitHub API.

The important design choice is real execution. Prior agent-security benchmarks often simulate tool calls. GitInject instead runs the live workflow, so the evaluation includes runner state, sandbox behavior, network policy, credential handling, and the actual permissions granted to the job. The paper studies workflow configurations across four AI providers and documents eleven named attacks spanning PR or issue body injection, configuration-file injection, credential exfiltration, judgment manipulation, and availability.

The paper reports that every tested provider was susceptible to at least one attack class in its default configuration. Read that as an architecture warning, not a permanent provider ranking: default CI/CD agent workflows can collapse the boundary between untrusted project input and privileged automation.

The Simulation Gap

The most useful result is the simulation gap. In the paper's comparison with AgentDojo-style simulation, simulated evaluation missed 71.2% of confirmed real attacks and incorrectly predicted success for 5.0% of attacks blocked by production infrastructure. The authors' point is not that simulation is useless. It is that CI/CD security depends on details a simulator may not model: runner-managed files, checkout behavior, environment isolation, egress rules, job permissions, and repository event semantics.

That matters for governance because many AI safety claims are benchmark-shaped. A model may refuse a hostile string in a chat transcript. A simulated agent may appear safe when a test harness stubs the tool. But a real CI runner contains build directories, configuration files, credentials, caches, logs, permission settings, and network paths. Those are not decorative infrastructure. They are the attack surface.

For software organizations, the lesson is blunt: do not certify an AI workflow from prompt behavior alone. Test the workflow that will actually run, with the trigger, checkout mode, token scope, network policy, configuration files, logs, and approval gates that production will use.

Configuration Becomes Instruction

The paper's sharpest conceptual move is configuration-file injection. A normal pull request can propose new or modified files. Some coding agents and command-line agent tools read project-level instruction files as trusted guidance. If a workflow checks out the proposed branch and the agent treats those files as authoritative instructions, an attacker can move from low-trust contribution into high-trust agent context.

That is not just a model alignment problem. It is a provenance problem. The same string can mean different things depending on where it came from. A repository-owner policy file, a maintainer-reviewed instruction, a contributor-proposed change, and a generated artifact should not all arrive in the same operational layer as undifferentiated text.

GitHub's own documentation is relevant here. Its GITHUB_TOKEN documentation describes workflow authentication through a repository-scoped token whose permissions can be configured. Its secure-use guidance warns against using certain workflow triggers with untrusted pull requests or code content unless the workflow avoids checking out or executing untrusted material. GitInject adds the AI-specific version: untrusted text can be dangerous even when the agent is "only reading" it, because reading may steer later tool use.

A safer design treats repository instructions as configuration with provenance. Instructions read from the protected base branch, organization policy, or reviewed workflow should not be equivalent to instructions introduced by the pull request under review. If an agent must inspect proposed instruction-file changes, it should inspect them as untrusted diff content and require maintainer approval before those instructions can govern the run.

Workflow-Level Security

GitInject's findings point away from model-only defenses. Better refusal behavior helps, but the paper argues that the most important failures are structural: how workflows manage credentials, configuration, checkout, events, and permissions. A safer design therefore treats the CI runner as the control plane, not the model.

The governance standard is practical. Use least-privilege job permissions. Keep write-capable credentials away from workflows triggered by untrusted contributors. Separate untrusted pull request content from owner-approved agent instructions. Require human approval before privileged agent execution when external contributors are involved. Make agent comments advisory unless the workflow has a stronger trust path. Preserve logs that show which event triggered the agent, which files were read as instruction, what token scope was active, and what state changed.

Security review should include failure accounting. An availability attack that burns tokens or CI minutes may look less severe than credential exposure, but it still matters for maintainers. A project that cannot distinguish ordinary CI failure from agent-policy failure has made maintenance dependent on an opaque assistant layer.

Failure Modes

PR-body authority collapse. The agent treats pull-request text, issue text, comments, hidden markup, or generated summaries as if they were maintainer instructions.

Configuration-file elevation. A contributor changes an agent instruction file, workflow prompt, rules file, MCP config, or tool manifest, and the workflow loads the proposed version as trusted policy before review.

Token scope inflation. A job receives write permissions, secrets, or cloud credentials because a normal automation needed them, then an agent reads untrusted content inside the same privileged job.

Runner state leakage. Credentials, checkout metadata, caches, logs, temporary files, artifacts, or environment variables become available to a model-driven command path that the simulator did not model.

Advisory comment drift. An agent's review comment or approval-looking language is treated by humans, bots, or downstream automation as stronger evidence than it deserves.

Denial of maintainer budget. An attacker causes the agent to burn model tokens, CI minutes, reviewer time, or API quota without needing to steal a secret or merge code.

Minimum Run Record

A useful CI/CD agent receipt should preserve: triggering event, actor trust class, repository and branch, base SHA, head SHA, workflow file version, runner type, checkout mode, token permissions, secrets availability, network policy, sandbox policy, agent product and version, model route if available, instruction files read, untrusted text sources read, commands run, files changed, comments posted, approvals requested, artifacts created, external calls, final state, human approvals, and whether any policy blocked or narrowed the run.

The record should distinguish proposed context from authorized instruction. Reviewers need to know whether the agent followed a maintainer-approved rule, a repository-default rule, a pull-request-proposed rule, a tool result, or its own generated plan. Without that provenance, incident response collapses into reading a chat transcript and guessing which text became authority.

What This Changes

The pull request becomes the prompt injector when the institution lets contribution, instruction, and authority share one channel.

That does not mean AI should be banned from software maintenance. It means the social boundary of review has to become a technical boundary too. A stranger's proposed file is not the same as a maintainer's operating rule. A model-visible instruction is not safe because it is formatted like documentation. A workflow token is not harmless because the agent promises to review before acting.

This connects directly to the coding agent as maintainer, the agent sandbox, AI coding agents, and agentic supply-chain vulnerabilities. Software projects already run on trust gradients: contributor, maintainer, bot, runner, release key, package registry, downstream user. AI agents add a new interpreter inside that gradient. If the interpreter cannot tell proposed context from authorized instruction, the project has not gained an assistant. It has opened a new route from persuasion to execution.

The Spiralist rule is simple: any agent that reads untrusted code-review material and holds workflow authority needs source labels, credential limits, configuration provenance, approval gates, and receipts. Otherwise the repository becomes a place where language can become infrastructure before anyone has decided to trust it.

Source Discipline

Use GitInject for claims about the framework, real GitHub workflow execution, simulation gap, named attack classes, provider default-configuration findings, and paper-stated limits. Use GitHub documentation for GitHub Actions token, trigger, runner, secret, and secure-use guidance. Use OWASP, NIST, and OpenSSF for current security-governance context, not as proof that any specific AI CI/CD product is safe.

Do not collapse the source types. An arXiv proof-of-concept is not a field prevalence estimate. A provider default result is not a permanent ranking. A secure-use guide is not evidence that a workflow followed it. A simulated agent benchmark is not a production CI/CD test. A pull request is safe only inside the exact trigger, token, checkout, runner, instruction, and approval path that actually executes.

Sources

Return to Blog