AI Agents and SOX Controls: ITGCs, SoD and Evidence

AI agents that post journals, match invoices, change vendor master data or deploy code into financial systems are acting inside the scope of Sarbanes-Oxley, yet most ITGC designs assume every actor is either a named person or a fixed, benchmarked program. An agent is neither: it holds credentials like a service account, makes judgements like a clerk and can change its own behaviour when a prompt, model or tool changes. That breaks familiar evidence for access reviews, segregation of duties and change management. This guide shows how to map agent activity onto logical access, program change and operations controls, what evidence external auditors will ask for, and how to keep segregation of duties meaningful when software does the work. It is written for IT audit, SOX programme leads, finance systems owners and the security teams that run agent identities. The underlying SOX framework, scoping and deficiency evaluation are covered in the SOX IT General Controls (ITGC) Guide, which this page builds on rather than repeats.

Key takeaways

Agents are in-scope users with extra properties. Treat each agent that touches a financially significant system as a non-human identity with an owner, a role, a review cycle and its own credentials, never a shared service account.
An agent is not an automated control. PCAOB AS 2201 benchmarking relies on controls that do not change and are not subject to human-style breakdowns; a model-driven agent fails both tests, so test it like a manual control with machine speed.
Prompts, models and tools are program changes. A new system prompt, a model version upgrade or an added tool can change what reaches the ledger, so all three go through change management with approval and testing.
Segregation of duties applies across the whole chain. The person who configures an agent, the agent itself and the approver of its output must not collapse into one actor, and one agent must not both prepare and approve.
Evidence must come from the system, not the agent. Independent, tamper-evident logs tied to agent identity are what auditors can rely on; an agent's own summary of what it did is not evidence.

Why agents strain existing ITGCs

PCAOB AS 2201 requires the auditor to understand how IT affects the company's flow of transactions (paragraph .36) and notes that IT risks are not a separate evaluation: they sit inside the top-down audit of internal control over financial reporting. AS 2110 Appendix B (paragraph B4) lists the IT risks the auditor must understand. Read through an agent lens, every one of them becomes sharper.

AS 2110 B4 risk	How an agent raises it	Control response
Unauthorised access to data leading to destruction or improper changes	Agent holds a broad API token or database role; prompt injection can redirect it	Per-agent identity, least privilege, read-only by default, write scopes per task
Access privileges beyond those needed for assigned duties	Agents accumulate tools and scopes as use cases grow (permission drift)	Agent entitlement baseline, quarterly recertification, automated drift alerts
Unauthorised changes to master file data	Agent updates vendor bank details, customer credit limits or chart of accounts	Master data changes by agents routed to human approval; field-level restrictions
Unauthorised changes to systems or programs	Prompt, model or tool configuration changed outside change control; coding agents deploy to production	Agent configuration under version control, approved releases, no deploy rights for agents
Inappropriate manual intervention	Agent acts with a human's delegated session, so actions look like the human's	Distinct agent identity in every log; on-behalf-of claims recorded
Loss of data or inability to access it	Destructive actions executed at machine speed	Approval gates for deletes, tested backups, kill switch

The PCAOB staff Spotlight of July 2024 found companies exploring generative AI in accounting and financial reporting, though as a secondary use, and firms stressed strong supervision. COSO followed in February 2026 with Achieving Effective Internal Control Over Generative AI, which maps generative AI risks to the 17 principles of the 2013 framework and names "workflow orchestration and autonomous task execution" as a distinct capability type. Expect auditors to arrive with that vocabulary.

Inventory and scoping: which agents are in scope

Scoping still starts top-down from significant accounts and relevant assertions (AS 2201 paragraph .21). The new step is to find every agent that sits on the path from a transaction to the ledger.

Start from in-scope systems: for each ERP, subledger, consolidation, billing and treasury system already in SOX scope, list the non-human identities with write access and identify which are driven by a model or agent framework.
Add agents outside the system boundary: agents that prepare reconciliations in spreadsheets, draft journal entries for upload, or produce key reports used in management review controls. Their output is information produced by the entity (IPE) even if they never log in to the ERP.
Classify each agent by role: read-only analysis, preparer (drafts entries or matches for human approval), executor (posts, pays or changes data), or developer (writes or deploys code to in-scope systems).
Record ownership: a named business owner accountable for the agent's output and a technical owner accountable for its configuration and credentials.
Include hosted and vendor agents: agent features inside SaaS finance applications run under the vendor's control; AS 2201 paragraph B18 requires the service organisation's activities to be included when they are part of internal control, so map them to SOC 1 coverage and complementary user entity controls.

Keep the result in an agent registry that audit can sample from. See the AI agent registry and the Audit Readiness for AI Agents and NHIs guide.

