Source Code Prompt Injection

What Is Source Code Prompt Injection?

Source code prompt injection is indirect prompt injection through repository material that a coding assistant or agent reads, searches, indexes, summarizes or places in model context. The influencing language may occur in a comment, docstring, README, configuration file, test fixture, example, generated file, issue or pull-request description, or an explicitly supported repository instruction file.

The primitive is semantic influence, not executable code. A contributor-controlled text span can change a model's interpretation, plan or proposed patch even when every file parses correctly and no malicious program runs. Security impact requires more: reachable data or capabilities and an absent, overbroad or failed application control.

Scope and Related Attack Classes

A compromised repository, dependency or package description can deliver content into scope, but that compromise is not itself prompt injection. This article begins where repository or task material becomes model-visible and can influence the coding workflow.

The Repository and Coding-Agent Pipeline

Products assemble this path differently. Some inspect only open files, some search a local checkout, some query a remote index, and some combine repository files with issue or pull-request context. Trusted processors can faithfully transport untrusted text; their operational trust does not elevate the authority of their output.

Repository Content Surfaces

Source Text Is Data by Default

Code, comments, documentation, test data and configuration are evidence about the repository. Their authorship, location, successful compilation, signature or inclusion in an internal repository does not make their natural-language statements authoritative instructions for an AI system.

User task text is also input rather than application authority. The application defines the permitted objective and capability envelope; deterministic controls decide which resources and effects are allowed. Neither the user's wording nor repository text can expand that envelope.

Designated Repository Instructions as a Separate Authority Class

Some products intentionally support repository instruction mechanisms. For GitHub Copilot, GitHub documents .github/copilot-instructions.md, path-specific .github/instructions/**/*.instructions.md files and agent instruction files such as AGENTS.md. Support, combination and precedence vary by Copilot feature and surface. Such files can carry higher workflow instruction authority only where that concrete product surface recognizes them.

That authority is bounded. It never outranks system or application policy and never grants authorization for data access or side effects. Provenance, path, applicable scope, product-specific precedence and write permissions form a separate security boundary. Support and combination rules vary by product and surface, so they must be tested rather than generalized.

Branch, Ref, Commit and Worktree State

A repository name alone does not identify the material an agent saw. Branches, tags and pull-request refs can resolve to different commits; a local worktree can contain staged, unstaged or untracked changes; submodules can point elsewhere. An assessment must record the resolved commit and working state before reasoning about provenance.

Untrusted fork or pull-request content should not silently inherit the integrity or provenance status of an approved or pinned base state. Ordinary source remains data on either side. Where designated instruction files are supported, systems should explicitly define whether effective instructions come from the approved or pinned base state, the proposed change or both, and expose that choice to policy and review.

Search, Indexing and Context Selection

Coding systems often select context through filename search, symbol graphs, lexical or semantic indexes, open-editor state and model-directed follow-up searches. Relevance determines reachability, not trust. A result may be highly relevant and still be contributor-controlled task data.

Selection can be iterative: an included span can influence which symbol, file or directory the model asks to inspect next. Defenders should record every query and result set, constrain traversable scopes, and preserve the authority label of each returned span. For protected repositories or paths, indexing and retrieval should enforce the initiating principal's applicable access or a narrower delegated scope.

What Actually Becomes Model-Visible

Provenance and Derived Repository Artifacts

Each model-visible span should retain repository identity, owner, branch or ref, resolved commit SHA, file path, blob or content hash, line or span identity, retrieval query, index generation and worktree status where available. Issue, pull-request and task context need their own author, event and permission provenance.

Summaries, symbol indexes, embeddings, caches and memory are derived artifacts. They should carry lineage to their source spans and access labels. Removing or correcting a repository file does not automatically remove old index generations, summaries or memory; response requires explicit invalidation and verified rebuild while preserving evidence.

Attacker Prerequisites and Reachability

A realistic assessment begins by identifying content the tester is authorized to control: a fixture on a test branch, a synthetic fork, a test issue, or a dependency fixture in an isolated project. The content must then become reachable under a plausible task, branch, file-selection and indexing configuration.

Write access alone is insufficient. The relevant ref must be checked out or indexed, the file type must be eligible, the span must survive selection and truncation, and the resulting context must influence a model operation. A security effect additionally requires a reachable capability and a failed deterministic control.

