They assume comments are harmless documentation instead of machine-consumed instructions. In AI-assisted development, a comment can become an operational signal that changes code generation, so comments must be reviewed with the same discipline as code when assistants are reading them automatically.
Why This Matters for Security Teams
Malicious comments are not a novelty issue. In AI-assisted development, they become a supply-chain control problem because the assistant may read, summarise, or act on text that a human would normally ignore. That changes the threat model: comment content can steer code generation, tests, refactors, or tool calls, especially when agents ingest repo context automatically. NIST guidance on access and system integrity, including NIST SP 800-53 Rev 5 Security and Privacy Controls, is relevant here because the risk is not just incorrect code, but untrusted input influencing trusted automation.
This matters most where teams assume comments are passive documentation. They are not, once an AI assistant or coding agent is in the loop. The practical failure is letting untrusted natural language sit beside source code without the same review expectations, provenance checks, or policy enforcement applied to executable logic. NHIMG research on the DeepSeek breach shows how quickly sensitive material can be embedded and exposed at scale when development workflows are not tightly controlled.
In practice, many security teams discover comment abuse only after the assistant has already propagated the bad instruction into generated code or documentation, rather than through intentional review of comment-handling risk.
How It Works in Practice
The core mistake is treating comments as non-executable because humans read them that way. AI tools do not always. A malicious comment can be crafted to look like guidance, a TODO, a security exception, or a build instruction, while actually nudging the model toward unsafe output. This is especially dangerous when the assistant has broad repository context and can infer intent from adjacent files, issue text, or prompts.
Current guidance suggests teams should classify comments as untrusted input whenever an AI system can consume them. That means applying code-review discipline to comment changes, especially in files that influence prompts, scripts, CI/CD pipelines, infrastructure templates, or generated code. The most effective controls are procedural and technical:
- Review comment additions and edits in the same pull request workflow as code.
- Restrict assistants from using comments as authoritative instructions unless the context is trusted.
- Separate developer notes from machine-facing directives where possible.
- Scan for prompt-like language, override phrases, and hidden instructions in repository text.
- Log when assistants consume comments so reviewers can trace how outputs were influenced.
For teams building broader NHI controls, this aligns with The State of Secrets in AppSec, which highlights the real-world gap between confidence in controls and actual developer behaviour. It also fits the control logic in OWASP guidance and NIST-style integrity management, because the issue is not just content quality, but trust boundaries around machine-consumed text. These controls tend to break down when assistants are allowed to process large, heterogeneous repositories without comment provenance tracking, because malicious instructions are indistinguishable from legitimate developer notes at ingestion time.
Common Variations and Edge Cases
Tighter comment controls often increase review overhead, requiring organisations to balance developer velocity against the risk of instruction injection. That tradeoff becomes sharper in fast-moving monorepos, generated codebases, and agentic workflows where comments may be used as lightweight orchestration signals.
There is no universal standard for this yet, but best practice is evolving toward context-aware handling. A comment in a README is not the same as a comment in a prompt template, a test fixture, or a deployment script. Teams should set different trust levels based on where the assistant can read, whether the file feeds automation, and whether natural language can alter downstream behaviour. External comments pulled into code via copy-paste, issue sync, or documentation generation deserve similar scrutiny.
Two edge cases deserve special attention. First, benign-looking comments can be weaponised by telling the model to ignore policy, preserve secrets, or prioritise unsafe behaviour. Second, legitimate comments can be over-blocked if every natural-language annotation is treated as hostile. The practical answer is not to ban comments, but to label machine-facing text, constrain assistant scope, and require human review of any comment that could influence generated output. That is especially important when the repository is already a source of sensitive material, as shown by NHIMG coverage of the DeepSeek breach and broader secrets exposure patterns.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | LLM-01 | Covers prompt injection through untrusted text, including malicious comments. |
| CSA MAESTRO | AG-2 | Addresses agent input trust boundaries and unsafe instruction ingestion. |
| NIST AI RMF | Supports governance for harmful model behaviour and context misuse. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Relevant where comments influence systems using non-human identities or automation. |
| NIST CSF 2.0 | PR.DS-6 | Supports integrity checks for software and data modified by assistants. |
Treat repository comments as untrusted input and validate assistant outputs before merge.
