One agent, many duties
The obvious failure. An agent that creates vendors, codes bills, approves them, and schedules payment holds four duties a control framework deliberately separates.
AI governance
A control framework separates who creates a vendor from who pays one, because concentrating both is how money leaves quietly. Automation reconcentrates those duties by default — one agent doing four jobs a policy manual spent a decade splitting apart — and almost nobody is checking.
Tell us your size and current controls. We will map where automation would create a conflict.
Six ways it breaks
The obvious failure. An agent that creates vendors, codes bills, approves them, and schedules payment holds four duties a control framework deliberately separates.
Where an agent inherits the credentials of whoever triggered it, the audit trail shows a person doing something software did — and every SoD assertion built on that trail is wrong.
If the person who grants an agent authority also writes the rules defining what that authority permits, they hold an unreviewed ability to automate postings.
If agent actions are logged separately from human ones, or not at all, an auditor cannot test the population and has to assume the worst about it.
An agent that can re-attempt a rejected action under different framing has an effective authority higher than its stated one. Ours cannot retry a policy rejection.
Any path by which an agent modifies its own permissions collapses the whole model, which is why that capability is absent rather than merely restricted.
The single decision that determines whether segregation survives automation is whether an agent has its own identity. Treat it as a tool that a person wields, and it inherits that person’s permissions and appears in the log as them — at which point your audit trail is describing something that did not happen.
Treat it as an actor, and it holds its own identity, its own permission set, and its own entries in the same trail as everyone else. Every conflict rule that applies to a person then applies to it without anyone writing a second framework.
Four questions, and we would rather you ask them than take this page on trust. Does each agent have its own identity, or does it act as the triggering user? Can an agent hold two conflicting duties under any configuration? Can an agent modify its own permissions or retry a rejected action? And can you produce, for any period, the complete list of actions taken by automation and the authority under which each was permitted?
The last one is the practical test. A vendor who cannot produce that list has not thought about this, whatever their documentation says.
Audit firms are becoming specific about automated activity inside financial systems. The questions arriving now are what the software was permitted to do, whether that changed during the period, and how you would detect it acting outside scope — all of which are answerable here and unanswerable in most systems.
Questions
We will walk your audit team through the conflict matrix and the automation record, without a salesperson present.