Offensive Perspective on Repository Ingestion

Authorized Red Teams should map controllable content to realistic entry points and measure each barrier independently. Useful questions concern which identity can modify which surface, which ref the system resolves, how retrieval selects spans, whether authority labels survive assembly, and what capability exists after influence.

The objective is not to optimize wording. It is to discover unsafe composition: untrusted repository material reaching an instruction-sensitive model, an influenced proposal reaching excessive tools or data, and application policy failing to contain it. This article therefore omits reusable prompts, malicious code, concealment, persistence techniques and exploitation sequences.

Source Code Prompt Injection Success Chain

The chain branches after influence. A read-only assistant may only produce an answer or proposal. Another system may separately offer scoped file writes, shell or package tools, network calls, commits, pushes, pull requests, CI triggers or merge operations. None of these capabilities is universal, and each is a separate gate.

Model influence is not security impact. End-to-end impact requires one complete capability branch, a missing or failed policy decision, and an actual security-relevant effect. Reports should state the deepest observed gate rather than imply later effects.

Competing Constraints for an Attacker

Offensive Review Questions

Worked Scenario: Bounded Validation Update

The test uses synthetic data, bounded permissions and reversible effects. Influence is recorded as a model-level finding; the denied capability path demonstrates containment.

Capabilities, Effects and Authorization Boundaries

Approval should bind to the exact immutable diff, ref, action and destination. Re-evaluate authorization if any parameter or repository state changes. Repository instructions and model output remain proposals to this control plane, never authorization inputs.

Detection and Telemetry

Useful signals include plan drift, source-authority mismatch, unexpected refs or untracked files, a widened diff, new path or destination requests, and mismatch between approved and executed actions. Telemetry should establish sequence without claiming it proves internal model causality.

Prevention and Secure Architecture

1. 01
   Classify authority

   Treat source text as data and supported repository instructions as a distinct, bounded class below application policy.

2. 02
   Protect instruction sources

   Restrict and review who can modify designated instruction files; expose their scope and effective precedence.

3. 03
   Preserve span provenance

   Carry repository, ref, commit, path, blob hash, line range, query and index version into context and logs.

4. 04
   Resolve intended base state

   Pin or verify branch and ref where required, and isolate fork, PR and local worktree content without treating repository integrity as instruction authority.

5. 05
   Minimize context

   Retrieve only task-relevant files and spans under the initiating identity's permissions.

6. 06
   Isolate execution

   Use an isolated workspace or container without ambient secrets or sensitive local files.

7. 07
   Authorize deterministically

   Enforce file, path, tool, shell, package and network rules outside the model, including egress allowlists.

8. 08
   Stage higher-impact changes

   Require proposal and review before mutation, and separate write, commit, push, PR and merge rights.

9. 09
   Bind approvals

   Approve the exact diff, ref, action and destination; re-evaluate when repository state changes.

10. 10
    Validate downstream

    Use branch protection, code review, CI and security scans as additional validation, not prompt-injection prevention.

The Defense Hub places these controls in the broader architecture for provenance, least privilege, information flow, action control and recovery.

Controlled Security Testing

Use synthetic repositories, identities, secrets and destinations; isolate execution; cap permissions; and make every effect reversible. Vary content class, ref, worktree state, retrieval method, instruction-file support and capability set. Record a denominator for each metric.

Do not combine the metrics. High influence with zero policy bypass is materially different from low reachability with untested authorization.

Incident Response

Common Misconceptions

Standards and Research Context

OWASP LLM01:2026 classifies indirect injection through external sources. NIST defines indirect prompt injection as prompt injection executed through resource control, while resource control separately describes attacker control of external resources consumed at inference time. These define mechanism, not downstream impact.

Microsoft treats prompts, documents, retrieved chunks, tool results and memory writes as untrusted and recommends provenance, permission-aware indexing and validation at each read and write. GitHub documents concrete custom-instruction mechanisms and mitigations for its own Copilot surfaces. Those product behaviours are examples, not universal permissions or precedence rules.

Greshake et al. reports the practical viability of indirect prompt injection against real-world LLM-integrated systems, including code-completion engines. The paper supports the threat model; this page does not reproduce attack strings or procedures.

Frequently Asked Questions