GitHub made indirect prompt injection a build time finding this week. On October 28, 2026, code scanning for AI applications entered public preview, and it can flag the agent architectures most exposed to indirect prompt injection (XPIA), sensitive information disclosure, and excessive agency. The scans run automatically on pull requests, alongside existing CodeQL analysis, and they flag the code paths where untrusted content, a file, a webpage, or an issue comment, can reach a model that has access to tools, data, or business systems.
That is a real step forward. It is also only half the problem, because the other half does not exist until the agent is running.
What researchers found in the wild
At [un]prompted II this week, Radware researchers Gabi Nakibly and Zvika Babo presented a scan of 86 million GitHub items, issues, pull requests, comments, and README files, hunting for hidden instructions aimed at AI coding agents. They found prompt injections in approximately 2.5 of every 100,000 items examined.
The method matters. They extracted hidden text, including HTML comments, then ran heuristics plus a two-stage LLM classifier, with manual review of every flagged candidate. The hiding place is the point: HTML comments in Markdown do not appear in the normal rendered page, so a human reviewer sees an ordinary bug report while an agent processing the underlying Markdown encounters extra instructions.
The hidden instructions fell into four categories: agent orchestration (legitimate project automation), restrictions on visiting bots, growth hacking (promotional manipulation), and malicious activity, including attempted exfiltration of sensitive data. Only the last category is malicious. Most of what they found was not an attack. In an expanded dataset of approximately 145 million items, they identified 47 attack attempts, plus thousands of other hidden instructions tied to orchestration, content manipulation, and defensive restrictions.
Two limits in the report deserve emphasis. The study documents attempts, not a measured success rate and not confirmed compromises. And the scan concentrated on hidden text, so it cannot capture every form of prompt injection, and the classifier pipeline may have missed attacks. The real number is unknown, in both directions.
Why build time scanning cannot cover the runtime
GitHub's new check answers a design question: can untrusted content reach the model along this code path? That is the right question to ask before merge. But the content itself arrives later. The issue comment that carries the hidden instruction is written after deployment. The webpage the agent reads is fetched at inference time. The MCP tool result that returns poisoned data was never in the repository, so no pull request check ever saw it.
Runtime is also where the blast radius lives. A flagged code path is a possibility. A live prompt carrying an instruction to exfiltrate data, issued to an agent holding credentials and tool access, is an event in progress. Scanning the architecture does not inspect the prompt. Inspecting the prompt does not fix the architecture. You need both, and they are different jobs.
There are practical limits on the GitHub side too. The feature is in public preview on github.com, requires a GitHub Advanced Security license, and does not yet work on GitHub Enterprise Server. No timeline for general availability has been given, and no false positive rate at scale has been published. Teams running self-hosted GitHub, or waiting on the preview, have no coverage from this check at all today.
A short checklist for teams shipping agents
Treat repository content as untrusted input. Every issue, comment, README, and webpage your agent reads is data, not instruction, until proven otherwise.
Verify authority outside the content. An instruction inside a file or comment proves nothing about who authorized it. Check the sender, the channel, and the permission separately.
Limit agent privileges. Give each agent the minimum tools, data, and system access its job requires, so a successful injection buys the attacker as little as possible.
Inspect tool calls as well as inputs. A clean prompt can still produce a dangerous call. Watch what the agent is about to do, not only what it was told.
Govern the live traffic. Build time checks catch architecture. Runtime inspection catches the prompt, the response, and the tool call as they happen, with policy enforced before the action executes.
That last item is where AI-FW fits. It sits between AI agents and LLM backends and inspects every prompt and response at runtime, with agent identity and policy enforcement, so an instruction hidden in content the agent reads at inference time is inspected before it can drive a tool or data access. It is the complement to GitHub scanning, not a replacement for it. The Community Edition is free to use, includes enterprise grade features, and covers 10 billion tokens per rolling 30 days with no credit card required.
Build time scanning just made indirect prompt injection visible before merge. The injections researchers found in the wild were already living in the content agents consume every day. Closing the runtime half is the work that remains.
Sarah Reid works at Securetron, where she covers AI agent security and certificate lifecycle management.
Top comments (0)