ERP Agent Governance Compared: Microsoft, SAP, Workday, Oracle

TL;DR

4 major ERP vendors have now shipped agent governance, and each put the control point somewhere different. No 2 of them answer the same question first.

Microsoft governs at 2 separate moments: the Agent 365 CLI scores an MCP server before use, the Agent Governance Toolkit judges each sensitive call at runtime (Microsoft Security Community Blog, 5 August 2026).

SAP governs at the runtime boundary, placing each agent inside "an isolated, sandboxed environment with configurable policies and guardrails" via NVIDIA OpenShell (SAP News Center, 13 May 2026).

Workday governs at the identity layer, with an Agent System of Record to "set clear roles for agents, define what data they can access, control what actions they take, and track their performance" (Workday, 3 June 2025).

Oracle NetSuite governs at the rollout, deciding per account who gets the capability at all: "NetSuite Next is being made available to customers in phases" (Oracle documentation).

All 4 name a protocol layer. Only 2 name a cost-of-agent control. That gap is where the next 18 months of surprise invoices live.

Why compare governance rather than agents?

Because the agents are converging and the governance is not.

Every vendor in this comparison now ships agents that read and write inside the transaction layer. Counting them has stopped being informative: the number goes up every release, and a bigger number is not a better answer. What still differs, sharply, is the mechanism each vendor gives you to decide what an agent may do, and that is the thing an operator has to live with.

Nobody maintains this comparison, so here it is, built only from each vendor's own published wording. Where a cell says "not stated", it means that vendor's primary documentation does not address it, not that the capability is absent.

What does each vendor actually control?

Microsoft. SAP. Workday. Oracle NetSuite

Primary control point. Build time and runtime, separately. Runtime sandbox. Agent identity and role. Rollout eligibility

Named mechanism. Agent 365 CLI · Agent Governance Toolkit. Joule Studio runtime · NVIDIA OpenShell. Agent System of Record · Agent Gateway. Phased per-account availability

What it judges. Server quality, then each sensitive call. What the agent can reach from its sandbox. What data and actions the role permits. Whether the account gets the feature yet

Protocol named. MCP. Multi-agent orchestration (n8n). MCP and A2A. Not stated

Audit trail. Same trails as human users. Built-in observability, lifecycle management. Track performance, support compliance. Not stated

Cost control. Not stated. Free design-time access to end of 2026. Budget and forecast agent costs. Not stated

Third-party agents. MCP compliant, cross-platform. Open frameworks, partner tooling. Agent Gateway, 15 named partners. Not stated

Read the "Primary control point" row twice. It is the whole story.

Where does each vendor put the control point, and why does it matter?

Microsoft splits it in two, and that is the unusual choice. The Agent 365 CLI evaluates an MCP server before an agent uses it, producing a per-tool score and a maturity rating. The Agent Governance Toolkit then evaluates individual calls while the agent runs. Microsoft's own framing is the clearest sentence any vendor has written on this: "One improves what the agent sees. The other governs what the agent does." We covered what that means against a 650,000-action surface when both shipped.

SAP governs the blast radius instead. Rather than scoring what an agent may call, SAP puts the agent in a box: NVIDIA OpenShell "places each agent inside an isolated, sandboxed environment with configurable policies and guardrails", with "built-in observability and lifecycle management" around it. That is a containment model rather than a permissions model, and it answers a different question. It does not ask whether an action is sensible. It limits what a bad action can reach. SAP separately put its agents under an ISO 42001 control tower, which is the compliance half of the same story.

Workday treats an agent as a member of staff. The Agent System of Record exists to "set clear roles for agents, define what data they can access, control what actions they take, and track their performance", and the vocabulary is deliberate: Workday describes managing agents as "hire, onboard, assign responsibility, and manage agent outcomes". It is the only one of the four to name cost as a governed dimension, with budgeting and forecasting for agent spend. It is also the only one to name both MCP and A2A. We looked at the system-of-record framing when it landed.

Oracle governs by not shipping it to you yet. That sounds like a joke and it is not. NetSuite Next arrives per account, in phases, and eligibility is announced by in-app notification rather than by date. A capability that has not reached your tenant cannot be misused in your tenant. It is the crudest control in the table and, for a mid-market shop with no platform team, arguably the safest default.

What is the gap nobody is covering?

Cost. Of the 4 vendors, exactly 1 names agent spend as something you govern.

Work the arithmetic on why that matters. An agent that makes decisions inside an ERP is called by a workflow, and workflows run at the volume of the business rather than the volume of the team. A mid-market distributor processing 2,000 orders a month, with an agent invoked 3 times per order, is 6,000 agent invocations a month from a single workflow. Add a second workflow at the same rate and it is 12,000. Nobody signs off on 12,000 of anything; they sign off on "turn the agent on for order entry".

Microsoft, SAP and Oracle's primary documentation on these features does not address budgeting or forecasting for that. Workday's does. That is not a criticism of three vendors so much as a warning about a class of surprise: the permission to use an agent and the budget to use it at business volume are different decisions, and only one of them currently has a control surface.

What should an operator take from the table?

Match the control point to your actual risk. If your worry is an agent doing something stupid but permitted, Microsoft's runtime toolkit is aimed at exactly that. If your worry is an agent reaching something it should never have touched, SAP's sandbox is the right shape. If your worry is nobody knowing which agents exist and what they cost, Workday's model is the only one that names it.

Assume you will run more than one vendor's agents. MCP is named by Microsoft and Workday, A2A by Workday. The interoperability story is real and it means the governance question stops being "how does vendor X govern" and becomes "which system holds the roster when agents from three vendors touch the same order".

Ask every vendor the cost question in writing. It is the column with the most "not stated" in it, and the one that scales with your business rather than your headcount.

FAQ

Is one of these four clearly the best?

No, and the comparison is more useful once you stop looking for that. They control different things. The right question is which failure you are most exposed to.

Does a sandbox make a permissions model unnecessary, or the reverse?

Neither. A sandbox limits reach, a permissions model limits intent. An agent can do something permitted and wrong inside a perfect sandbox.

Why does "not stated" appear so often?

Because this table is built only from each vendor's own published wording on these specific features. A vendor may well have the capability and not document it here, and inferring it would make the table less useful, not more.

Does MCP support mean agents are portable between these ERPs?

It means the protocol is shared, not that the permissions are. An agent that can technically call two systems still needs a role in each.

The last mile

All 4 vendors automate the step, and the governance work shipping this year is genuinely serious engineering. Scoring a server, sandboxing a runtime, giving an agent a role, staging a rollout: each of those is a real answer to a real risk.

None of them answers whether the action an agent is permitted to take is the optimal one for this business, on this order, at this margin, today. Governance decides what may happen. The margin lives in which of the permitted things actually should. That is the difference between a system of record and a system of intelligence, and it is the layer Cognilium works in.