Why Agentic ERP Needs a New Control Framework, Not Just New Agents
Microsoft's 2026 release wave has pushed Dynamics 365 firmly into agentic territory: Business Central's Payables Agent now reads, matches, and stages vendor invoices without a human starting the process; Finance and Supply Chain agents triage exceptions and recommend postings; and Agent 365 has arrived as a control plane to register and monitor them. Most coverage of this shift focuses on productivity gains.
Far less attention goes to a harder question: who is accountable when an autonomous agent posts a transaction, and how do you prove that to an auditor?
This article examines the governance gap opening up inside agentic ERP deployments, why traditional segregation-of-duties (SoD) models break down when an agent can hold multiple "hats" at machine speed, and what a practical control framework looks like for finance and IT teams rolling out agents in Business Central or Finance and Operations today.
The Business Challenge: Agents Move Faster Than Controls Do
Every ERP control framework built over the last two decades assumes a human is the actor. SoD matrices separate the person who creates a vendor from the person who approves a payment to that vendor because a human acting alone, with bad intent or simple error, is the risk being managed. Approval thresholds assume a human pauses before clicking submit. Audit trails are built to reconstruct who did what, on the assumption that "who" is a named employee with a single role at a single point in time.
Autonomous agents violate every one of those assumptions. A single agent identity in Business Central's Payables Agent can read an invoice, match it to a purchase order, resolve a vendor discrepancy, and stage the payment for approval — actions that, mapped onto a traditional SoD matrix, would sit with three or four different human roles. The agent isn't circumventing controls maliciously; the control model itself was never designed for an actor that can legitimately perform multiple functions in milliseconds, continuously, outside business hours, without fatigue or hesitation.
This is not a hypothetical compliance problem. Internal audit and GRC teams have already flagged "toxic combinations" emerging where an agent's combined permissions recreate the exact conflict SoD was designed to prevent, just inside a single non-human identity instead of two human ones. If your SoD matrix was last reviewed for human roles, it has a blind spot the moment an agent goes live.
Expert Analysis: Three Places the Old Model Breaks
Identity and accountability. In a traditional ERP, "who posted this journal entry" resolves to one employee. With agents, the chain runs through the agent's service identity, the configuration that defined its permissions, the model or workflow that drove its decision, and the human who originally authorized the agent's scope — often months earlier and disconnected from the specific transaction. Microsoft's Agent 365 addresses part of this by giving agents an Entra-based identity and a registry, which is a meaningful step. But a registry entry telling you an agent exists is not the same as an audit trail telling you why it chose a particular GL account or vendor match on a specific Tuesday at 2 a.m.
Explainability versus logging. Most agent implementations log outcomes — invoice matched, payment staged, exception flagged. Far fewer capture the reasoning: which fields the agent weighted, what confidence threshold triggered escalation versus autonomous action, and what alternative it didn't choose. Auditors and regulators increasingly ask not just "what happened" but "why," and a transaction log without a decision rationale will satisfy neither SOX testing nor a skeptical controller reviewing a flagged anomaly.
Threshold drift. Approval thresholds were calibrated for human throughput — a controller can meaningfully review twenty exceptions a day, not two thousand. When an agent works at machine scale, the same dollar threshold that made sense for manual review can either bottleneck the agent's value (everything escalates) or quietly approve a volume of transactions no human ever meaningfully reviews (thresholds set too high to keep the agent useful). Few organizations have revisited their approval matrices with this volume shift in mind; most simply ported human-era thresholds onto agent workflows unchanged.
Practical Recommendations: Building the Control Framework
Start by re-papering your SoD matrix with agents as first-class actors, not exceptions. Map every permission an agent identity holds against the same conflict matrix you use for human roles, and treat any agent that spans multiple conflicting functions as a finding requiring compensating controls — not an oversight to quietly accept because "it's just automation."
Require decision-rationale logging, not just action logging, before any agent goes live in a financially material process. If your platform's agent framework does not expose why a match, exception, or escalation occurred, treat that as a go-live blocker, not a future enhancement. This is the single highest-leverage control investment available right now, because it is the evidence base every subsequent audit conversation will depend on.
Recalibrate approval thresholds explicitly for agent throughput, with a defined review cadence — for example, a statistically sampled review of auto-approved transactions rather than a transaction-by-transaction human check that was never realistic at agent scale. Document the sampling methodology itself, because that documentation is what will be tested.
Use a registry — Agent 365 or an equivalent — as the inventory layer, but build your actual control testing on top of it rather than assuming registration equals governance. A registered agent with unreviewed permissions is still an ungoverned agent; the registry only tells you it exists.
Finally, assign a named human owner to every agent in a financial process, distinct from the IT administrator who configured it. That owner is accountable for periodic permission review, for responding to anomalies the agent flags, and for the answer when an auditor asks "who is responsible for this agent's behavior."
Common Pitfalls to Avoid
The most common mistake is treating agent governance as an IT security question rather than a finance control question. Identity and access management matters, but SoD conflicts and approval-threshold design are finance and audit decisions that IT cannot make alone. A second pitfall is waiting for vendor tooling to mature before building internal governance — Agent 365 and equivalent control planes are evolving quickly, but your SoD matrix and approval policy are yours to own regardless of what the platform provides. A third is rolling out agents process-by-process without a consistent framework, which produces a patchwork where Payables has rigorous logging and Sales order automation has none, leaving auditors unable to give a consistent opinion on the control environment as a whole.
Future Outlook
Expect agent governance to formalize quickly over the next 12–18 months as external auditors build agentic AI into SOX testing programs and as frameworks like Agent 365 mature toward genuine policy enforcement rather than visibility alone. Organizations that build their SoD and logging discipline now, ahead of that formalization, will face a far lighter lift when the audit requirements catch up than those treating agents as a productivity feature to bolt on after the fact.
Key Takeaways
Agentic ERP capability is arriving faster than the governance models needed to control it safely. Traditional SoD matrices and approval thresholds were built for human actors and need explicit redesign for agent identities, not a one-time exception. Decision-rationale logging is now a more urgent investment than additional agent capability, because it is the foundation every audit and incident investigation will rest on. Registries like Agent 365 provide inventory, not governance — the control testing has to be built on top, not assumed from registration alone. Named human accountability for each agent in a financial process is non-negotiable, regardless of how autonomous the agent becomes.
Conclusion
The agentic shift in Business Central and Finance and Operations is real and the productivity case is strong. But finance leaders who treat this purely as an efficiency story are setting up a governance debt that compounds quietly until an audit finding, a duplicate payment, or a regulator's question forces a reckoning.
The organizations that get ahead of this will not be the ones with the most agents deployed — they will be the ones that can explain, with evidence, exactly what every agent did and why.