For AI-authored code, keep the same change management evidence you keep for human code: a linked ticket, a reviewed pull request, passing checks, an approver who is not the author, and a deployment record. Add two items: a label showing an agent was involved and the log of what it did.
The core idea
Change management asks a simple question: can you show that each production change was authorized, reviewed, tested, and traceable? An agent does not change that question. It changes where the risk of a gap sits. Agents can produce large diffs quickly, which tempts teams to skip steps, and they can act under a shared credential, which blurs who did what.
Evidence checklist
| Evidence | Why an auditor wants it | Agent specific note |
|---|---|---|
| Ticket or request linked to the change | Authorization | Include the task given to the agent |
| Pull request with author and reviewer | Review | Author is the human who launched the agent |
| Approval from someone other than the author | Separation of duties | An AI review is not an approval |
| Status checks and their results | Testing and control operation | Include dependency and policy checks |
| Deployment record tied to the commit | Traceability | Same as any change |
| Agent label and session reference | Provenance | New, but cheap to add |
| Action log for the session | Investigation | Mask sensitive values |
Make evidence automatic
Manual screenshots do not scale. Prefer evidence that the system produces by itself:
- Require a ticket reference in the pull request template.
- Protect main branches so merges need a human approval and passing checks.
- Apply a label automatically when a pull request comes from an agent identity.
- Export check results and approvals on a schedule to a place auditors can read.
- Keep agent logs in a store the agent cannot edit.
If you want to cut the effort further, our post on AI coding assistants and SOC 2 dependency changes looks at the dependency side.
Common gaps
- Shared agent credential. If three agents use one token, you cannot attribute actions. Give each agent its own identity.
- Self-approval. The launcher approves the pull request their own agent opened. Block it with branch protection.
- Weakened tests. Agents sometimes make a build pass by editing tests. Reviewers should look for it.
- Direct pushes. A token that can push to a protected branch bypasses the whole process.
- Missing logs. The session is gone, and you cannot answer how a change happened.
Wording for your own documentation
Describe the practice in plain terms: "Changes produced with AI assistance follow the same review, testing, and approval steps as other changes. The human who launched the assistant is the author of record." Only write that sentence once it is true and you can show examples.
A note on claims
Evidence supports a statement about how you operate. It does not turn that statement into a certification, and no document here should be read as one. If an audit is in progress, say it is in progress, and let the auditor's report speak when it exists.
Sample before you trust
Pull ten recent agent pull requests and check each against the table. If more than one fails an item, fix the process before the audit asks.
Safeguard can help at the dependency and pipeline end of this: SBOM and dependency scanning, reachability analysis, policies and gates on pull requests, and agent identity. You can try a free scan at gold.safeguard.sh/scan.
A worked example: sampling ten pull requests
A team preparing for an audit pulls ten recent pull requests where an agent was involved and checks the evidence table.
| Check | Pass | Fail | Cause of failures |
|---|---|---|---|
| Linked ticket | 8 | 2 | Template not required |
| Separate approver | 9 | 1 | Author approved own change |
| Required checks passed | 10 | 0 | None |
| Agent label present | 6 | 4 | Label added by hand |
| Session log retrievable | 7 | 3 | Logs rotated early |
The fixes follow directly. Make the ticket field required in the template. Block self approval with branch protection. Apply the label automatically from the agent's identity. Extend log retention to cover the audit period. After fixes, sample another ten a month later to confirm.
The numbers matter less than the habit. A sample shows where the process leaks, and a re-sample shows whether the fix held.
Separation of duties in practice
Separation of duties means the person who writes a change is not the only person who approves it. With agents, there are two risks. The launcher may approve their own agent's work, and the agent may hold rights that bypass review. Both are solved by server side rules.
| Rule | Where enforced |
|---|---|
| Approval from someone other than the author | Branch protection |
| Agent cannot merge to protected branches | Agent identity permissions |
| Pipeline files need owner review | Code owners |
| Deploys need a ticket reference | Pipeline gate |
Keeping evidence tidy
- Store exports in a folder per quarter with a short index.
- Name files by what they show, not by when they were made.
- Keep a short description of how each export is produced, so a new team member can repeat it.
- Note any period when a control was not working and what you did about it. Auditors respect honest gaps with remediation more than suspiciously perfect records.
Talking to an auditor
Explain the process in your own words, then show examples. Say what is true. If an audit or attestation is underway, say it is underway, and never describe it as complete before the independent report exists. If you are unsure whether a statement is accurate, check with your compliance lead before sending.
Small team version
If you have no dedicated compliance staff, begin with three things: required reviews with a separate approver, required checks, and an automatic agent label. Those three settings produce most of the evidence on their own. Add log retention and the ticket requirement next.
Keep the loop going
Review the sample quarterly, update the table when your tools change, and add any new agent type to the inventory. Evidence that is produced as a by product of normal work is the kind that stays accurate.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and notice how one piece of evidence maps to several controls.
Quick check
Do we need to disclose AI use to auditors?
Be ready to describe it accurately if asked, and make sure your documented process covers it. Ask your auditor what they expect.
Is an automated review enough as the approval?
No. Keep a human approval from someone other than the author.
How many pull requests should we sample?
Ten is a reasonable start for a small team. Increase it when your volume or risk grows, and sample across different agents and repositories.
Sources
Last reviewed: 19 October 2026.
