- SAP, Microsoft, Salesforce and other vendors now let AI agents into their systems through MCP, and agent traffic to business software is growing fast. Getting an agent connected to your ERP is no longer the hard part.
- The risk isn't that agents touch your ERP. It's connecting one before you've scoped its identity, its permissions, and what happens when it's wrong.
- Five things need to be true before an agent gets write access to a production system: it has its own identity (not a shared service account), its role is purpose-built and least-privilege, all its traffic runs through a server you control, every tool call is logged somewhere the agent can't touch, and it earned write access in stages instead of getting it on day one.
- Vendor-native MCP servers (SAP, NetSuite, Dynamics 365) handle the standard workflows well. They stop being enough once your ERP configuration is non-standard, your use case spans systems, or you need field-level control the vendor's role model doesn't offer.
A year ago, "connect your AI agent to SAP" meant a custom integration project measured in months. At Sapphire 2026, SAP shipped 200+ specialized agents across finance, spend management, and supply chain as part of what it's calling the Autonomous Enterprise. Microsoft says Dynamics 365 now exposes over 650,000 MCP actions across sales, finance, supply chain, HR, field service, and project operations — the same depth of capability a human user has, now available to an agent.
That's a real shift, and it happened fast. It also means the governance conversation that used to be optional is now the thing standing between a working demo and a production incident. This article is a working checklist for what to verify before an agent gets access to your ERP or CRM through MCP — identity, permissions, architecture, observability, and rollout. If you're still deciding whether you need MCP at all versus a plain REST integration, MCP vs REST API covers that decision first.
Why does MCP governance suddenly matter for ERP and CRM teams?
It matters because agent traffic to enterprise systems went from a rounding error to a real channel in about two quarters. Snowflake's engineering team pulled the numbers straight from August 2026 earnings calls: Datadog reported MCP tool calls up 22x since Q4 2025, quadrupling again quarter over quarter. Figma reported MCP write usage up 75% in a single quarter. Atlassian reported MCP calls up 400% in one quarter, with growth arriving "with barely a blip in people actually using the applications through the web or a mobile client." Salesforce reported sixfold growth in the agentic use of its platform through MCP and CLI calls.
None of that traffic looks like the traffic your security stack was built to watch. A human logging into NetSuite generates a session, a set of clicks, and a predictable rate of activity. An agent generates a burst of tool calls, chosen dynamically based on a prompt, chained across systems, sometimes running unattended overnight. The access pattern is real and growing regardless of whether your team has a governance plan for it.
The good news is that none of what follows is exotic. It's the same discipline enterprise security teams already apply to human users and service accounts: least privilege, audited access, staged rollout. The difference is that most ERP role models were designed assuming a human on the other end, someone who reads a warning dialog and thinks twice. An agent doesn't do that unless you build the equivalent in.
What's the real difference between a native MCP server and a custom one?
A native MCP server is built and maintained by the ERP vendor; a custom one is built around your specific data model and permission requirements, and the choice mostly comes down to how standard your setup is. SAP, Oracle NetSuite, and Microsoft Dynamics 365 all now ship their own MCP servers, and for standard workflows on a standard configuration, they're a reasonable starting point — the vendor has already handled authentication, the basic permission model, and the connection to their own audit trail.
Where native MCP breaks down is the long tail: custom fields, modified data models, industry-specific extensions, or a use case that spans multiple systems (an agent reading from Salesforce and writing to SAP in the same workflow, say). We see this constantly in ERP work generally, not just MCP — reads usually work off the shelf, writes almost never do, because every instance is configured differently. A vendor's native role model can't account for a validation rule your admin added in 2021.
| Approach | Built and maintained by | Best fit | Where it breaks |
|---|---|---|---|
| Native MCP server | The ERP/CRM vendor | Standard workflows, standard configuration, fastest to turn on | Non-standard fields, cross-system workflows, granular field-level control |
| Custom MCP server | You or an integration partner | Non-standard configs, multi-system orchestration, specific compliance needs | Slower to stand up than flipping a vendor setting |
| Third-party connector (Make, Zapier, n8n) | The middleware vendor | Fast prototypes, low-stakes read access | Not built for production write access or enterprise audit requirements |
Most real deployments end up running both: native MCP for the workflows the vendor already covers well, and a custom server for the parts no vendor role model reaches — legacy systems, cross-system logic, field-level restrictions. Custom MCP servers exist for exactly that gap, and build-vs-outsource is worth reading once you know which parts you actually need to build.
How do you stop an agent from acting like a shared admin account?
Give each agent its own identity in your enterprise identity provider, authenticated through user-delegated OAuth, instead of a static API key or a shared service account. This is the single most common governance gap in early deployments: a team wires up an agent with broad credentials during testing, the agent works fine, and in production it's operating with whatever permissions those credentials happen to carry — often admin-level, because nobody scoped them down before go-live.
The June 2026 Enterprise-Managed Authorization extension to the MCP spec formalizes a cleaner version of this: your identity provider becomes the authoritative source for which MCP servers an agent (and the user behind it) can reach, provisioned centrally instead of through a one-off OAuth consent screen per server. Before go-live, confirm the agent authenticates as itself, that its identity ties to a documented role, that credentials rotate on a schedule and live in a secrets manager rather than a config file, and that you can revoke its access immediately if it starts behaving strangely.
How much permission should an agent actually get?
Start from read-only and add write permissions one action at a time, because an agent will use every permission it has and has none of the judgment a human user brings to deciding not to. Least privilege isn't a new idea, but most ERP roles were built for humans who understand context. A role inherited from a human user profile usually carries far more than an agent needs, and an agent doesn't know the difference between "I could do this" and "I should do this."
Set a threshold above which writes need a human to approve before they execute — a purchase order over a set amount, anything touching payroll or banking fields, any change to another user's permissions. We build this as a two-phase pattern on engagements where the risk profile calls for it: the agent prepares the action, a person reviews it, and only then does it commit. We built it that way for an S/4HANA deployment specifically because financial writes into a production ERP warranted it — it's not something we bolt onto every server by default, because plenty of read-heavy or low-stakes workflows don't need the extra step. Decide your own threshold before go-live, not after the first write goes somewhere it shouldn't have.
Where should the MCP server sit in your stack?
All agent traffic to your ERP should route through one MCP server you control, sitting between the agent and the system of record rather than letting agents call APIs directly. A server running on someone's laptop, or one with no boundary between it and your production database, isn't an architecture — it's a demo that got deployed by accident.
Before any write access goes live, point the server at a sandbox, not production data. This is the part that gets skipped most often under deadline pressure, and it's also the cheapest insurance available: a sandbox catches the platform-level mistakes (wrong assumption about a required field, a write chain that skips a step) before they touch a real customer record. It's also worth reviewing what the server logs or caches in transit and whether that needs encryption at rest. If you're on a vendor's native MCP server, read their shared-responsibility model so you know which half of this is actually yours to secure.
What do you need to log to reconstruct what an agent did?
Every tool call needs a timestamp, the agent's identity, the action it took, the parameters it used, and the outcome, stored somewhere the agent itself can't read or modify. An agent you can't observe is an agent you can't trust, and observability is what makes every other item on this list actually verifiable after the fact rather than just in theory.
Set up alerts for the patterns that matter: failed authentication attempts, an agent hitting a permission boundary repeatedly, an unusual volume of actions, or activity outside normal business hours. Assign someone to actually review the logs on a cadence, weekly at minimum for a new deployment, and confirm you can reconstruct a full audit trail for any single action within a day if a compliance team or an auditor asks for one. If you can't do that today, close that gap before you add any more write scope.
Once you run more than a couple of MCP servers, keeping these logs in one place gets hard. An MCP gateway puts every agent's tool calls through a single point, so logging, alerts and access rules live in one place instead of in each server. Best MCP Gateways in 2026 compares the main options.
What's the safest order to roll out write access?
Read-only in a sandbox first, then read-only in production, then narrow write access in a sandbox, then narrow write access in production with approval gates, then expand — and each stage needs to run clean for its full duration before you move to the next one. Teams that get burned almost always skipped a stage because a demo worked and the pressure was on to ship.
A working version of that sequence looks like two weeks of sandbox reads to confirm the agent queries the right data and respects field-level limits, two weeks of production reads to establish a normal baseline for query volume, then a single write action added in the sandbox to test edge cases like invalid input, missing fields, and duplicate records before it goes anywhere near production. Once a narrow write action runs clean in production with human approval on every instance for two weeks, you have a real basis for expanding scope. Document your rollback plan before stage one: you should know exactly how to pull an agent's access within fifteen minutes, not figure it out mid-incident.
When does a vendor's native MCP server stop being enough?
It stops being enough once your configuration, your use case, or your compliance requirements go past what the vendor's role model was built for. That's a non-standard field setup, a workflow that spans multiple systems, a need for field-level access control finer than the vendor's roles support, a data-residency requirement the vendor's hosting doesn't meet, or an internal system, like a legacy database or a proprietary API, that has no vendor MCP server to begin with.
The honest answer to "native or custom" is usually "both, for different parts of the same deployment." We maintain our own sandbox environments for SAP S/4HANA, NetSuite, Dynamics 365, Coupa, Workday, and Salesforce, among others, so we can start building against the actual system on day one rather than spending weeks provisioning access first — and most of the custom MCP servers we build sit specifically in the gap a vendor's native server leaves: the legacy system, the cross-system write, the field the vendor's role model was never built to restrict.
Frequently asked questions
Does this checklist apply if agents only get read access?
Mostly yes, though the stakes are lower. Identity, logging, and rollout sequencing all still matter for read-only agents — an agent with broad read access to payroll or customer PII is a real exposure even if it never writes anything. Permissions and approval gates matter less until write access enters the picture.
What's the single highest-impact change most teams can make?
Move agents off shared service accounts and onto their own identity with user-delegated OAuth scopes. It's the fix that addresses the most common failure mode, an agent operating with broad, inherited permissions nobody scoped down, and it's usually achievable without touching the rest of the architecture.
Do we need a commercial MCP gateway product, or can we build this ourselves?
It depends on how many agents and systems you're governing. A handful of agents against one or two systems is manageable with a well-built custom MCP server and disciplined logging. Governing agent traffic across many systems and many teams at enterprise scale is where a dedicated gateway layer, commercial or internally built, starts to earn its cost. We compare the main products in Best MCP Gateways in 2026.
How is this different from securing a normal API integration?
A traditional API integration is deterministic: the same call, from the same client, hits the same endpoint every time, so a standard API gateway checking authorization and rate limits is enough. An agent chooses which tool to call based on a prompt, chains calls across systems in real time, and can turn an innocuous-looking request into a write, an export, or a deletion. That calls for a control layer that evaluates the specific tool call and its parameters, not just whether the client is allowed to connect.
Should every write action go through human approval?
No — that would make the agent pointless. Reversible, low-risk writes can run autonomously once you've established a track record. The gate belongs on writes that are hard to undo or carry real financial or compliance weight: large purchase orders, payroll changes, anything touching banking details. Decide the threshold in advance, not after something slips through.
Can a vendor's native MCP server (SAP, Dynamics 365, NetSuite) cover all of this on its own?
For standard workflows on a standard configuration, mostly yes — the vendor has already solved authentication and the basic permission model. It runs out of road once your setup is non-standard, your workflow spans multiple systems, or you need field-level control finer than the vendor's built-in roles.
How long does it take to get from zero to a governed deployment?
The five-stage rollout in this article runs about eight weeks end to end for a single write action, assuming each stage completes cleanly. Scoping and building the MCP server itself is usually faster: a well-scoped server can be built and delivered in 1–2 weeks with an experienced team working against a real sandbox. The staged rollout is what earns write access safely, and skipping stages is exactly how teams get burned.
What happens if we skip the sandbox phase?
You find out about a misconfigured field, a missing validation rule, or an unexpected write chain on a real customer's data instead of a disposable environment. Sandbox testing is the cheapest stage in this entire process, and it's also the one under the most pressure to get cut when a deadline is close.
Does MCP work without an AI agent behind it?
Not really — the protocol assumes an LLM is the thing deciding which tool to call and why. If you don't have an agent in the loop, a traditional REST API is almost always the better fit; wiring up MCP for a deterministic, non-agentic workflow adds governance overhead for no real benefit.