Segregation of duties breaks the moment an AI agent gets write access to your ERP, because the control was never designed for an actor that can hold every role at once. Classic SoD assumes a human occupies one seat: the clerk who creates the vendor master record is not the manager who approves the payment, and whoever posts the journal entry is not whoever reconciles the account. An agent has no seat. It has a credential, and that credential carries whatever scopes were convenient the day someone wired up the integration.
The predictable result is one non-human identity that can create a vendor, raise a purchase order, post a journal entry, clear it under an auto-approval threshold, and reconcile the account it just touched. Every step produces a clean log line and none is technically unauthorized. The failure is structural, not behavioral, which is why it slips past most SoD tooling: conventional rulesets compare human role assignments to each other, and the agent is not in the role model at all.
This is arriving now, not next cycle. BlackLine took its Verity Prepare multi-agent reconciliation system to general availability on July 27, 2026. Microsoft's Account Reconciliation Agent for Dynamics 365 Finance is in production ready preview. Workday's Financial Close Agent was announced in September 2025 for 2026 availability. The agents are shipping. The role models underneath them mostly are not.
Agents concentrate duties for three structural reasons: they are provisioned as integrations instead of employees, granted task scope instead of role scope, and reused across processes no single person would be allowed to span.
Provisioning fails first. An agent arrives through a project, not through HR, so nobody files a role request or runs the proposed permission set through the SoD ruleset that would have rejected the same combination for a person. It gets an API user, a client secret, and a permission bundle assembled by whoever needed the pilot working by Friday.
Scope fails second. Human roles are bounded by function and usually by entity, cost center, or account range. Agent permissions are bounded by verb: "post journal entries" is granted as a raw capability, not a role tied to a ledger, company code, or period. Reuse compounds both. The identity that started in bank reconciliation gets pointed at intercompany, then accruals, then vendor onboarding, because it already authenticates cleanly, and no single expansion looks large enough to trigger review.
A toxic combination for an agent is any pair of incompatible duties your auditors already test for, now held by a single principal that never switches hats. Break each of these at grant time rather than surfacing it after the fact:
The SoD question for an agent is not "what did it do?" It is "what could it have done with the scopes it holds?" A capability an agent has never exercised is still a control deficiency, because the conflict lives in the entitlement, not in the activity log.
Service accounts are the root cause because they were built to be broad, static, and shared, the opposite of what a duty-segregated role must be. A service account exists so a batch job never fails at 2 a.m., so its permission set is the union of everything anyone ever needed and its owner is often a team, a mailbox, or a departed engineer. Layer agents on top and three things break. Attribution collapses, because several agents authenticate as the same principal, so the log shows the account acted but not which agent or prompt drove it. Scope creep goes unnoticed. Revocation becomes impossible, because nobody can prove which consumer will break.
The fix is a distinct, named, sponsored identity per agent with its own credential and entitlements. Microsoft's Entra Agent ID governance model is a useful template: each agent gets a first-class directory object, a human sponsor accountable for its lifecycle and access, entitlements delivered through access packages with expiry dates, and automatic transfer of sponsorship if that person leaves. We go deeper on credentials and tokens in agent identity and access, and on the secrets handling behind it in our AI security practice.
Model the agent as a role by defining the role first, in business terms, then binding exactly one agent to it. The sequence matters. Most teams build the agent, discover its permissions by watching it fail, and back-fill a role definition that is really a transcript of the errors.
A defensible definition names the process step the agent owns, the entities and account ranges in scope, the transaction types it may originate, the maximum value it may act on without a human, the systems it may read, and the things it must never do. Write it before the first line of integration code. If the resulting permission set trips your SoD ruleset, you found the problem while it was still cheap. The corollary: one agent maps to one role, and a process spanning incompatible duties needs several agents with separate identities, not one agent with a longer tool list. That is the difference between an automation that survives a SOX walkthrough and one that gets pulled from the close in October. When we build custom AI agents for finance teams, role decomposition happens before the workflow automation design, not after.
A second agent is a genuine control only when its failure modes are uncorrelated with the first agent's. A reviewer running the same model, on the same prompt scaffold, over the same data, from the same vendor, will agree with the maker almost every time the maker is wrong, because it is wrong for the same reasons. That is not maker and checker. That is one control counted twice.
Correlated failure is the whole risk. If the maker misreads an ambiguous bank memo, a checker on the same model misreads it identically, and confidence scores do not save you because confidence correlates too. COSO's 2026 guidance makes the point plainly: as Lucia Wind, Executive Director and Chair of COSO, put it, generative AI "can be confidently wrong, easily manipulated, or deployed outside formal oversight channels," per the February 2026 announcement.
An automated checker earns control status when it differs from the maker on at least two dimensions: a deterministic rules engine rather than a model, an independent source of truth such as the bank statement rather than the ERP extract the maker used, a different identity with read-only access to the maker's output, and a different owning team. Deterministic logic is usually strongest, and it pairs with the threshold design covered in deterministic controls for finance AI agents. Microsoft's Dynamics 365 agent, notably, recommends an action on voucher amount mismatch exceptions and leaves the accept decision to a person, a reasonable default until your independence story is solid.
COSO's Achieving Effective Internal Control Over Generative AI, released in February 2026 and summarized by the Journal of Accountancy, applies the five familiar internal control components to GenAI and sorts AI uses into eight capability categories: ingestion, transformation, posting, orchestration, judgment, monitoring, regulatory intelligence, and human-AI interaction. Read that as a role taxonomy. Posting, judgment, and monitoring are separate categories for the same reason maker, checker, and monitor are separate seats.
For SOX, nothing new is required conceptually: the 2013 framework already expects management to segregate incompatible duties and to select alternative controls where segregation is impractical. What changes is population and evidence. Your ITGC population now includes agent identities, the prompts and tool configurations defining their behavior, and the pipeline that promotes changes to them, which is why we run agent releases as an AI DevOps discipline. The urgency is real: CPA Practice Advisor, citing KPMG's March 2026 Global AI in Finance survey of 1,013 senior finance leaders, reported active AI use in finance rising from 30 percent in 2024 to 75 percent while only 42 percent called their organizations fully assurance ready.
An agent access review answers four questions per agent: who sponsors it, what can it do, what did it actually do, and does its entitlement set violate an SoD rule. Start from the identity provider and the ERP authorization tables, not a vendor console, because a vendor console shows you the agents that vendor knows about and nothing else.
The minimum evidence set is every non-human principal with write access to financial systems, its named sponsor, its effective permissions rather than assigned roles, its last-used date, the change history of its prompt and tool configuration, and your SoD ruleset output run against those permissions. Effective permissions are the hard part and the part that matters, since inherited scopes and nested groups routinely grant far more than a role name suggests. Pair this with tamper-evident logging so the review has something to test against, the subject of our piece on audit-grade evidence for AI agents.
Three things change once agent identities are in scope: the population, the reviewer, and the question. The population expands, because agent identities are in scope and the review is incomplete without them. The reviewer changes, because a process owner cannot judge whether an agent's OAuth scopes are appropriate, so these certifications need joint sign-off from the process owner and an engineer. And the question changes, from "does this person still need this access" to "has this agent's effective permission set changed, and does it still map to exactly one role in our SoD matrix." Add two certifications with no human equivalent: a dormancy check that disables any agent identity idle for 90 days, and an attestation that the prompt and tool list in production match what was approved.
Inventory every non-human identity with write access to the general ledger, subledgers, treasury, and vendor master, and give each one a named human sponsor. Extract effective permissions and run them through your existing SoD ruleset as if each agent were an employee. Break every conflict by splitting the agent into separate identities rather than bolting on a compensating review. Retire shared service accounts used by more than one agent. Then update your access review procedure and SOX control narratives to cover agent identities, prompt and configuration change management, and the two attestations above.
Infonaligy helps IT and finance leaders design agent role models, decompose toxic capability combinations, and rebuild access reviews that hold up in a SOX walkthrough. Our AI consulting team works from our Dallas–Fort Worth home base across Texas and Oklahoma on site, and nationwide remotely. If you are putting agents anywhere near the close, start with the role model, not the pilot. Reach us at hello@infonaligy.com or 800-985-1365.
Infonaligy works with organizations across the Dallas–Fort Worth metroplex, Texas and Oklahoma on site, with remote delivery nationwide.
We start with a full inventory of the non-human identities holding write access to your financial systems, then extract effective permissions rather than assigned role names and run them through your existing SoD ruleset. Where an agent holds a toxic capability combination, we decompose it into separate identities with separate credentials and separate sponsors instead of papering over it with another review step. We then rewrite your quarterly access review procedure, SOX control narratives, and change management process to cover agent identities, prompts, and tool configurations. The work is vendor-neutral and fits whatever ERP, identity provider, and agent platform you already run.
Infonaligy