Connecting an AI agent to an ERP is no longer only a prototype exercise. Major business-software platforms are exposing more data and business logic to agents, while the Model Context Protocol (MCP) is evolving into a common way for AI applications to discover and call tools. That makes integration easier, but it does not remove the need for ordinary business controls.

The practical design question is not “MCP or API?” It is: what may the agent see, what may it propose, what may it execute, which system remains authoritative, and how will the business verify the outcome? Those decisions matter more than the transport used to connect the model to the ERP.

What changed in 2026

MCP has moved quickly from a developer integration pattern toward infrastructure that is relevant to business systems. The MCP maintainers released specification version 2026-07-28 with a stateless protocol core, header-based routing, cacheable tool listings and authorization hardening. The project's August 2026 roadmap also puts agent identity, enterprise security and HTTP-native transport hardening among the next priorities.

At the same time, ERP vendors are exposing agent-facing integration surfaces. Microsoft's Dynamics 365 finance and operations roadmap lists an ERP MCP server that can expose business data and logic to agents, along with 2026 features for agent orchestration and attachment access. This is a concrete signal that agent-to-ERP integration is moving closer to normal enterprise architecture.

None of this means a business should grant an AI agent broad ERP access by default. Better connectivity increases the importance of permissions, policy and auditability because the agent can potentially reach more useful — and more sensitive — functions.

MCP and APIs solve different parts of the problem

An API is the underlying contract through which software reads data or performs an operation. MCP can sit above tools and APIs to give an AI client a standardized way to discover capabilities and call them. In many real deployments, an MCP server will still use ordinary vendor APIs, database services or application logic underneath.

That distinction matters because MCP should not become a shortcut around the controls already present in the ERP. If the existing purchasing API checks supplier status, role permissions and approval thresholds, the agent-facing tool should preserve those checks rather than write directly to a database table.

  • Use native ERP APIs and business services for authoritative transactions and vendor-supported validation.
  • Use MCP where it improves agent interoperability, tool discovery or access to a controlled set of business capabilities.
  • Keep deterministic policy outside the model so spending limits, role checks and prohibited actions are not dependent on prompt wording.

Start with read, reason and recommend

The safest first integration usually gives the agent enough access to understand a workflow without giving it unrestricted authority to change records. For example, a collections agent might read invoice status, customer history and previous follow-ups, then prepare a ranked action list and draft reminder messages.

A purchasing agent might read open purchase orders, expected delivery dates and stock exceptions, then surface delayed items and prepare supplier follow-ups. An accounts-payable assistant might extract invoice fields, compare them with purchase records and flag mismatches for review.

These patterns create value because they remove search and preparation work. They also let the company measure accuracy before granting the agent permission to perform consequential actions.

Give the agent a business identity, not a master key

NIST's 2026 concept paper on software and AI-agent identity highlights a core problem: agents can access multiple datasets, tools and applications, so organizations need appropriate identification and authorization controls. That is directly relevant to ERP integration.

Treat each agent as a bounded software identity with a defined role. A receivables assistant should not automatically inherit the permissions of a finance administrator. A sales agent should not be able to modify bank details merely because both functions live in the same ERP.

  • Give each agent only the data and tools required for its job.
  • Separate read permissions from write permissions.
  • Use task-specific scopes instead of broad “ERP access.”
  • Make sensitive operations require stronger authorization or explicit approval.
  • Revoke access centrally when the workflow or agent is retired.

The MCP authorization model itself has been tightening. Its current documentation emphasizes audience-bound tokens, OAuth-based authorization and least-privilege scopes, while the newer enterprise-managed authorization extension is designed to let organizations centralize MCP access policy through their identity provider.

Do not let the model become the policy engine

A model can help interpret messy context, but important business rules should be checked by normal application logic. Suppose an agent recommends issuing a supplier payment. The recommendation may be reasonable, but the transaction should still pass deterministic checks such as approved vendor status, invoice match, payment limit, duplicate-payment detection and the user's authorization level.

The model can explain why it recommends an action. The policy layer decides whether that action is allowed. The ERP or transactional service performs it. This separation makes failures easier to contain and gives auditors a much clearer answer to “why was this action permitted?”

This is the same architecture described in our guide to AI workflows with human approval: AI reasons, policy constrains, people approve where necessary, deterministic software executes and the system verifies the result.

A practical permission ladder for ERP agents

You do not need to choose between “chatbot” and “fully autonomous.” A better approach is to increase authority by workflow.

  • Level 0 — Read only: search, summarize and explain ERP state.
  • Level 1 — Prepare: draft messages, forms, reconciliations or recommended actions.
  • Level 2 — Execute after approval: create or update a bounded transaction only after a named person approves it.
  • Level 3 — Bounded automation: automatically perform low-risk actions that pass deterministic policy checks.
  • Restricted: block actions such as changing bank details, releasing high-value payments or altering sensitive financial controls unless handled through a separately governed process.

The correct level can differ inside the same agent. It may automatically tag a document, require approval before sending a customer message and be prohibited from releasing a payment.

Log the evidence, not only the final action

ERP auditability should extend to the agent workflow. A useful log records what triggered the run, which business records and tools were accessed, the recommendation produced, the policy decision, who approved it, the exact action requested and whether execution succeeded.

Microsoft's current Dynamics 365 agent-management documentation includes an agent activity view specifically for tracking agent interactions and task completion. That reflects an important architectural principle: an autonomous action without a usable activity history is difficult to govern.

Verification also matters. If an ERP API rejects a request or a downstream message fails, the agent should not mark the task complete simply because it attempted the action. The workflow should check the actual system response and surface failures as exceptions.

When MCP is worth adding

MCP is most useful when you expect multiple AI clients, models or agent frameworks to work with the same controlled business tools, or when you want a consistent interface for tool discovery and authorization. It can reduce bespoke integration work at the AI layer.

It is less compelling when one narrow workflow already has a stable first-party API integration and no need for agent interoperability. Adding another protocol layer does not automatically create business value.

For a small business, this usually means starting with the workflow and existing software capabilities first. Do not deploy MCP merely because it is current. Add it when it simplifies a real integration architecture or gives you a governed way to reuse business tools across agents.

A six-step implementation checklist

  • 1. Choose one workflow. Define the trigger, current manual work and measurable outcome.
  • 2. Identify the system of record. Decide which ERP, CRM or accounting system remains authoritative.
  • 3. Define the agent's identity and scopes. List exactly what it may read and what it may request.
  • 4. Put policy between reasoning and execution. Encode approval thresholds and prohibited actions outside the model.
  • 5. Log and verify every consequential action. Record evidence, approval and the final system response.
  • 6. Increase autonomy only from measured evidence. Expand permissions after the workflow demonstrates acceptable accuracy and failure handling.

If you are still deciding whether a workflow is ready for AI, use the AI Opportunity & Readiness Audit. For a broader architecture view, see what an AI operating system for business means and our AI + ERP automation guide.

Sources checked

This article was researched against current first-party and standards sources on 25 August 2026. Protocol specifications and vendor roadmaps can change, so verify the current release and product documentation before implementation.

Editorial & commercial disclosure

Renvoriq Technology publishes original educational analysis about business AI and operations. Renvoriq may offer technology or implementation services related to the topics discussed. No vendor or standards body paid for or reviewed this article. Product and protocol references are included for technical context, not as endorsements. Renvoriq product references describe technology direction unless explicitly stated otherwise.