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

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.

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 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.

This divide reflects an honest design boundary, since these 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 destinations are handled. Each of these, reviewed alone, passes static checks cleanly because the code is syntactically safe and matches no known vulnerability signature.

Only the combined history reveals a path toward unauthorized data movement, and that combined history is exactly what most review systems never assemble. Reviewers look at one PR. CI evaluates one change.

Branch protection rules make merge decisions independently, PR by PR. None of this requires anything resembling a sophisticated attacker; it just requires a workflow that never asks what a given account, agent, or contributor has been building over time.

The security question becomes longitudinal, and almost nothing in a standard pipeline is built to hold that longer view.

How this risk shows up in real engineering workflows

A security lead at a software company needed every pull request to satisfy OWASP Top 10, CWE Top 25, and threat modeling checks because of a customer security mandate, so the team built an internal LLM-based PR security analysis tool and wired it into CI/CD:

• Every pull request had to satisfy OWASP Top 10, CWE Top 25, and threat modeling checks.
• The tool was wired into CI/CD.
• Medium-or-higher findings required either a fix or an explicit acknowledgement before merge.

This is a serious, well-built system, and it worked exactly as designed. It expanded coverage well beyond what standard static rules catch, and because it was enforced in CI rather than left advisory, findings actually blocked merges rather than sitting in a dashboard nobody read.

The system analyzes each pull request at review time. Whether similar reasoning can be extended across sequences of pull requests remains a separate challenge. This matters because it shows the limitation is not sophistication.

Even organizations with custom-built, enforced, LLM-assisted review can see every individual PR clearly and still miss the pattern that only appears across several of them.

Why compliance-driven teams should care now

For engineering leaders in fintech and healthtech who own quality and security without a dedicated security function, the stakes here are less about whether a scanner catches a known bug and more about whether the organization can demonstrate consistent governance over AI-generated change.

Evidence has to exist at the level of individual merge decisions, which means compliance and security need to be governed at the point of change, not as a quarterly review exercise layered on top of it.

What an intent-aware code governance model needs

Building toward intent-aware governance means adding a few specific capabilities without replacing what already works. Prompt-to-output alignment is the most tractable piece: a system that can judge whether generated code reasonably implements a stated request gives reviewers a fast signal at the point of merge.

Actor and agent attribution matters just as much, since governance depends on knowing whether a change came from a human, an AI assistant, an automation account, or some mixed workflow between them — a gap GitHub has begun addressing by using the Copilot identity to co-commit AI-generated pull requests.

Longitudinal context is the harder addition, requiring a review system to reason over prior PRs, related files, and repeated behavior by the same actor rather than evaluating each merge in isolation.

Findings need to map to actual merge decisions, required acknowledgements, or remediation workflows, and the evidence behind those decisions needs to be repeatable rather than a one-off LLM opinion that shifts from run to run without explanation.

None of this replaces SAST or SCA. It adds governance around a dimension of risk those tools were never built to see.

Where current tooling fits (and where the frontier is)

Static analysis, dependency scanning, secrets detection, and LLM-assisted PR review remain genuinely useful, and none of that changes. The frontier is combining them with governance that understands intent and history together.

• Layer one: Prompt-to-output alignment. This is becoming tractable now: emerging systems can reasonably evaluate whether a piece of generated code matches the request that produced it. Verity works at this layer, helping teams evaluate whether a pull request reflects the intent behind the request rather than only checking the code artifact on its own.
• Layer two: Cross-PR intent evaluation. Judging whether an intent is harmful across many pull requests and multiple actors remains the harder problem at scale, requiring history, policy context, and behavioral interpretation that most tooling does not yet do well.

Cross-PR malicious intent detection is an emerging direction the industry is actively building toward, not a solved capability, and any team evaluating tools here should treat claims of full longitudinal detection with appropriate skepticism.

How engineering leaders should start addressing the challenges

Closing this gap starts with a few concrete moves rather than a wholesale platform overhaul:

• Map where AI-generated code actually enters your workflow, including IDE assistants, coding agents, automation accounts, and human-edited AI output, so you know where attribution needs to exist.

• Make high-risk checks enforced rather than advisory in CI, particularly where customer commitments or regulated data are involved, since an advisory finding that nobody has to act on is not governance.

• Preserve enough metadata in your development trail to know who or what produced a given change, and give extra scrutiny to pull requests touching logging, data export, background jobs, or authentication flows, since these components often warrant additional scrutiny during security review.

• Keep the conversation about vulnerable code separate from the conversation about harmful objectives, because conflating the two makes both harder to act on.

• Finally, capture findings, acknowledgements, and overrides as part of the normal merge process rather than as a separate audit exercise, so the evidence exists when you need it.

AI-generated code needs governance that can evaluate the artifact in front of it, the instruction that produced it, and the pattern that only becomes visible across many changes over time. Building toward all three is what separates teams that can answer hard questions about their codebase from those that can only answer easy ones.