When an engineer prompts an agent to write a change and then approves the pull request, your change record shows two people and your process had one.
That matters because separation of duties is part of what auditors test in IT general controls. A change management control that does not operate as designed can become an audit finding, and for systems that support financial reporting, control deficiencies can be judged significant or, at worst, a material weakness, depending on their severity. AI does not change that scale. It changes whether the deficiency shows up in the evidence you hand over. Here it does not: the pull request has an author and an approver, the ticket is linked, the tests ran.
What SOX change management controls test
For a sample of changes to in-scope systems, the test asks whether each change was authorized, tested, and approved before it reached production, and whether someone other than the person who built it made the approval. None of it names a tool. SOX does not care who or what typed the code. It cares whether the control around the change operated, so agents add no new requirement. They change whether your existing evidence still means what it says.
How an agent makes the review stop being independent
The control assumes the author shaped the change and the reviewer is a second, independent mind. With an agent, the engineer who wrote the prompt is the real author: they set the intent, read the output, asked for fixes, and decided it was done.
When a cloud agent opens the pull request under its own account, the repository sees the agent as the author. Some agent integrations now refuse to count an approval from the person who assigned the work. Where yours does not, the engineer approves work they directed, the rule against self-approval is satisfied, and the record shows an independent review that did not happen.
It also runs the other way. When an agent reviews a pull request and a person approves on the strength of the agent's summary, the approval is real on paper and thin in practice.
What auditors are likely to ask next
- Who directed this change, and who approved it? If it is the same person, the account names on the pull request do not help.
- Did any agent change reach production without a human approval? Auto-merge, agent deploy permissions, and direct pushes from automation are change paths, whether or not anyone designed them as one.
- Can you show who directed a given change? For any change the auditor picks, not only the sample. If the answer lives in one engineer's chat history with an agent, it is not evidence.
How to show SOX change control when an AI agent made the change
- Attribute every agent change to the person who directed it. The bot account is a tool, not an author.
- Require an approver other than that person. Write the separation of duties rule around the human behind the agent, not the account that opened the pull request.
- Close the paths around review. Treat auto-merge and agent deploy rights on in-scope systems as changes to the control itself, with their own approval.
- Test the population. When the evidence comes from the systems of record, there is little reason to test a sample instead of every change.
EU banks face the same question from a different direction under DORA, which also treats the coding assistant as a third-party service. See DORA and AI coding agents.
Checking every change, not a sample
Bloomfilter reads your tickets, pull requests, CI, deploys, and agent sessions and answers two of those questions across the whole population: who approved each change an agent wrote, and which agent changes reached production without a review. Your control owners see the exceptions before the auditor does. See the regulated software use case.