Why do AI coding agents increase software risk if organisations keep the same review process they used for human developers?

Why This Matters for Security Teams

AI coding agents change the risk profile because they compress work that used to be spread across many small human decisions into a few large, fast execution bursts. A review process built for human pacing often checks syntax, style, and isolated diffs, but misses intent, hidden dependencies, and cross-file effects. That gap matters because agent-generated code can introduce insecure defaults, privilege overreach, weak secret handling, and logic that looks acceptable in isolation while breaking system-level assumptions. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point to governance, traceability, and validation as control priorities, not just code quality.

The practical issue is that traditional review assumes the reviewer can reconstruct developer reasoning from a small diff and a ticket. With coding agents, the relevant context often lives in prompts, tool calls, retrieved documents, and generated changes across multiple repositories. If that provenance is not retained, reviewers are forced to guess whether a change reflects sound engineering judgment or an unvetted model output. In practice, many security teams encounter this only after a release has already normalised insecure patterns across several services, rather than through intentional design review.

How It Works in Practice

AI coding agents create risk when they are allowed to operate with broad tool access and then enter a human review pipeline that was never designed to inspect autonomous work products. A reviewer may see a plausible pull request, but not the prompt that shaped it, the retrieved snippets that influenced it, or the fallback path the agent used when it failed mid-task. That means the organisation is reviewing the artifact, not the decision process. The result is weaker accountability and poorer defect detection.

Practically, security teams should treat agent-generated code as a higher-risk change class until controls prove otherwise. The relevant checks are less about finding every bug manually and more about constraining what the agent can do, what evidence must be captured, and when a human must intervene. Useful control points include:

• Require prompt, tool, and repository provenance so reviewers can reconstruct why code was produced.
• Limit agent permissions to the minimum necessary repository, environment, and secret scope.
• Separate generation from merge approval, with stronger review for authentication, authorisation, cryptography, and data handling changes.
• Use automated tests, policy checks, and secret scanning as mandatory gates, not optional aids.
• Escalate changes that touch deployment, infrastructure, or privileged workflows to a deeper security review.

Where agentic systems interact with software delivery, the OWASP guidance and the MITRE ATLAS adversarial AI threat matrix are useful because they highlight prompt injection, tool misuse, and adversarial manipulation of model behaviour. That matters when the agent pulls instructions from tickets, docs, or code comments that can be tampered with. These controls tend to break down when the agent is allowed to make broad repository-wide edits in monorepos because reviewers cannot reliably assess downstream impact from local diffs alone.

Common Variations and Edge Cases

Tighter controls often increase delivery overhead, requiring organisations to balance release speed against the risk of opaque machine-generated change. That tradeoff is real, and best practice is evolving rather than settled. There is no universal standard for exactly how much autonomy a coding agent should have before a second reviewer or approval gate is mandatory.

Edge cases matter. In small, low-risk utility repositories, a lighter review model may be acceptable if the agent’s permissions are tightly scoped and the blast radius is low. In regulated environments, production infrastructure, or code that handles credentials, customer data, or access control, the acceptable threshold is much lower. The CSA MAESTRO agentic AI threat modeling framework is useful here because it pushes teams to map agent capabilities, trust boundaries, and failure modes before deployment. The key question is not whether an agent can write code, but whether the organisation can still explain, test, and approve the resulting change with enough confidence.

In practice, the review process should become stricter as autonomy rises. If the agent can create code, open pull requests, modify tests, and suggest deployment changes, then the review model needs stronger provenance, stricter policy enforcement, and a lower tolerance for unexplained complexity. Without that shift, teams end up approving output they can no longer fully attribute or validate.

Related resources from NHI Mgmt Group

• Why do AI coding agents increase code security risk if they are not verified?
• Why do AI coding agents create security risk even when they use the same model?
• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents increase non-human identity risk?