Code and comment injection

How it works

Coding assistants read files, comments, configuration and documentation as context. A comment addressed to the assistant rather than to a developer becomes an instruction, and can influence generated code across the project.

Why it works

Everything in the repository is context, and a comment is indistinguishable from guidance. Dependencies, vendored code and generated files are all in reach and rarely reviewed line by line.

What it looks like

A comment or documentation block phrased as direction to an automated tool, typically in a file unlikely to receive close human review.

Described rather than reproduced. This library publishes mechanisms, not payloads: recognising a class of attack and choosing a control does not require a working copy of it.

Defences

• Review generated code, not the prompt

  ArchitecturalWorks on: treat what it produces as untrusted

  The output is the artefact that ships. Code review is the control that already exists for this class of problem, and it works here provided reviewers are actually reading the diff.

• Constrain assistant context to reviewed sources

  Raises costWorks on: control sources, integrations and assumptions

  Limit what an assistant is permitted to read, particularly across dependency trees and vendored code that no one on the team has read.

• Keep secrets and deploy rights away from the assistant

  ArchitecturalWorks on: limit what it can do

  An assistant that can commit, publish or deploy converts a comment into an action. Separate authorship from release.

Framework mapping

• LLM01:2025 · OWASP LLM Top 10
• AML.T0051.001 · MITRE ATLAS

Mappings are asserted only where the identifier is known correct, and omitted where uncertain. Last reviewed 2026-10-08.

Others in indirect injection

• PIP-005Indirect injection through a retrieved document
• PIP-006Indirect injection through web content
• PIP-019Instruction addressed to an automated analyser
• PIP-020Summary and priority manipulation