Auditors need to know not only what code exists, but how it was produced and whether policy checks were enforced at the point of generation. Commit logs do not show prompts, context, or tool interactions, so they cannot prove that governance worked. If the organisation cannot reconstruct the decision path, it cannot reliably defend its control environment.
Why provenance matters more than the final commit
Auditors are not just checking that code changed, they are checking whether the change was produced under controlled conditions. In AI-assisted development, the final commit is only the artefact, while prompts, context, retrieval inputs, tool calls, and policy gates are the evidence trail that shows whether the artefact was created within an approved process. Without that trail, the organisation has output but not assurance.
That distinction matters because AI can generate code through a path that is fast, distributed, and partially opaque. A commit history can show who merged what, but not whether the model was given restricted source material, whether unsafe instructions were filtered, or whether a required review gate was enforced before generation. SLSA is useful here as a provenance lens because it frames trust in how software was produced, not just whether the result exists.
For audit purposes, provenance evidence needs to answer a simple question: can the organisation reconstruct the path from instruction to output? If the answer is no, then the control environment depends on trust in people or tools rather than verifiable process. That is especially important when AI coding systems interact with external context, because the production path may include hidden dependencies that never appear in the repository.
What policy evidence proves that governance actually ran
Policy evidence is the record that the right checks happened at the right moment. For AI code generation, auditors care about whether the system enforced rules on prompt use, data exposure, tool access, approvals, and any restricted actions before code was accepted. A policy document alone is not enough; the key issue is whether the policy was executed and logged in a way that can be tested.
This is why evidence must be tied to the workflow, not just stored in a compliance folder. If the organisation says a policy blocks unsafe code generation, the auditor will want to see the execution trace, the approval state, the policy decision, and the exception handling. Agentic AI Security Policy Template is relevant because it reflects the kind of governance artefacts that need to exist before those checks can be evidenced operationally.
Policy evidence also helps separate “we intended to control this” from “the control was actually in force.” In practice, that means logs, decision records, and enforcement outputs matter more than policy prose. If a system can generate code while bypassing policy checks, the control is performative rather than defensible.
Why auditors look for reproducibility, not just assurance statements
Auditors care about reproducibility because it is the best available test of whether governance was real. If a team can recreate the decision path, the generated artefact, and the policy outcome from retained records, then the control environment is inspectable. If the path cannot be reconstructed, then the organisation cannot reliably demonstrate that generation was constrained by approved rules.
That is especially relevant for AI coding workflows where the human reviewer may only see the final diff. The reviewer can approve the code, but the auditor may still ask what influenced the model, what data was exposed, whether approved tools were used, and whether any high-risk action was blocked. AI Coding Agents Security Guide supports this issue because it covers the security realities of secrets in context, over-scoped tokens, sandboxing, and agent-authored commits.
Good audit evidence therefore connects three things: the artefact, the generation path, and the control decision. If any one of those is missing, the organisation may still have code, but it does not have a complete control story.
Risk and Threat Considerations
When AI-generated code cannot be tied back to trustworthy provenance and policy enforcement, the risk is not merely weak documentation. The organisation may be unable to prove that sensitive inputs were excluded, that unsafe tool actions were blocked, or that approved review steps happened before code reached production.
Failure mechanism: The audit trail records the output, but not the decision path, so control failures, prompt contamination, and unauthorised tool use can remain invisible until after deployment.
Impact: This can turn a governance gap into a security gap, because the organisation may not be able to defend the integrity of its SDLC, explain an incident, or demonstrate that policy enforcement was operating as designed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | AI code provenance depends on verifiable build and generation lineage. |
| Recommendation — Use SLSA to preserve provenance evidence for generated code and related artefacts. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Auditors need logged generation and policy decisions to reconstruct control operation. |
| AU-12 — Audit Record Generation | The question centers on whether evidence exists to reconstruct the decision path. | |
| CM-3 — Configuration Change Control | AI-produced code still needs controlled change approval and traceability. | |
| Recommendation — Define audit events for prompt handling, policy decisions, and approvals. Generate records that capture the generation path, policy outcome, and reviewer action. Require controlled approval for AI-assisted code changes before merge. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Policy evidence relies on logs that show enforcement and review activity. |
| Recommendation — Retain logs that show policy enforcement, exceptions, and review results. | ||
Practitioner Guidance
What to verify: Make sure your evidence set can show the generation context, the policy decision, the human approval state, and the retained artefact together. If any one of those is absent, the audit story is incomplete even if the code itself is clean.
What good looks like: An auditor should be able to trace a representative change from request to generation to approval to merge, and see where policy controls blocked, allowed, or escalated the action. The strongest evidence is reproducible and time-aligned, not just descriptive.
Common mistake: Treating commit history as if it were provenance. A commit proves that something was recorded, not that generation was governed.
Practitioner takeaway: For AI code, the control question is not “what shipped?” but “can we prove how it was allowed to exist?”
Related resources from NHI Mgmt Group
- Why do insurers care so much about control evidence instead of policy questionnaires?
- Why do AI-assisted code review tools often miss the issues engineers care about most?
- Why do auditors care about evidence after an SoD conflict is found?
- Why do auditors care so much about current compliance evidence?