Why do AI coding agents make traditional code review and change tracking harder?

AI coding agents shift much of the work into prompts, retries, and intermediate edits that never become part of the final commit. That breaks the old assumption that git history tells the full story. Teams need ways to capture the reasoning, rejected attempts, and context behind changes so reviewers can assess process quality, not just the resulting diff.

Why This Matters for Security Teams

AI coding agents change the evidence trail that reviewers normally rely on. Instead of a developer making each change directly, the agent may draft code, discard alternatives, call tools, and iterate across several hidden steps before a commit is created. That means traditional review methods, which focus on the final diff, can miss unsafe assumptions, insecure prompt instructions, or a bad path that was later overwritten. Guidance from the NIST AI Risk Management Framework is relevant here because it treats AI systems as lifecycle-managed risks, not just outputs to be accepted at face value.

The practical impact is that change approval starts to depend on provenance, not only code quality. Security teams need to know what the agent was asked to do, which files it touched, which tools it used, and whether the final patch reflects a safe sequence of decisions. This is especially important where AI-generated changes affect authentication, secrets handling, IAM policy, or infrastructure-as-code, because a small error can create durable exposure. The review burden also shifts from syntax checking to behavioural scrutiny, which many teams are not yet instrumented to do. In practice, many security teams encounter these failures only after an unsafe agent-driven change has already reached production, rather than through intentional review design.

How It Works in Practice

Traditional code review assumes a stable relationship between intent, implementation, and commit history. AI coding agents break that assumption by inserting an intermediate execution layer. A single task may involve prompt chaining, repository reads, tool calls, test retries, patch rewrites, and automatic commits. Some of those steps are invisible unless the environment is designed to retain them. That is why the review target becomes broader than the diff: teams need traceability for prompts, model outputs, tool actions, and human approvals. The OWASP Top 10 for Agentic Applications 2026 is useful here because it frames agent risks such as excessive agency, prompt injection, and unsafe tool use.

Operationally, strong change tracking usually includes:

• Logging the original task prompt and any follow-up instructions.
• Recording tool calls, file access, and external data retrieved by the agent.
• Capturing rejected drafts and retries, not just the final commit.
• Requiring human approval for high-impact changes, especially in security-sensitive paths.
• Preserving links between issue tickets, prompts, commits, and test results.

This matters because reviewers need to understand whether the agent arrived at the result through a safe route or merely happened to land on a safe-looking patch. For threat modelling, the CSA MAESTRO agentic AI threat modeling framework and the MITRE ATLAS adversarial AI threat matrix help teams think about manipulation of the agent itself, including prompt injection, data poisoning, and tool abuse. These controls tend to break down when the agent has broad write access to repositories and can modify its own instructions or bypass review gates through automated retries because the provenance chain becomes fragmented.

Common Variations and Edge Cases

Tighter agent oversight often increases delivery overhead, requiring organisations to balance developer speed against auditability. There is no universal standard for how much of an agent’s inner process must be retained, but current guidance suggests that higher-risk changes deserve deeper traceability than routine formatting updates. The right threshold usually depends on blast radius, not on whether the code was human-written or machine-assisted.

Some environments create harder edge cases than others. In ephemeral development sandboxes, teams may accept lighter logging because the output is not production-bound. In regulated or safety-sensitive systems, that is rarely sufficient, especially when agents can touch secrets, IAM policies, or deployment manifests. Another complication is that many agent workflows are multi-step and non-deterministic, so two identical prompts can produce different code paths. That makes reproducibility and explainability part of the review problem, not just a model governance concern. The NIST AI Risk Management Framework and the Anthropic report on AI-orchestrated cyber espionage both reinforce the need to treat agent behaviour as a managed risk surface, not a convenience feature.

For identity-sensitive engineering, the intersection with NHI is becoming more important. AI agents increasingly act as non-human actors with tool access, so their permissions, approvals, and audit trails should be governed with the same seriousness as privileged automation. That does not mean every agent needs full PAM treatment, but it does mean their standing access, escalation path, and review evidence should be explicit and reviewable.

Related resources from NHI Mgmt Group

• Why do autonomous AI agents make oversight harder than traditional automation?
• Why do AI copilots and agents make PII governance harder than traditional DLP does?
• Why do AI agents and automated attackers make traditional detection harder?
• Why do AI agents make observability and incident response harder than traditional applications?