Logical access controls for agents

Provisioning: each agent gets its own identity created through the same request and approval workflow as a person, with the business justification and the exact scopes recorded. Shared service accounts used by several agents defeat attribution and fail access review.
Least privilege by role: preparer agents get create or draft permissions but no post, approve or release rights. Executor agents get narrowly scoped write permissions with transaction value limits enforced in the target system, not in the prompt.
Credentials: short-lived tokens issued per session or per task, no passwords or static keys in agent configuration, and no reuse of a human administrator's credentials. Delegated (on-behalf-of) access must keep both identities visible in logs.
Access reviews: include agents in user access reviews with their full tool list, scopes and the systems they reach. Reviewers need to see what the agent actually did in the period, not just what it is allowed to do. See the Agent Identity Recertification guide.
Deprovisioning: retiring an agent revokes tokens, removes tool connections and disables the identity in every in-scope system. Test it with the same leaver sample you use for people.
Privileged use: agents should never hold ERP superuser, database owner or production deploy rights. Where elevated actions are unavoidable, require just-in-time elevation with human approval and log each use (NIST SP 800-53 AC-6(9)).

Segregation of duties when agents do the work

Segregation of duties exists so that no single actor can initiate, approve and record a transaction, or create a vendor and pay it. Agents create three new ways to break it.

Conflict	How it appears with agents	Design that keeps duties separate
Same agent prepares and approves	One agent drafts a journal and calls an approval API with its own token	Approval rights never granted to the preparing identity; approvals by a named human in the target system
Human configures the agent and approves its output	The finance analyst who writes the agent's instructions also approves what it posts	Configuration owner and output approver are different people, recorded in the registry
Agent spans incompatible roles	One agent can create vendors, change bank details and propose payments	Split into separate agents with separate identities; run your SoD ruleset against agent roles as well as human roles
Agent acts on behalf of a conflicted human	Delegated access inherits a user who already holds conflicting roles	SoD checks evaluate the combined permissions of the human and the agent tools in use
Agent chain launders approval	Agent A asks agent B to perform the step A is not allowed to do	Authorisation checks at the target system on the end identity; delegation chains logged and attenuated

Run your existing SoD conflict matrix against agent identities with the same rigour as people. AS 2201 paragraph .42 recognises that smaller companies may have limited opportunities to segregate duties and must show alternative controls; agents can make that worse or better depending on design. See the Segregation of Duties Guide and Dual control and four-eyes approval for privileged and agent actions.

Change management: prompts, models and tools

For a conventional program, change management covers code. For an agent, behaviour is defined by several components, any of which can change outputs that reach the financial statements.

Model version: a provider upgrade or a switch to a different model is a change. Pin versions in production and treat upgrades as releases with regression testing against a fixed set of accounting cases.
Instructions and prompts: system prompts, policies and few-shot examples go into version control, with peer review and approval by the business owner before release. COSO's 2026 guidance calls out prompt and configuration governance and change control as a control building block.
Tools and connectors: adding a tool, changing its scopes or connecting a new MCP server alters what the agent can do. Route these through the same approval as an access change.
Retrieval sources: changes to the documents or tables an agent retrieves from (policy manuals, chart of accounts mappings) can change its decisions; control who can edit them.
Coding agents: code written by an agent for an in-scope system follows the normal developer-to-production separation. The agent opens a pull request; a human reviews and a pipeline with separate credentials deploys. Agents do not hold deploy rights or direct database write access in production.

Complete change populations must come from system logs (repository history, model gateway configuration, agent platform audit logs), not from a change ticket list alone, so the auditor can test that every change was approved.

Testing agent controls: what auditors will ask

AS 2201 paragraph B28 says entirely automated application controls are generally not subject to breakdowns due to human failure, and B29 allows benchmarking when ITGCs are effective and the control has not changed since the baseline. A model-driven agent can give different outputs for similar inputs and changes when any component changes, so it does not fit benchmarking. Practical consequences:

Treat agent output as preparer work: the key control is usually the human review or approval of what the agent produced, designed with a stated precision (thresholds, sample sizes, what the reviewer checks) and evidence of performance.
Test operating effectiveness by re-performance and inspection: paragraph .50 makes clear inquiry alone is not enough. Sample agent actions from system logs and re-perform them or inspect the reviewer's evidence.
Prove completeness and accuracy of agent-produced reports: if a reviewer relies on an agent's reconciliation or exception list, test that the agent's input population was complete and its logic accurate, as for any IPE.
Hard limits belong in the system: value limits, approval workflows and field restrictions configured in the ERP can be tested as configured automated controls; instructions in a prompt cannot.
Agree evidence early: COSO recommends agreeing with internal and external auditors early on what counts as sufficient evidence for generative AI-enabled controls. Do this before go-live, not at year end.

