Agentic Segregation-of-Duties Monitoring: Catching Toxic ERP Access Combinations Before They Become a Fraud or Audit Finding
written by Cooter:Labs
published on August 8, 2026
Introduction
Segregation-of-duties violations rarely get caught because someone is actively defrauding the company. Far more often they get caught because a quarterly access review finally runs, and it turns out a warehouse supervisor has held both 'create vendor' and 'approve payment' permissions for eleven months after a role change nobody cleaned up. The access itself isn't the fraud — it's the exposure that makes fraud, or an honest but uncorrected mistake, possible without a second person ever noticing. Most ERPs ship an SoD rule matrix that can, in principle, catch this. Most companies still only run it on a schedule, which means the gap between when a toxic combination gets granted and when anyone looks for it is measured in months, not days.
Access control and audit findings are the same problem seen at different times
A segregation-of-duties conflict is a statement about what a single user account is capable of doing unsupervised — create a vendor and pay it, create a purchase order and approve it, post a journal entry and approve the reconciliation that would catch it. Whether that capability ever turns into an actual loss or a misstatement depends on whether it's exercised, and whether anyone is watching for it in between the periodic reviews that most companies still rely on. An agent that treats access-and-usage as a continuous signal, rather than a quarterly snapshot, closes exactly that gap — not by locking down every dual-permission user reflexively, but by surfacing the combinations that are both live and actually being used before they show up as a finding.
Every mainstream ERP's GRC or access-control module ships with a standard conflict matrix: AP clerk plus vendor master maintainer, PO creator plus PO approver, journal entry preparer plus GL reconciliation approver, and dozens of similar pairs specific to procure-to-pay, order-to-cash, and record-to-report. None of that logic needs to be invented. What's missing in most implementations is cadence — the matrix runs against a point-in-time snapshot of role assignments during a quarterly or annual access review, not continuously against role changes as they happen. An agent wired to the ERP's role-assignment events can evaluate the same matrix the moment a role is granted, modified, or combined with an existing one, instead of waiting for the next scheduled review to discover the conflict has existed for months.
Holding two conflicting permissions is not the same as having used both of them on the same transaction chain, and treating every technical conflict as equally urgent buries the ones that matter under the ones that don't. An agent that correlates role conflicts against actual transaction logs — did the same user ID that created this vendor record also release the payment run that paid it, did the same person who created this PO also approve it past a threshold that should have required a second approver — can rank findings by whether the exposure was ever exercised, not just theoretically present. A dormant conflict on an account that's never touched both sides of the transaction is a cleanup item; a conflict where the same user demonstrably did both is the one that needs same-week attention.
SoD conflicts rarely get granted deliberately — they accumulate through role creep, where an employee moves teams, picks up a temporary responsibility, or inherits a predecessor's access profile wholesale because rebuilding it from scratch takes longer than copying it. Each individual grant looks reasonable in isolation; the conflict only exists in the union of everything a user has accumulated over time, which is exactly what a point-in-time review is bad at catching if it's comparing against last quarter's baseline rather than evaluating the full current profile against the matrix fresh. An agent re-evaluating the complete access profile on every change, not just the delta, catches the conflict that emerged from three unrelated, individually-approved grants stacking on top of each other.
Not every conflict gets remediated by removing access — sometimes the fix is a documented compensating control instead, like a monthly independent review of a specific user's transactions by someone outside their reporting line. The problem in most companies isn't that this doesn't happen; it's that the compensating control lives in a spreadsheet or a SharePoint doc disconnected from the access system, so nobody can verify it's actually being performed on schedule, and an auditor asking for evidence gets a stale file instead of a log. An agent can track the compensating control as a recurring task tied to the specific conflict it mitigates, flag when the review is overdue, and produce the evidence trail an audit actually needs instead of a document someone has to reconstruct from memory.
Looking Ahead: Challenges and Innovations
Small teams need people to legitimately wear multiple hats, and a rigid matrix can't tell the difference
A twelve-person subsidiary's controller may legitimately need both journal entry and reconciliation-approval access because there's no one else to split the work with, and a blanket policy that flags every technical conflict as a violation to be remediated will generate a stream of findings that the business correctly ignores — which then trains everyone to ignore the agent's flags generally, including the ones that matter. The workable approach scopes urgency by entity size and available headcount, not a single global rule, and routes small-entity conflicts toward a documented compensating control rather than a remediation demand that isn't actually achievable.
Service accounts and integration users trip the same rules as human fraud risk, for different reasons
A batch integration account that posts journal entries and also has reconciliation access isn't a fraud exposure in the way a human user with the same combination is — it's a technical account doing exactly what it was configured to do, and it will still match the conflict matrix because the matrix doesn't distinguish account type. An agent needs an explicit allowlist of non-human accounts evaluated under different rules (or excluded and monitored separately for credential misuse instead), or every automated process in the ERP shows up as a standing SoD finding that dilutes the signal for the accounts that actually carry risk.
Firefighter access is supposed to be temporary, and temporary is where automated tracking usually breaks down
Emergency or 'firefighter' access — elevated permissions granted for a specific incident, meant to expire automatically — is a legitimate and necessary workflow, but it's also where SoD violations quietly become permanent, because the time-box gets extended informally or the access simply never gets revoked once the incident is resolved. An agent tracking firefighter grants needs to treat the expiration itself as the thing being monitored, alerting when a time-boxed grant is still active past its window, rather than only evaluating whether the grant currently conflicts with something else. The risk isn't that firefighter access was granted; it's that nobody circled back to take it away.
The metaverse
As more procure-to-pay and record-to-report activity moves through agentic workflows that themselves hold system access — creating vendor records, drafting journal entries, initiating payment runs — SoD monitoring has to extend to cover what an AI agent's own service account can do, not just what human employees can do. The same conflict logic applies: an agent that can both propose a payment and approve it without a human in the loop is a segregation-of-duties violation regardless of whether the account is a person or a process. Companies that already track access as continuous, correlated data rather than a quarterly spreadsheet snapshot are better positioned to extend that same monitoring to their own automation as it takes on more transactional authority.
Conclusion
Segregation-of-duties risk isn't created by any single access grant — it accumulates from role creep, inherited permissions, and firefighter access that never got revoked, and it typically surfaces only when a scheduled review or an actual audit finally looks. An agent that evaluates the full access profile continuously, correlates conflicting access against whether it was actually exercised, and tracks compensating controls as verifiable data rather than a static document doesn't eliminate the underlying tradeoff between operational flexibility and risk. It just means the company finds out about a toxic combination while it's still a data point to review, instead of after it's already become the finding.
Share this post:
Curious what this means for your business?
Get a personalized ROI estimate, or book a free discovery workshop with our team.