PIP-016
Code and comment injection
Instructions placed in source files or comments influence AI coding assistants reading the repository.
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
Architectural
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 cost
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
Architectural
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-08-03.