Automatic loading breaks the assumption that the reviewer sees the same evidence the repository contains. An attacker can hide malicious lines from diffs, security scanner output, or source files before the model sees them. The result is false confidence in a clean review and a path for compromised code to advance toward production.
Why This Matters for Security Teams
When a project-local AI filter auto-loads from the repository, the review boundary shifts from “what is committed” to “what the filter decides to show.” That creates a trust problem, not just a tooling problem. Security teams can no longer assume the reviewer, the scanner, and the model all saw the same source evidence, which is exactly how malicious edits slip past human and machine review alike. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it emphasizes governance and integrity around security operations, not just detection.
The real risk is that filtering becomes part of the attack surface. A compromised repository can shape what the model reads, suppress lines that would trigger concern, or alter surrounding context so suspicious changes look normal. NHIMG has seen adjacent patterns in the GitLocker GitHub extortion campaign, where repository trust was part of the exploitation path. In practice, many security teams encounter tampered review context only after unsafe code has already been approved, rather than through intentional review design.
How It Works in Practice
Auto-loading repository-local filters breaks review integrity because the control plane and the evidence plane become the same thing. If a filter file, prompt template, parser rule, or ignore list lives in the repo, then a contributor who can alter the repo can also alter the lens through which the AI reviews it. That is especially dangerous for code review assistants, pre-commit bots, and pipeline copilots that trust local configuration by default.
Practically, the failure mode usually looks like this:
- The repository contains a filter or policy file that is loaded automatically before analysis.
- A malicious commit modifies the filter so dangerous patterns are excluded, normalized, or rewritten.
- The AI summarizes the remaining content as safe, giving reviewers false confidence.
- Downstream scanners or human reviewers inherit the same skewed view if they rely on the AI output.
This is why current guidance suggests keeping security policy, prompt logic, and model instructions outside the project tree whenever possible. Use immutable policy sources, signed configurations, and separate trust domains for review rules. Where automation is unavoidable, compare the model’s output against raw repository evidence and maintain an auditable trail of what was loaded, from where, and under which identity. The broader issue is not just malicious prompt injection; it is repository-controlled behaviour that changes the meaning of the review itself. NHIMG’s analysis of DeepSeek breach shows how exposed data and sensitive operational material can cascade once trust boundaries collapse. These controls tend to break down in monorepos with broad write access because policy files, test fixtures, and application code are often changed together.
Common Variations and Edge Cases
Tighter review isolation often increases friction, requiring organisations to balance stronger integrity with developer speed and pipeline simplicity. The best practice is evolving, but there is no universal standard for this yet. Some teams keep local filters for convenience while pinning only high-risk rules centrally; others eliminate repository-supplied review logic entirely and treat it as untrusted input.
The edge cases matter. Generated code, vendored dependencies, and multi-package repositories can make it difficult to separate “content under review” from “instructions about review.” If the filter is needed for legitimate reasons, it should be signed, versioned, and validated outside the repository before any AI system consumes it. Teams should also assume an attacker may target the parser, not just the filter text, because malformed input can produce selective omission or misleading summaries even when the rule file itself appears harmless.
NHIMG’s reporting on the Emerald Whale breach reinforces a broader lesson: once automation inherits trust from a compromised environment, attackers can turn efficiency into concealment. That is why secure review design must separate evidence, policy, and execution authority rather than letting the repository define all three.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AGENT-03 | Repository-loaded filters can manipulate what the agent sees during review. |
| CSA MAESTRO | A3 | Covers trust boundaries for agentic workflows and tool-mediated decisions. |
| NIST AI RMF | AI RMF applies to integrity, transparency, and governance of model-assisted reviews. |
Keep agent instructions and review policy outside repo-controlled content and verify raw evidence separately.
