opengrep-rules: The security rule that treats prompt injection like RCE

AikidoSec’s opengrep-rules repository shows how static analysis is moving from code bugs to AI workflow abuse, one YAML file at a time.

9 min read • View on GitHub • More from AikidoSec

An editorial illustration of a workflow file turned into a drawbridge, with untrusted PR scraps feeding into a prompt chamber and a small tool-wielding machine waiting on the other side. It visualizes the article's core idea: a GitHub Action can turn user-controlled text into an execution path when an LLM has tools. — The danger is not the prompt alone. It is the path from untrusted GitHub context to a tool-enabled action.

Key Takeaways

Opengrep-rules turns AI workflow prompt injection into a static-analysis problem that security teams can actually automate.
Its strongest rule is narrow on purpose, because precision matters more than broad coverage when false positives kill trust.
The repo is also a signal about governance, with open rules positioned as the antidote to locked-down security tooling.
The interesting shift is not just that GitHub Actions are being scanned, but that prompts are now treated like a security sink.

Most security tools still look for old favorites: secrets, SQL injection, dependency risk, and obvious bad patterns in source code. opengrep-rules goes after something newer and stranger. It asks a simple question with big consequences: what happens when a GitHub Action turns untrusted repository data into an LLM prompt, and that LLM can touch tools?

Why this repo exists

The repository is small, but the politics around it are not. Aikido Security published these rules as part of the Opengrep ecosystem, which was created to keep open static analysis open after Semgrep changed course on licensing and community control. That context matters, because this is not just a rule pack. It is an argument that security detections should stay inspectable, forkable, and vendor-neutral.

We’ve united with 10 direct competitors to launch Opengrep—a coordinated, industry-wide stand to keep a great open-source project alive and make secure software development vendor-neutral, shared standard.

Willem Delbare, Author · Launching Opengrep

The strategic point is bigger than one fork. If your detection logic is a black box, you can still buy it. You just cannot really inspect it, adapt it, or trust it in the way an internal security team needs. Opengrep’s appeal is that the rules stay readable, and the threat model stays visible.

Static code analysis is too important to be restricted... By creating Opengrep, we're ensuring that security tooling remains open, innovative, and community-driven. This isn't just about preserving existing capabilities—it's about building a future where security tools evolve through collaboration rather than commercial interests.

Endor Labs, Contributor · Socket on Opengrep

What the rule is actually hunting

The key file lives under rules/github_workflow_prompt_injection/github_workflow_prompt_injection.yaml, which tells you a lot about the scope. This is not scanning arbitrary YAML. It is looking specifically at GitHub workflow files, where user-controlled context can slip into prompts through fields like issue bodies, titles, labels, branch names, and step outputs.

A close-up illustration of a YAML rule under a magnifying glass, with one branch of variables spilling toward a sealed box and another toward a tool chest. It explains why the rule is selective: it hunts for user-controlled fields instead of every GitHub variable. — The rule is selective by design. It targets the fields an attacker can influence, not every variable GitHub exposes.

pattern-regex: '\${{\s*(?:github\.[^}]*\.(?:body|default_branch|email|head_ref|label|message|name|page_name|ref|title)|steps\.[A-Za-z0-9_-]+\.outputs(?:\.[A-Za-z0-9_-]+)+)\s*}}'

# Comment this out, in case you also want to consider potential risks from insiders/trusted users.
allowed_non_write_users: "*"

That regex is the heart of the rule. It does not shout at every github.* variable. It narrows in on the ones an attacker can plausibly control, then watches for those values inside a prompt. The second branch is even more pointed: if a Claude Code action is allowed to use tools and is open to non-writing users, the prompt becomes more than text. It becomes a path to code execution or file access.

The rule tracks data flow, not just syntax. That is the right instinct when a prompt can steer a tool-enabled action.

Why this is a new kind of SAST

Traditional static analysis grew up around code. This repository is aimed at the logic that surrounds code now: workflow automation, AI orchestration, and the handoff between untrusted text and privileged tools. That makes it feel less like a linter and more like a guardrail for a new control plane.

Approach	What it scans	Strength	Blind spot
Traditional SAST	Application source code	Catches classic bugs across large codebases	Misses workflow abuse and prompt-level risks
opengrep-rules	GitHub workflow YAML	Targets AI prompt injection with low noise	Only works where the rule author has modeled the threat
Manual review	Human judgment	Sees context and intent	Does not scale across every repository and workflow

That tradeoff is the whole game. A broad rule that flags every GitHub context variable would produce noise and get ignored. A tighter rule gives teams something they can run in CI, trust on first pass, and actually act on. In security tooling, precision is not a luxury. It is the product.

The deeper lesson is that LLM prompts are now part of the attack surface. Once a workflow mixes untrusted text with an action that can read files, call tools, or reach a shell, the security boundary is no longer just the repository. It is the route from input to instruction to execution.