2938 Members
Join Permit's SlackEnterprise systems are entering a new phase: instead of users clicking through screens, AI agents are executing multi-step work across finance, HR, procurement, and payroll. In that world, MCP for ERP is not just a connectivity pattern. It is the runtime surface where an agent decides what to do next, calls a tool, and potentially changes critical records.
This is why agentic ERP changes the security conversation. Classic ERP controls were designed around humans, roles, and transaction codes. Agentic workflows are dynamic, contextual, and often delegated, so authorization must evaluate who the agent is acting for, what step it is on, and what risk level that action carries.
Vendors are already moving in this direction with offerings like SAP Joule and Microsoft Dynamics agents, including integration patterns that align with MCP principles in Dynamics 365 finance and operations contexts (reference). The architecture question now emphasizes not just connectivity but also whether every tool call can be authorized at runtime with least privilege and full traceability.
Traditional ERP integration boundaries sit at APIs, middleware, and service accounts. With MCP, the boundary shifts to agent-initiated tool calls, where intent and execution happen in fast loops. That shift is the core architectural change described in this ERP-focused MCP analysis.
In practice, this means each tool call becomes a policy decision point, not just a transport event. The system must evaluate actor identity, delegated context, workflow stage, and business sensitivity before allowing the call. This is foundational to ERP AI governance because the risk is no longer only data access, but autonomous action sequencing.
Finance risk is concentrated in actions that move books from draft to committed states. A model that can draft journal suggestions is very different from one that can post entries, release payments, or reverse transactions. Runtime controls must enforce that distinction every time.
HR risk is dominated by personally sensitive records and decision fairness. Reading profile data for analytics may be acceptable; updating compensation, performance outcomes, or employment status is materially different and demands stronger guardrails.
Procurement risk spans supplier fraud, spend leakage, and policy bypass. Agent actions like creating purchase requisitions, modifying vendor master data, or approving exceptions should be authorized against policy and context, not just static role membership.
Payroll risk is uniquely high because errors are immediate and trust-damaging. Drafting payroll inputs is one trust tier; finalizing payroll runs or reversing payouts is another. For least privilege for AI agents, these tiers must be explicit, enforced, and auditable.
The MCP authorization model correctly emphasizes authorization standards and delegated access patterns (spec). In real ERP settings, identity propagation is mandatory so downstream systems know both the initiating user and the acting agent.
Likewise, token scopes and scoped ERP permissions are necessary baseline controls. They reduce coarse overreach and let teams encode intended access boundaries. But scopes are still largely static and resource-oriented, while agentic workflows are contextual and action-oriented.
This gap is significant: an agent can hold a valid scope and still perform the wrong action at the wrong workflow moment. Security best practices for MCP already push toward defense-in-depth (guidance); in ERP, that means adding runtime policy checks per tool invocation and step, plus immutable MCP audit logs for governance and forensics.
A product-agnostic reference architecture for MCP for ERP has five layers. The agent runtime plans tasks and issues MCP tool calls. An authorization gateway intercepts each call, evaluates policy, and returns allow/deny with obligations. ERP connectors execute only authorized actions, while telemetry pipelines store decision and execution evidence.
The policy model should bind subject, delegated principal, tool, action, resource, workflow state, and risk score. This is where policy moves from "can read object X" to "can approve invoice Y only in this stage, under this threshold, for this business unit." It supports cross-vendor control consistency whether the upstream assistant is SAP Joule, Microsoft Dynamics agents, or another copiloting surface.
The trust-level model can be standardized across workflows: read/report, draft/update, approve/post, and delete/reverse. Read/report allows non-mutating access and analytics retrieval. Draft/update permits reversible preparation changes. Approve/post allows commitments to financial or operational records. Delete/reverse is the highest-risk class and should require strict conditional policy, stronger approvals, and elevated logging.
After defining policy semantics, teams need an enforcement plane that operates directly on MCP traffic. Permit MCP Gateway documentation describes this pattern as an authorization control point between agents and MCP tools, with central policy, decisioning, and observability. The product overview is here: Permit MCP Gateway.
The practical value is control-plane consistency: one place to implement runtime authorization logic across heterogeneous ERP tools and agent frameworks. This is especially useful for organizations running mixed landscapes where policy drift is common.
When implemented well, the gateway model strengthens ERP AI governance by making every decision explicit, explainable, and reviewable. It also helps operationalize least privilege for AI agents without rewriting each ERP connector.
The MCP Registry and a runtime authorization gateway solve different problems. Registry services improve discoverability, metadata, and trust signals around available MCP servers and tools. They are important for ecosystem hygiene and onboarding velocity.
But MCP registry vs MCP gateway is not an either/or choice. Registry tells you what exists; runtime authorization decides what may execute now, by whom, under which business constraints. For ERP-grade controls, both are useful, but only runtime authorization can enforce per-call policy and produce decision-linked MCP audit logs aligned to enterprise risk requirements.
The largest shift is from static user-role checks to dynamic, per-action authorization at runtime. Agents do not just view data; they chain decisions into business outcomes. That makes each tool call a potential control boundary that must be evaluated in context.
Scopes are coarse declarations of access intent, not full workflow governance. They usually do not encode stage-specific business risk like "draft allowed, post denied." In agentic systems, that distinction is essential because the same agent may legitimately perform low-risk actions but not high-risk commitments.
Identity propagation carries end-user and agent context through the call path so downstream enforcement can reason about delegation. Without it, systems fall back to opaque service identities, which weakens accountability. It is a prerequisite for trustworthy policy decisions and auditability.
Policy should be enforced at the MCP tool-call layer, before execution reaches ERP mutation endpoints. That placement allows consistent decisions across many tools and workflows. It also enables centralized evidence capture for MCP audit logs.
It means granting only the minimum trust level required for the current workflow step and revoking elevated permissions by default. An agent may read and draft broadly but require explicit conditions for approve/post and delete/reverse. This creates a safer path from assistance to autonomy.
They are orchestration and interaction surfaces where users and agents initiate work. The runtime authorization model sits beneath them and governs what tools can actually execute. That keeps controls consistent even as assistant capabilities evolve.
No, because registry capability is discovery-oriented, not execution-governance oriented. It helps teams know which tools exist and their metadata characteristics. ERP AI governance still requires runtime authorization to approve or block specific actions in real time.
Co-Founder / CEO at Permit.io
