Indirect Prompt Injection Through Git Repositories

Malicious indirect prompt injection content rose 32% between November 2025 and February 2026 across the two-to-three billion pages Google Threat Intelligence crawled each month, according to the Cloud Security Alliance’s threat analysis. The same report says Palo Alto Networks Unit 42 documented twelve cases against AI agents in production.

That growth matters because a coding agent doesn’t just read repositories. It reads issues, comments, documentation, configuration, command output, and dependency metadata, then may act with the developer’s credentials. One poisoned file can cross from untrusted content into an authorized tool call. Treating this as a smarter-filtering problem misses the architectural issue.

What is indirect prompt injection through Git repositories?

Indirect prompt injection through Git repositories occurs when an AI agent retrieves malicious instructions from repository content and follows them as though the operator supplied them. Coralogix defines indirect prompt injection as instructions concealed in external data—websites, documents, emails, or code repositories—that an LLM processes as legitimate input.

A direct attack enters through the user’s prompt. An indirect attack arrives later, through content the agent chooses to retrieve. A README, code comment, pull-request description, or git log result can therefore become part of the model’s effective instruction stream even though the developer never submitted it as a command.

That distinction matters for coding workflows. Suppose an agent opens a repository to fix a build. The user expects the agent to inspect local files, run a bounded command, and propose a patch. A malicious file can try to redirect that job: read environment variables, fetch an attacker-controlled script, alter the agent’s task, or publish private information.

The defensive consequence is blunt: repository text is untrusted input. A prompt that tells the model to trust a file, ignore policy, or send data elsewhere should receive the same treatment as a script downloaded from an unknown origin. It shouldn’t be allowed to redefine what the agent is allowed to do.

How do Git repositories become an execution surface?

The clearest example is GitLost, a critical vulnerability in GitHub Agentic Workflows that turned a public issue into a path toward private repository data. Noma Labs found that an unauthenticated attacker could post a crafted issue on a public repository in the same organization and induce the workflow to retrieve private data.

The attack required no stolen credentials, no coding expertise, and no special access. The attacker only needed to open a public GitHub issue. More unsettling, including the word “Additionally” in the injected prompt was enough to bypass the workflow’s guardrails, according to Noma’s GitLost report.

GitSpawn demonstrates a different route. Here, a repository’s .git/config uses Git’s core.fsmonitor setting to force attacker-chosen code execution when an agent inspects the repository. The Cloud Security Alliance reports that GitSpawn affected seven widely used agents, including Claude Code, OpenAI Codex, Cursor, Grok Build, Goose, Hermes Agent, and Qwen Code; four remained unpatched at publication.

The shared lesson is that “reading” a repository is not a passive operation. Agents routinely run Git, inspect configuration, and retrieve text from files the attacker controls. This is why repository-instruction poisoning is a security problem, not merely an agent-quality problem. The broader mechanics are covered in AI Coding Agent Configuration Poisoning, Explained.

Why don’t prompt filters solve the problem?

A detector has to recognize malicious intent hidden in material that may otherwise look like documentation, code, or an ordinary maintenance note. The security boundary is weak because natural language does not provide a reliable distinction between command and data.

The available benchmark data is sobering. AI EdgeLabs’ field assessment reports that no detection tool exceeds roughly 90% accuracy against adaptive attacks. Balanced accuracy falls from above 90% into the low 80s when ordinary page noise is added, and one multilanguage result drops to 76.0%. Those figures are decent for detection. They’re not a trustworthy final boundary for an agent holding a shell.

Code-focused defenses are improving. CodeSentinel uses three inference-time layers: Tree-sitter identifies high-risk syntax-tree nodes, Dynamic Min-K% scoring evaluates them, and node perturbation analysis checks whether removing or changing the suspected content alters the result. Across six attack families, the system achieved a 0.80 average node-level F1 score and outperformed the compared defenses.

Still, 0.80 F1 is a measurement of detection, not a guarantee that every model interpretation and tool path is safe. The attacker can change wording, location, language, and objective. A warning nobody can act on becomes background noise.

