What breaks when AI code review tools are allowed to analyse untrusted pull requests?

The review workflow itself becomes an attack surface. Prompt injection in comments, documentation, or code can steer the model, expose secrets, or trigger unsafe actions if the tool has privileged access. Teams should treat untrusted pull requests as hostile inputs and require manual approval before automated security scanning runs.

Why This Matters for Security Teams

Allowing AI code review tools to inspect untrusted pull requests turns routine review into a hostile interaction. The model is not just reading code, it is interpreting attacker-controlled text that can include prompt injection in comments, documentation, tests, and even dependency metadata. If the tool can reach secrets, issue comments, or call internal services, the blast radius quickly expands from bad suggestions to active compromise. Current guidance from NIST Cybersecurity Framework 2.0 still applies, but it needs to be applied to the review pipeline itself, not only the repository.

NHI Management Group research on The State of Secrets in AppSec shows how fragile code-security operations become when secret handling and developer workflows are inconsistent. The key issue is that AI tools do not understand trust boundaries the way humans do, so a malicious PR can influence the tool’s next action if controls are loose. In practice, many security teams encounter unsafe automation only after a reviewer bot has already exposed context or triggered an unintended action, rather than through intentional design.

How It Works in Practice

The failure mode is usually not the model “hacking itself.” It is the surrounding workflow granting the model too much authority over untrusted content. A pull request can contain adversarial instructions that look like ordinary code review artifacts, and the agent may obey them if the prompt, retrieval layer, or tool chain is not isolated. That is why the safest pattern is to treat every external contribution as hostile input until manual triage has occurred.

Practical controls are straightforward, but they must be layered:

• Run initial triage without access to production secrets, write permissions, or internal issue trackers.
• Separate the analysis model from the actioning system so the tool can suggest, but not merge, comment, or deploy.
• Strip or redact secrets before any LLM sees repository content, including logs and diffs.
• Use allowlisted tools and read-only identities for automated review paths.
• Require manual approval before a higher-privilege scan, retrieval, or remediation step runs.

This aligns with the broader logic of DeepSeek breach lessons: once sensitive context is exposed to an environment that ingests untrusted data, the trust boundary has already failed. The same pattern applies to agentic review systems. If the tool can fetch secrets, open tickets, or execute repository actions, a prompt injection payload may steer it into privilege abuse or data exfiltration. These controls tend to break down when the review bot is embedded directly into a CI pipeline that also holds long-lived credentials, because the tool can chain read access, retrieval, and write actions in one pass.

Common Variations and Edge Cases

Tighter review controls often increase developer friction, requiring organisations to balance faster automated feedback against stronger containment. That tradeoff becomes more visible in large monorepos, fork-based contribution models, and repositories that mix public and private components. Best practice is evolving, but there is no universal standard for whether an AI reviewer may inspect untrusted code locally, in a sandbox, or only after human pre-clearance.

Edge cases matter. A tool that only summarizes diffs may seem harmless, yet it can still leak snippets of secrets, infer internal architecture, or preserve malicious instructions in downstream tickets. Conversely, a fully isolated scanner may miss context if it cannot access dependency history or build metadata. Current guidance suggests separating “analysis” from “authority”: the model can observe untrusted PRs, but it should not receive standing privilege, durable credentials, or direct access to high-impact systems. That distinction is especially important where security teams rely on AI to classify findings, because the model may reproduce attacker intent as if it were operational guidance.

For teams formalising this workflow, NHI Management Group recommends treating AI review services as non-human identities with tightly scoped runtime access, not as trusted members of the engineering team. The practical question is not whether the model can read code, but whether it can be influenced into doing something the submitter should never be able to request.

Related resources from NHI Mgmt Group

• What breaks when AI agents can call tools after reading untrusted content?
• What breaks when GitHub Actions workflows run untrusted pull requests with write access?
• What breaks when AI skills are judged only by static code review?
• What breaks when hidden prompt injection is allowed in AI code assistants?