MCP and Enterprise Systems: Standardizing AI Access to ERP

Fourteen months ago, connecting an assistant to an enterprise system meant writing a bespoke integration for each pairing: this model, that application, one set of credentials, one set of permissions, one piece of code nobody else could reuse. The Model Context Protocol, published by Anthropic at the end of 2023 and now picking up support across the major model providers and development tools, proposes a different arrangement. Expose your system once, as a server. Any compliant client can use it. For anyone responsible for an enterprise resource planning system, the interesting part is not the protocol. It is that the protocol makes the access question explicit for the first time.

The integration problem was never the hard part. The hard part was deciding what an assistant is allowed to do in your system of record, and a standard interface does not answer that

It does, however, force you to write the answer down — which is an improvement on the current arrangement.

What the standard actually does

It defines how a client discovers what a server can do, how it calls those capabilities, and how results come back. Concretely, your finance system exposes a set of named operations — look up an invoice, list open purchase orders, check stock — with described parameters, and the assistant chooses among them. The practical consequence is that integration effort drops substantially and becomes reusable. The strategic consequence is that the same interface will be usable by tools you have not chosen yet, which is both the benefit and the risk.

Read and write are entirely different decisions

Almost every organisation should start with read-only access, and many should stay there through this year. Read access converts your system from something people navigate into something they can question, which is a genuine productivity change for occasional users — executives, field staff, account managers who never learned the screens. The failure mode is an inaccurate answer, which is recoverable. Write access converts it into something that can be changed by a model interpreting a sentence. The failure mode is a transaction. Those are not the same category of decision and they should not be made in the same meeting.

Three design rules that matter more than the protocol

Expose operations, not tables. A tool called "query the database" is a security problem with a friendly name. A tool called "get invoice status by number" has defined inputs, defined outputs and a defined blast radius. Design the surface deliberately and keep it small. Carry the user's identity through. The most common implementation error is connecting with a service account that has broad permissions, which means every user inherits the maximum. The assistant must act as the person asking, with that person's permissions, or your access control has been quietly replaced. Log the call, not just the result. Record which tool was invoked, with what parameters, on whose behalf, and what came back. Without that, you cannot answer the only question that matters after an incident.

What to do this quarter

Find out whether your vendors have published servers or have them on the roadmap, because this is moving quickly and you do not want to build what will ship. Pick one read-only use case with a real user population. Write down the operation list before anyone implements it. And settle the identity question before the first connection, because retrofitting per-user permissions onto a service-account integration is a rebuild rather than a change.

Practical Guidance for AI Integration Architecture Review

• Separate the read decision from the write decision entirely.
• Design a small, named operation surface rather than generic query access.
• Pass the user's identity through to the underlying system.
• Log invocations, including parameters and the acting user.
• Ask vendors for their roadmap before building your own server.
• Rate-limit and bound every operation you expose.
• Start with one population that struggles with the existing screens.
• Review the operation list quarterly as usage patterns emerge.

The Regional Angle

The first consideration is that a standard access layer changes the language question in a way regional organisations should exploit early. A very large proportion of staff in Gulf operations — warehouse supervisors, site foremen, drivers, retail managers — have never been trained on the enterprise system and never will be, and the information they need is simple: is this order approved, has this delivery been received, what is the balance on this account. An interface that accepts a question in Arabic, Hindi, Urdu or Tagalog and returns a bounded factual answer from the system of record is more valuable here than in a market with uniform language and uniform system training. Start with read-only lookups for exactly that population and measure how many phone calls to the office disappear. The second is a permissions problem regional groups will hit immediately. Access in a group structure is usually organised per entity and per system, and it is common for the same person to have different rights in different operating companies, with the boundaries maintained by long-standing local arrangements rather than by a coherent group model. Route all of that through one assistant interface and the inconsistencies become visible and, worse, exploitable — a user who cannot see another entity's data in the application may find that the integration's service account can. Before connecting anything, check that the identity flowing through the protocol resolves to the same entity-level restrictions the application enforces. If your entity separation is enforced by separate logins rather than by roles, that is a project you need to complete first. The third concerns the vendor landscape as it applies here. Many regional organisations run localised or partner-modified builds of their enterprise systems — a globally supported product with country-specific modules, or a local product entirely — and those builds will be slower to receive standard connectors than the vendor's flagship cloud edition. That creates a real choice: wait, or have your partner build a server against the operations you care about. Building one is genuinely modest work for a defined read-only surface, and the constraint is not engineering but whether your support agreement permits it and who owns the code afterwards. Settle that in the contract before the work starts, because a partner-built integration you cannot maintain is a dependency, not an asset.

The objection worth taking seriously

The strongest objection is that this is a protocol without a track record being wired into systems of record. It is barely a year old, the specification is still moving, the security model is young enough that serious analysis is only now appearing, and the industry's enthusiasm is running well ahead of any deployed experience at scale. Connecting a standards-based interface to the general ledger on that basis is a reasonable way to acquire a vulnerability class nobody has named yet, and the conservative course is to wait eighteen months and let other organisations find the failures. That caution is justified for write access, and anyone exposing transactional operations this year should expect to be an early case study. Where it overreaches is in treating the alternative as safe. The alternative is not the absence of assistant access to enterprise data; it is the current arrangement, in which individual teams build point integrations with service accounts and broad permissions because there was no standard way to do it properly. Those integrations already exist in most organisations, they are undocumented, and their permissions are worse than anything a deliberate server design would produce. A standard interface does not create the exposure. It creates the first opportunity to inventory it, bound it, and log it. Adopt it for read, design it carefully, and let someone else prove the write path.

Common Questions

Does this replace our existing integrations?

Not the high-volume, system-to-system ones, which remain better served by conventional interfaces. This addresses the assistant-to-system case, which was previously handled badly or not at all.

Is a read-only connection safe?

Safer, not safe. Bound what each operation can return, pass user identity through, and remember that a model can combine several small permitted answers into something a person was not meant to assemble.

Should we wait for our vendor?

For the core system, usually yes, if the roadmap is credible and dated. For a peripheral system with a stable interface, building your own is reasonable.

What should we expect over the next twelve months?

Expect broad client support across the major assistants and development tools to become the default assumption. Expect the first significant security research into protocol implementations, and expect it to find permission and identity handling rather than the protocol itself. Expect enterprise vendors to ship official servers with deliberately conservative operation lists. And expect the write-access question to be the governance argument of the second half of the year.

---

AI Integration Architecture Review — we design the operation surface and the identity path before anything is connected to your system of record.