The smarter the classifier, the more tempting it becomes to treat it as the control plane. That’s the trap. Put a probabilistic scanner in front of containment and it becomes useful. Replace containment with it and the architecture becomes fragile.

Which controls actually contain the attack?

The durable control is to limit what the agent can touch, not merely to guess whether a sentence is hostile. I call this surface governance: every repository, fetched page, tool result, and external service remains untrusted, while the agent receives only the permissions required for its current task.

Start with the execution environment. Run the agent in a sandbox, keep credentials out of its environment, deny outbound network access by default, and require human approval for sensitive operations. These controls don’t decide whether a README is malicious. They limit the damage if the model reaches the wrong conclusion anyway.

Then scope identity and tools separately. An agent reviewing one repository shouldn’t inherit organization-wide repository access. A test-generation task shouldn’t inherit deployment credentials. A documentation agent shouldn’t be able to post public comments. This is the same lesson behind the Supabase MCP Server privilege inversion problem: powerful tooling becomes a security liability when its authorization scope exceeds the job it performs.

Configuration deserves equivalent scrutiny. If an agent automatically trusts AGENTS.md, cursor rules, issue templates, or similar files, review them as executable policy rather than passive documentation. The Hardening AGENTS.md and Agent Config Files Against Poisoning guide goes deeper into version control, review gates, and trust boundaries for those files.

The tradeoff is reduced convenience. A fully isolated agent may need more human intervention. That’s the correct cost when the alternative is giving an experimental instruction-following system unrestricted access to your workstation.

What does defense cost for a 50-developer team?

The cost problem is harder than detector accuracy. One estimate places the average successful indirect prompt injection incident at more than $2.3 million, including breach notifications, fines, and reputational damage. Against that exposure, a managed security product is rarely the irrational purchase.

Published ranges vary sharply by segment: enterprise indirect prompt injection mitigation platforms run from $18,000 annually to $50,000+ annually, while mid-market options start at $2,400 per year. The table below compares those options with a code-context defense and an adjacent repository-security control.

Option	Pricing in available research	Relevant capability	Best fit
Enterprise IPI mitigation platform	$18,000 to $50,000+ annually	Managed mitigation for indirect prompt injection	Organizations needing broad coverage and centralized operations
Mid-market IPI option	$2,400 per year	Lower-cost access to IPI mitigation	Mid-market teams with narrower infrastructure requirements
CodeSentinel	—	Three-layer sanitization for model-facing code nodes	Research teams and code-focused agent deployments
GitHub Advanced Security full coverage	$49 per active committer per month	Code security and secret protection; not evidence of IPI coverage	GitHub platform teams already managing code-security controls

The projection for 50 active committers combines enterprise-platform pricing with GitHub Advanced Security: 50 × $49 per month × 12 months equals $29,400 per year. Combined with the platform range, the projected baseline spans $47,400 to $79,400 per year.

That estimate is a planning scenario, not a universal invoice. Your actual exposure depends on active committers, repositories, existing controls, and whether a managed detector can run where your code runs. The important budgeting mistake is treating repository security, secret scanning, and prompt-injection containment as interchangeable line items.

What should a team implement first?

Start with the smallest reversible control that breaks the attack chain. For most coding-agent deployments, that means repository-scoped credentials, read-only access by default, denied network egress, and a separate approval path for commands that change state or transmit data.

A practical sequence looks like this:

1. Inventory every file, issue, web page, and tool response the agent reads automatically.
2. Remove broad credentials and cross-repository permissions.
3. Run the agent in a sandbox with outbound access denied.
4. Add detection where your own repository corpus shows a meaningful gap.
5. Test adversarial repositories, multilingual payloads, ordinary documentation noise, and state-changing tool calls.

Detection still earns a place. It improves visibility and can block obvious attacks before expensive processing. It just shouldn’t be your only blast-radius control. Managed APIs also create their own trust boundary by sending prompt content to a third party, which can make them unsuitable for sensitive code or isolated environments.

My recommendation is straightforward: launch coding agents with repository-scoped, read-only, network-denied permissions, then add detection based on evidence from your own workload. If a managed platform can’t operate under those constraints—or your tests can’t justify its annual cost—don’t buy it by default.