For three years, prompt injection lived in the "cute research demo" corner of the threat landscape. That stopped being the right place to put it the moment agents started opening pull requests, running build scripts, and pushing containers. Injection is now an input to your CI/CD pipeline, which makes it a software supply chain risk with all the attached severity. This post treats it as one and walks through how it actually lands in shipped code.
How does prompt injection become a build-time risk?
Through any agent that reads untrusted content and then writes code or configuration. The canonical example in 2025 was the "assistant-maintained README" pattern, where an LLM agent updated READMEs across a monorepo based on the contents of source files. A maliciously crafted comment in a single dependency's source, surfaced through the agent's scan, was enough to get the agent to add a line to a different repo's GitHub Actions workflow. That workflow then did something interesting during the next CI run.
The pattern generalizes. Any time an agent has (a) read access to a mutable corpus, (b) write access to code or pipeline config, and (c) no human-in-the-loop checkpoint between them, prompt injection becomes a build-time primitive. The attacker doesn't need to compromise your package registry or your CI system. They just need to put content somewhere your agent will read. That "somewhere" can be a GitHub issue on a public repo, a field in an internal ticketing system, a log line from a deployed service, or a file in a vendored dependency.
Where is the injection corpus in a real codebase?
Larger than most teams realize. When security teams audit for prompt injection risk, they usually think about "the web" and stop. The actual corpus an agent sees in a typical engineering workflow includes: source code in every dependency (including transitive ones), docstrings, commit messages, PR descriptions, issue bodies, inline comments, test fixtures, error logs from local runs, and any markdown the agent is asked to summarize. Every one of those is user-influenced in some sense.
The Hugging Face ecosystem gave us a preview of where this goes. Model cards are markdown. Datasets have READMEs. Many of them are scraped and summarized by AI agents as part of discovery or evaluation pipelines. A crafted model card with embedded instructions, served to a procurement agent deciding which model to download, can influence that decision in ways the human operator never sees. This is not hypothetical. Several teams reported variants of this in late 2025 when they started auditing their model selection pipelines.
What makes this a supply chain problem specifically?
Because the injection payload rides on artifacts you imported. When PyTorch nightly was compromised in late 2022, the attack vector was a dependency confusion trick that installed a malicious package. The actionable lesson was: pin your deps, verify provenance, watch your registry. Prompt injection adds a new axis. Now the malicious payload does not need to be code. It can be prose embedded in a dependency's documentation, and it becomes active the moment an agent reads it.
That changes the review surface. The old surface was "what does this dependency's code do when it runs?" The new surface is "what does this dependency's content do when an agent reads it?" You cannot answer that with static code analysis alone. You need content-level scanning, and you need it across the same dependency graph depth you already scan for vulnerabilities. A dependency five levels deep in your tree whose README includes a well-placed instruction is a live payload as soon as an agent gets close to it.
How should agent pipelines be segmented?
Read and write must not share the same session, and agents that touch untrusted corpora must not hold production credentials. Concretely, the pattern that holds up is a two-stage pipeline. A first-stage agent reads widely, has strong content-consumption capabilities, and has zero write access or credentials beyond its local scratch space. A second-stage agent performs actions, has scoped credentials, and receives only structured, schema-validated outputs from the first stage. The structured schema is the trust boundary. Anything outside the schema is discarded before it reaches the second stage.
This mirrors patterns from web security. You do not let an unauthenticated user submit HTML directly into your rendered output; you sanitize through a known-good shape. The equivalent for agents is that the second stage should not receive free-form text from the first stage at all. It should receive a JSON object matching a strict schema, and any field that cannot validate kills the whole request.
The single-stage pattern (one agent with both read and write) is where almost every 2025 incident happened. It is convenient, it is what frameworks default to, and it is structurally unsafe for anything that produces shipped artifacts.
What does detection look like?
Content classifiers at tool output boundaries, plus diff review on anything an agent writes to a persistence layer. The classifier question is "does this content look like it is trying to be an instruction to a reader," and reasonable classifiers exist for this. They are not perfect and they generate noise, but they catch the crude attacks and raise the cost of the sophisticated ones. For agents that produce code, every change should generate a diff that is either auto-merged only after passing policy (no new network calls, no new credentials referenced, no out-of-scope files touched) or routed to a human.
Some teams have started logging the full agent trace for every session: the tool inputs, the tool outputs, the model completions, and the actions. That's the right default for anything in the critical path. If an agent does something wrong, you want to be able to trace back to the specific piece of retrieved content that steered it there. Without that log, incident response is archaeology.
How does this interact with dependency scanning?
It extends it. The scan that tells you a package has a CVE in its compiled code should also be telling you whether any of its prose content contains instruction-shaped payloads. This is not a separate tool space from software composition analysis; it is an expansion of it. And because the prose is small relative to the code, the scan is cheap once you have the artifact collection infrastructure in place. What stops teams is not cost but category confusion: they think of SCA and "AI safety" as different budgets.
The right model is that SCA in 2026 covers code, binaries, models, and content, all keyed off the same artifact graph. Anything less leaves a large blind spot.
How Safeguard.sh Helps
Safeguard.sh runs reachability analysis across dependency graphs that include both code and AI-facing content, cutting 60 to 80 percent of the false positives that drown out real signal in prose-heavy corpora. Griffin AI looks specifically at injection patterns in docstrings, READMEs, and model cards at the same time it evaluates code vulnerabilities, so prompt injection risk surfaces in the same SBOM view as CVEs. TPRM workflows flag agents and MCP integrations whose upstream content sources have changed risk posture, and the 100-level dependency depth catches transitive prose payloads the same way it catches transitive code compromises. Container self-healing ensures that when a package ships a fix for either content-based or code-based issues, downstream images rebuild without manual intervention.