Evidence item	Source system	Supports
Agent registry extract with owners, roles, scopes	Agent registry or IGA platform	Access provisioning, reviews, SoD
Per-action log: agent ID, on-behalf-of user, tool, target record, timestamp, outcome	Agent platform, ERP audit trail, SIEM	Operating effectiveness sampling, attribution
Model version, prompt version and tool configuration in force on each date	Repository, model gateway	Change management, roll-forward
Approval records for agent-prepared entries	ERP workflow	Review control performance
Change tickets linked to configuration commits	ITSM and repository	Program change completeness
Token issuance and revocation records	Identity provider, secrets manager	Credential management, deprovisioning

Logs used as evidence need integrity protection and retention for the audit period plus roll-forward (NIST SP 800-53 AU-9). See the AI Agent Audit Trails for Regulators Guide.

Computer operations and monitoring

Scheduled agent runs: treat recurring agent jobs (nightly matching, month-end accruals) like batch jobs: monitored for completion, failures escalated and reruns controlled.
Exception and override rates: COSO suggests monitoring transaction volume, transaction size and override rates. A rising rate of reviewers overriding agent output is an early sign of drift.
Behaviour monitoring: alert on agents calling tools outside their baseline, acting outside business hours where unexpected, or touching master data they normally do not.
Kill switch: the ability to suspend an agent's identity and tools in minutes, tested, with a documented manual fallback for the process.

Measuring control health

Agent ownership coverage: percentage of in-scope agents with named business and technical owners (target 100%).
Review completion: percentage of in-scope agents recertified in the cycle, with action evidence reviewed.
SoD violations: number of agent or human-plus-agent role conflicts open at period end.
Unapproved configuration changes: prompt, model or tool changes in production without a linked approval (target zero).
Override rate: share of agent-prepared items changed or rejected by reviewers, trended monthly.
Attribution gaps: agent actions in in-scope systems that cannot be tied to a unique agent identity (target zero).

Framework mapping

Area	PCAOB / COSO	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A
Agent accounts and access	AS 2110 B4; AS 2201 .36	AC-2, AC-6, IA-4	PR.AA-05	5.18
Segregation of duties	AS 2201 .42; COSO 2026 human oversight	AC-5	PR.AA-05	5.3
Prompt, model and tool changes	AS 2110 B4; COSO 2026 configuration change control	CM-3, CM-5	PR.PS-01	8.32
Logging and evidence	AS 2201 .44, .50	AU-6, AU-9, AU-12, AC-6(9)	DE.CM-03	8.15

Common failure patterns

Agents running under a shared integration account: several agents and a legacy interface share one ERP user, so no action can be attributed and access review is meaningless.
Controls written into the prompt: "never post entries above 10,000" in instructions is not a control; the limit must be configured in the target system.
Model upgrades outside change control: the provider's default model changes, outputs shift and nobody can say which version produced which entries.
Rubber-stamp review: reviewers approve hundreds of agent-prepared items without a defined precision, so the review fails as a control.
Coding agents with production access: developer-to-production separation lapses because the agent holds deploy or database credentials.
Delegated sessions hiding the agent: the agent acts with a finance user's session, so logs show the human and SoD analysis misses the agent entirely.

Lessons from incidents

The Replit AI Agent Database Deletion 2025 shows the change management point directly: a coding agent deleted a production database during a declared code freeze and then misreported whether rollback was possible. The freeze existed only as an instruction in chat, the agent held production write access and its own account of events was unreliable. In SOX terms that is a program change control that was never enforced in the system, plus evidence that could not be trusted. The same pattern applied to a ledger or vendor master file would be a deficiency to evaluate. See also the AI agents that destroyed data guide.

Practitioner checklist

Build an inventory of every agent with read or write access to SOX in-scope systems or that produces IPE, with named business and technical owners.
Give each agent its own identity and short-lived credentials; remove shared integration accounts used by agents.
Restrict preparer agents to draft rights and enforce value limits and approvals in the target system.
Extend the SoD ruleset to agent roles and to human-plus-agent combinations, including configuration owner versus output approver.
Place model versions, prompts, tools and retrieval sources under version control and change approval; pin production model versions.
Deny coding agents deploy and direct database write rights in production; route their work through pull requests and a separate pipeline.
Capture per-action logs with agent ID and on-behalf-of user into a protected store retained for the audit period.
Define the precision of human review over agent output and keep evidence of each review.
Include agents in quarterly access reviews and leaver tests, and test the kill switch.
Agree evidence expectations with the external auditor before any agent goes live in a financial process.

AI Agents and SOX Controls: Keeping ITGCs Intact When Agents Act