How can organisations reduce risk before merging code written with AI agents?

Why This Matters for Security Teams

AI-assisted coding changes the risk profile of software delivery because the person approving a merge may not fully understand the generated logic, hidden dependencies, or security implications of the diff. That creates a gap between velocity and assurance. Guidance from the NIST AI Risk Management Framework is useful here because it frames AI use as a governance problem, not just a developer productivity issue.

The real concern is not that AI agents always write bad code. It is that they can produce plausible code quickly, while also introducing subtle regressions, insecure defaults, weak validation, or design drift that slips through routine review. Security teams also need to think about the agent itself as a high-trust software contributor with tool access, repository access, and the ability to scale mistakes across many pull requests. Current guidance suggests treating AI-generated changes as higher-risk until they have been independently verified.

In practice, many security teams encounter the consequences only after a merge has already shipped a brittle implementation, rather than through intentional review of the agent’s assumptions.

How It Works in Practice

Reducing risk before merge starts with making the pull request small enough for a human reviewer to understand, then pairing that review with objective checks. The reviewer should be able to explain what the code does, what it changes, and why the change is safe to ship. That is especially important when the code touches authentication, authorization, data handling, secrets, network calls, or infrastructure as code.

A practical workflow usually combines policy, testing, and provenance checks. The AI agent can draft code, but the merge gate should require evidence that the code behaves as intended and does not widen attack surface. The OWASP Top 10 for Agentic Applications 2026 is relevant because it highlights risks from tool misuse, excessive autonomy, and insecure agent behavior that can surface in generated changes.

• Require human sign-off on the design intent, not just the syntax.
• Run unit, integration, and performance tests before merge, with security-sensitive test cases included.
• Use static analysis, secret scanning, and dependency checks to catch issues the reviewer may miss.
• Compare the diff against architectural boundaries so the agent does not silently introduce a new trust path.
• Track which changes were generated by an AI agent so post-merge investigation is possible.

For teams working with autonomous agents, the control question is whether the organisation can explain and reproduce the change without relying on the agent’s own output. That aligns well with the threat-focused approach in the MITRE ATLAS adversarial AI threat matrix, which helps teams think about abuse paths and failure modes before code is promoted. These controls tend to break down when repositories are large, test coverage is thin, and reviewers are asked to approve changes outside their area of expertise because understanding collapses under context switching.

Common Variations and Edge Cases

Tighter merge gates often increase delivery overhead, so organisations have to balance speed against assurance. That tradeoff is usually worth it for sensitive code paths, but best practice is evolving for low-risk changes such as documentation updates or isolated refactors.

One common edge case is when an agent produces code that passes tests but still encodes the wrong business logic. In that situation, automated checks may confirm correctness against the wrong expectation. Another issue arises in highly modular systems where a small change has broad downstream effects, making a “small” diff operationally large. Organisations should also be careful with agent-generated infrastructure changes, because a secure application merge can still create exposure through IAM, network policy, or deployment configuration.

Where agentic development is mature, teams increasingly combine code review with policy enforcement, reproducibility checks, and model-output traceability. The CSA MAESTRO agentic AI threat modeling framework is helpful for mapping how autonomy, tool access, and workflow permissions interact. There is no universal standard for this yet, but the direction is clear: merge approval should verify both code quality and the agent pathway that produced it. In environments with weak testing culture, legacy monoliths, or rapidly changing product requirements, even well-designed gate controls can become ceremonial rather than preventive.

Related resources from NHI Mgmt Group

• How can organisations reduce risk from shadow AI agents already inside the enterprise?
• How can organisations reduce risk from AI agents processing hidden instructions?
• How can organisations reduce risk when AI agents use MCP servers?
• How do organisations reduce the risk of AI-generated code reaching production?