AI Agents
AI agents for SOX controls testing: automating evidence without automating the sign-off
The quarterly SOX grind is evidence collection, sample testing, and workpaper drafting, exactly the repetitive, rule-bound work agents are good at. A wave of 2026 startups is pointing agents at it. Here is what an agent can take over, the segregation-of-duties trap that bites first, and why the auditor still signs.
Every quarter, a controls analyst pulls the same twenty-five samples, screenshots the same approvals, and pastes them into the same workpaper. The control passed again, the way it passed last quarter. The work was not judgment. It was retrieval, formatting, and cross-referencing, and a machine is better at all three.
SOX compliance is a workflow agents should be good at. The work is high-volume, rule-bound, repetitive, and spread across systems that do not talk to each other. A 2026 wave of startups has noticed, and evidence collection, sample testing, and workpaper drafting are being handed to agents.
What an agent should not touch is the auditor’s judgment, the sign-off, and the one piece of structure that breaks first: a control cannot test itself. Get the boundary right and the quarterly grind shrinks. Get it wrong and you have automated your way to an audit finding.
What SOX asks for
Start with the obligation, because the automation only makes sense against it. The Sarbanes-Oxley Act of 2002, Section 404, requires management to assess internal control over financial reporting (ICFR) and the external auditor to attest to it. The auditor’s side runs under PCAOB Auditing Standard 2201, the integrated audit of ICFR.
Testing a control means two separate questions. Design effectiveness asks whether the control, as built, could prevent or detect the error it targets. Operating effectiveness asks whether it did, consistently, across the period. The order is not negotiable: a control that is badly designed fails the first test, and sampling a broken design proves nothing.
Operating-effectiveness testing is where the hours go. You pull a sample from the full population of times the control ran, then inspect or re-perform each one. Inquiry alone, asking someone whether they did it, is never sufficient evidence.
The workpaper has to show the population, how the sample was selected, the result of each item, and a reviewer’s sign-off. Sample sizes are not fixed by rule; they scale with how often the control runs.
One more piece decides how much an agent can help. Controls that lean on a system, an automated approval, a report-driven reconciliation, are only as trustworthy as the IT general controls (ITGCs) underneath them. PCAOB inspections keep finding the same gap: insufficient ITGC testing is one of the most common ICFR deficiencies. That matters here, because an agent that collects and tests evidence becomes part of that IT layer.
What an agent takes over
Three parts of the quarterly cycle are retrieval and formatting, and those are the ones to automate first.
Evidence collection. The slowest manual step is logging into six systems to gather proof a control ran. An agent with read access can pull approvals, logs, reconciliations, and tickets from the source systems directly.
The reported 2026 entrants lean on this. Midship, which raised $4.15M in January 2026, describes agents that follow an audit plan and assemble audit-ready workpapers, and the Y Combinator startup Arden describes pulling evidence from more than twenty systems including Workday, Okta, and NetSuite. Treat the metrics as vendor claims until your own run proves them.
Testing the whole population, not a sample. Sampling exists because humans cannot inspect ten thousand control executions by hand. An agent can. For automated and report-based controls, testing the full population instead of twenty-five items raises the quality of the assurance and not merely its speed, because an exception a sample of twenty-five would have missed is now caught. Full-population testing is the part of this worth building toward.
Workpaper drafting and exception triage. Once the evidence is gathered and tested, drafting the workpaper and flagging the items that do not match is pattern work. The agent assembles the paper, marks the exceptions, and routes them. A human still decides what each exception means.
The common design across the serious products is the one to copy: the agent clears the routine population and escalates the exceptions to a person. That shape is not a limitation waiting to be engineered away; it mirrors the one we described for an agent that assembles while a human accepts in third-party risk.
The trap that bites first: a control cannot test itself
Here is the mistake that turns an automation win into a finding. SOX depends on segregation of duties. The person who operates a control cannot be the person who tests it, because that destroys the independence the whole framework rests on. The same rule applies to an agent, and it is easy to violate without noticing.
If one agent books the journal entry and the same agent tests the journal-entry control, you have built a reviewer that grades its own homework. Worse, because the logic is shared, a flaw in the booking is invisible to the testing: both inherit the same blind spot.
The segregation that is obvious with two human teams has to be deliberately rebuilt when the work moves to agents, with separate agents, separate access, and separate owners for operating a control and for testing it.
The agent also stops being only a tool here and becomes a control itself. An agent that collects and evaluates audit evidence sits inside the ICFR reporting chain, so it is subject to the same scrutiny as any automated control: its access, its logic, and its outputs have to be tested, and its ITGCs have to hold.
You are not simply deploying an agent. You are adding a control that your next audit will examine, so it needs an owner, a change log, and version history from day one. Governing that fleet of agents as controls is the same discipline as governing any agent fleet, with a regulator reading the result.
Why the auditor still signs
The regulation has not moved to meet the tooling. SOX was written in 2002, and Section 404 has never been amended for AI or automated controls. An external auditor’s opinion rests on professional judgment and independence that a probabilistic system cannot hold, and AS 2201 still wants a reviewer’s sign-off on the evidence. A model that is fast, capable, and occasionally confidently wrong does not get to form the opinion.
So the division of labor is clear. The agent gathers the evidence, tests the population, and drafts the paper. The human reviews the exceptions, exercises the judgment, and signs. Delegating the retrieval is a real gain. Delegating the conclusion is how you end up explaining to a regulator why a hallucination is in your 10-K.
The other non-negotiable is grounding. Every piece of evidence an agent presents has to be a real artifact pulled from an authoritative system and traceable back to it, never something the model generated because it fit the pattern. An invented approval screenshot is not a time saving. It is fraud with better formatting. The discipline is the same one that separates every production agent from a demo: the model may summarize and route, but the facts come from the system of record, labeled and linked, and a human stays in the loop on anything expensive to get wrong.
Where Salesforce fits, and where it does not
Because this is a Salesforce shop, the honest map matters. Salesforce does not ship a SOX controls-testing engine, and Agentforce does not audit your ICFR. The dedicated audit platforms and the controls themselves own that core. Anyone pitching Agentforce as a SOX auditor is overclaiming.
What Salesforce does well sits around the audit. A great deal of financial-control evidence originates in the CRM and the processes bolted to it: approvals, opportunity-to-order controls, access changes. Grounding an agent on that data through Data 360, and orchestrating the request-and-review workflow that moves an exception to the right owner with full context, is native territory. The adjacent work of speeding the financial close without breaking the audit trail is the closer fit, and for a regulated financial-services org the governance bar on any of it is higher.
The realistic pattern is integration, not replacement: the audit platform tests and documents, Salesforce grounds and orchestrates the pieces that live in the CRM, and a human signs. Deciding which bets pay and which to leave alone, before you buy an agent that becomes a control you have to defend, is the point of a vendor-neutral data and AI roadmap.
What I would do
Start where the work is pure retrieval and the risk is low: evidence collection and workpaper drafting, with a human reviewing before anything is filed. Prove the agent pulls real, traceable artifacts before you let it test anything. Build full-population testing next, on the automated and report-based controls where it adds assurance a sample cannot.
Separate the agents from the start. The agent that operates a control is never the agent that tests it, with distinct access and distinct owners, because retrofitting segregation of duties after an auditor flags it is a bad quarter. Treat every evidence agent as a control in its own right, with an owner, a change log, and testable ITGCs.
Then keep the conclusion human. The gain is handing a person a complete, tested, traceable workpaper so their time goes to judgment instead of screenshots. The agent does the quarter’s retrieval. The auditor still signs the opinion, and that line is the one worth defending.
Understanding the basics
Can AI agents do SOX controls testing?
Partly. An agent can collect evidence from source systems, test the full population of control executions rather than a sample, draft the workpaper, and flag exceptions for a human. What it cannot do is form the auditor’s opinion or provide the independent sign-off that PCAOB AS 2201 requires. The working pattern is the agent clears the routine population and escalates exceptions to a person who exercises judgment and signs.
Why can’t the same agent operate and test a control?
Because SOX depends on segregation of duties, and an agent that both performs a control and tests it has no independence. A shared flaw in its logic becomes invisible, since the operating side and the testing side inherit the same blind spot. You rebuild the separation deliberately with distinct agents, access, and owners for operating a control versus testing it.
Is an AI agent that tests controls itself a control?
Yes. An agent that collects and evaluates audit evidence sits inside the internal-control-over-financial-reporting chain, so it is subject to the same scrutiny as any automated control. Its access, logic, and outputs have to be tested, and the IT general controls around it have to hold. Give it an owner, a change log, and version history, because your next audit will examine it.
Does Salesforce Agentforce do SOX compliance?
Not the core of it. Salesforce does not ship a controls-testing or audit engine, so a dedicated audit platform owns that work. Agentforce fits around the edges: grounding an agent on control evidence that originates in the CRM through Data 360, and orchestrating the review-and-approval workflow for exceptions. The right design is Agentforce alongside an audit platform, each doing what it is built for, with a human signing the opinion.
Weighing where an agent fits in your SOX and internal-audit process, and where it becomes a control you have to defend? Drawing that boundary, and grounding the agent in authoritative evidence, is the kind of work we do. Talk to us.
