Detecting Malicious Intent Across AI-Generated Pull Requests: A Governance Framework for Engineering Leaders

Home All Posts Detecting Malicious Intent Across AI-Generated Pull Requests: A Governance Framework for Engineering Leaders

Trends,

AI in Software Engineering

22/07/2026

Detecting Malicious Intent Across AI-Generated Pull Requests: A Governance Framework for Engineering Leaders

Codacy

10 mins read

In this article:

Subscribe to our blog:

No single pull request has to look malicious to create a serious security problem. One adds logging. Another introduces a background job. A third expands network access. Individually, each change is reasonable enough to pass review. Together, they assemble a capability no reviewer ever intended to approve.

This is the blind spot in AI-assisted development: code review still evaluates changes one pull request at a time, while harmful intent can emerge only across many.

TL;DR

Traditional code review is designed to evaluate individual pull requests. AI-assisted development introduces a new governance hurdle: harmful intent can emerge across many individually acceptable changes. Static analysis, LLM-assisted review, and human reviewers remain essential, but engineering leaders should begin thinking beyond single-PR validation toward governance that combines intent, attribution, and longitudinal context.

Why AI-generated code changes the code review threat model

When a human writes malicious code, it is a rare and detectable failure. When an agent generates code, the author is no longer necessarily a trusted person acting transparently in front of a reviewer.

The most consequential shift here is upstream: a compromised agent, indirect prompt injection, or memory poisoning — risks covered by the OWASP Top 10 for Agentic Applications.

In many development workflows, reviewers primarily see the resulting code change rather than the full prompt chain, retrieved context, or reasoning that produced it. Which means the moment where intent gets set is invisible to the review surface entirely.

Add to that the sheer volume AI assistants produce (51% of professional developers use them daily) and you get less human attention paid to understanding the broader arc of any single contributor's or agent's behavior over time.

None of this is a failure of engineers or their existing tools. It is a governance problem created by a development model that generates code faster than any team can build context around it.

What traditional code review can and cannot see

Static analysis, dependency scanning, secrets detection, and human review still matter and still catch actual risk. The limitation shows up when each of these systems evaluates a change mainly as an isolated artifact.

A SAST scanner is built to recognize known weakness classes such as injection flaws or unsafe deserialization, and it does this well against a single diff. Traditional SAST tools are not designed to determine whether multiple changes collectively implement a broader objective.

Datadog's security engineering team described this directly after building an internal detection system: static tools are a critical part of the puzzle, but they mainly catch known bad patterns, and more importantly, they don't understand intent.

SAST systems were built to evaluate correctness and known risk patterns, not to reason about the goal a series of changes is working toward.

What intent means in AI-generated code governance

Intent, in this context, is the objective behind a request, prompt, agent plan, or sequence of changes, and it is a different question from whether the resulting code contains a known vulnerability. It helps to separate this into two layers:

The first layer asks whether the generated code matches the stated intent: if a developer or agent requests a specific feature, does the resulting diff represent a reasonable implementation of that request? This is an alignment question, and it is increasingly answerable by tooling that compares a task description against its output.

The second layer is harder and more consequential: is the intent itself acceptable in the first place? A system can implement a harmful request with technical precision. Code that quietly builds a stealth data path can align perfectly with what was asked while violating every security and compliance expectation the organization holds.

Layer one is about output fidelity.

Layer two is about whether the request, or the pattern emerging from many requests, should have been allowed to exist at all.

Why cross-PR intent is the harder security problem

This is where most governance models break down, because malicious intent rarely needs a single obvious pull request to succeed. It can be distributed across several ordinary-looking changes submitted over days or weeks.

One PR adds logging around a customer workflow. A later PR introduces a background job with access to those logs. A third modifies how outbound network...