Nine months later an auditor asks who authorised it as a change to a financial control. Finance points at IT. IT produces a properly logged administrative change made within policy by someone entitled to make it. Both are telling the truth. Neither is answering the question, because nobody in the financial control path ever saw the change as a change to a control.
Nobody did anything wrong. What happened is that the agent sits inside two governance systems at once, and the two do not share a definition of what had just occurred.
Two Systems, Both Legitimate
This is not a story about one side governing badly.
Financial control governance is mature. Segregation of duties, role design, approval hierarchies, change control over configuration, period-end discipline, retained evidence. It has been shaped by decades of audit and regulation, it is owned by the controller and finance leadership, and its rulesets are written in terms of job roles and enforced against user accounts.
AI and identity governance is newer and moving faster. Agent identity and lifecycle, what data an agent can reach, tenant policy about what is permitted, model and version management, monitoring and inventory. It is owned by IT and security, and it treats what it governs as technical objects with configurations and permissions.
Both are competent. Both are necessary. Neither was designed with the other in mind.
It is worth saying that agents are not the first object to land in both. Robotic process automation raised the same questions a decade ago — bot credentials inside a duties matrix, a bot inventory that never quite reconciled to the control matrix. What is different now is that the object is less predictable and its scope changes more often, which turns a filing problem into a live one.
Where the Two Systems Collide
These are structural rather than local failures, which is why they tend to recur.
- Who the actor is. Duties rulesets are written for job roles and enforced against user accounts. An agent’s identity lives in the directory. So which actor does the matrix test — the agent, its owner, or whoever configured it? Get that wrong and an agent can hold a combination of permissions you would refuse a person.
- Two definitions of change. Extending scope might be an ERP configuration change subject to change control, or an administrative setting adjusted under IT policy, or both. If only one path captures it, the period’s record has a gap that nobody notices until somebody asks. What an auditor actually wants in that situation is a separate subject, and one we have written about.
- Two registers. Finance maintains a control matrix. IT maintains an agent inventory. Unreconciled, an agent can be fully documented in one and absent from the other, and both sides will reasonably believe it is covered.
- Two clocks on the evidence. This is the one that does real damage. Financial evidence is retained for years because that is what audit and regulation require. Platform activity logs are retained according to an IT policy, often measured in months. The evidence that an agent-performed control operated can therefore be deleted, entirely properly, by a policy owned by people who were never told it was audit evidence.
- Two cadences, and a vendor inside the control. ERP change is deliberately periodic and tends to freeze around close. Platform capability moves on a vendor release schedule. Customers are notified — release plans exist — but notification lands with IT, not in the finance change-control path, so a capability can change inside a period finance considers locked without anyone in the control chain registering it. Underneath that sits a harder point: the control’s behaviour now depends partly on a model version somebody else controls. Finance handles third parties through service-organisation reporting; IT handles them through vendor risk. Neither register has a row for “this control depends on a vendor’s release decisions.”
- Two vocabularies. In finance, approval usually means a named person authorising a specific item. In AI governance it more often means a policy permitting a category of action. Same word, different meaning, which makes cross-team conversations feel settled when they are not.
- Two escalation paths. A control failure goes to finance leadership and eventually the audit committee. A policy violation goes to security. An agent that reconciles wrongly is both, and whoever picks up the phone first frames how it gets examined. Where oversight belongs is a question each side tends to answer differently.
The Gap Underneath All of Them
Finance owns the control. IT owns the agent. Very few organizations have anyone who owns the agent-as-a-control — the pair, as one governed thing with one name against it.
Each side is discharging its responsibilities properly inside its own frame, which is exactly why the gap is invisible from either side. And it produces a distinctive failure: not a breach, usually not even an error, but a disagreement discovered late, when somebody external asks a question that requires both systems to have been telling the same story all along.
Why Merging Them Is Not the Answer
The instinct is to consolidate — one forum, one register, one owner for everything. That instinct needs qualifying rather than following.
Financial control governance encodes regulatory obligation and audit expectation. AI and identity governance encodes technical risk finance is not equipped to assess. Collapse the two frameworks into one and you get a body expert in neither, and a control framework that no longer maps to what an auditor expects to see.
The honest counter-argument deserves stating, because it is stronger than it first appears. Interfaces between two governance functions are the fragile option: they have no owner, they degrade into email, and they lapse under load. A joint forum at least has a chair and a recurring slot in the calendar. Much mainstream guidance points that way — towards cross-functional bodies rather than negotiated boundaries.
The distinction worth holding is between merging bodies and unifying accountability. A shared forum with both functions in the room is often sensible. Merging the two registers and control frameworks into one is not, because the financial one has to survive contact with an auditor in a form they recognise.
The Interface Worth Defining
The specific decisions an agent deployment needs — naming an owner, defining what review means, re-testing duties, watching what ships monthly — are a separate exercise, and a mostly practical one. What follows is narrower: the small number of rules that govern how the two systems talk to each other.
- Cross-reference the two registers. Every agent appears in the control matrix and in the agent inventory, each carrying the other’s identifier. Reconcile on a defined cadence and treat a mismatch as an exception, not untidiness.
- Route changes by effect, not by console. If a change alters what an agent may do, to what value, or over which entities, it follows the financial change path — regardless of which interface it happens to be made in. Most of the trouble in the opening scenario disappears with this one rule.
- Agree the authority map in advance. Which system decides on scope, thresholds, data access, model changes, incident classification. One page. Disagreements are far cheaper before an incident than during one.
- Reconcile the retention policies. Establish how long platform logs are kept, compare it with how long financial evidence must be kept, and fix the shorter one. This is usually a setting, and almost always a surprise.
- One incident path, dual notification. Whoever receives the report first, both functions learn of it, and classification is decided jointly rather than by whoever answered.
None of this needs a new committee. It needs decisions that are currently implicit to be written down, and the register reconciliation to have a date attached.
Where This Actually Bites
Governance rarely fails at the level of principle. It fails at the level of “which console was that changed in, and does the other system know.”
For most of enterprise software’s history there was a clean division of labour: IT governed the systems, the business governed what people did inside them. An agent sits across that line, because it is simultaneously a technical object with a configuration and an actor performing a financial process. The division was never written down as an assumption, which is why nobody notices when it stops holding.
The practical test is short. Pick one live agent. Ask who is accountable for it as a financial control, where it appears in both registers, how long its activity log survives, and which console its permissions can be changed from. If those four answers take more than a few minutes to assemble, the interface has not been defined — and that is a conversation, not a programme.
DAX Software Solutions works on both sides of this. Our readiness work examines whether the ERP, the data, the integration and the governance around them can actually support an agent, and the operating-model piece is largely about making implicit arrangements explicit before an auditor or an incident does it for you. Related reading: which processes to give an agent first, and how much supervision a finance team can realistically provide.
Scope and caveat. This article describes general governance practice and is not audit, accounting or legal advice. Requirements differ by jurisdiction, regulatory regime, auditor and entity, and platform behaviour changes frequently — confirm the current position with your own auditors, advisers and administrators.
Four answers, one agent, a few minutes. That is the whole diagnostic, and it is worth running before something forces you to. We are glad to run it with you.