MCP servers for enterprise systems: how to build, secure and govern them

This guide is for engineering leads, architects and IT governance owners at a mid-market company who are asked to let an AI agent or assistant call an existing ERP, CRM or finance system, once agent architecture itself is decided (the agentic AI architecture guide covers checkpoint placement; this page is the connection layer underneath it). It is delivered through agentic AI automation.

In this guide

• What should an MCP server expose from an enterprise system?
• The three-tier exposure matrix
• Securing the server: identity, scope and the gateway
• Governing MCP at scale: registry, review and revocation
• A sequencing plan for standing up an MCP server
• Where AI fits in building an MCP server
• What delivery record exists, and what does not
• Alternatives: who builds and runs the MCP layer
• Limits of this guide
• Frequently asked questions
• Next step

What should an MCP server expose from an enterprise system?

Expose the smallest set of named actions the agent's job requires, never a generic pass-through to the ERP, CRM or finance API. A get_invoice_status or list_open_orders tool is a deliberate, typed, auditable function; a tool that forwards arbitrary SQL or an unscoped REST call is not an MCP tool, it is the whole API with extra steps, inheriting every risk of the system behind it.

The three-tier exposure matrix

Sort every candidate ERP, CRM or finance action into one of three tiers before any tool is built. The tier, not the system it touches, decides the approval rule.

Most first MCP servers over-scope the write tier: a create_order tool that also accepts a discount percentage hands the agent authority nobody reviewed. Name a tool's fields as narrowly as the job needs, not as broadly as the API allows.

Securing the server: identity, scope and the gateway

The Model Context Protocol's authorization specification places the MCP server in the OAuth 2.1 resource server role: it accepts bearer tokens, validates that each token was issued specifically for it, and rejects a token scoped to a different server, the audience-binding requirement OAuth 2.0 Resource Indicators (RFC 8707) define. Three choices follow.

• Authenticate through the company's own identity provider, never a static shared API key, so a token ties to the calling agent's own identity and a later audit or revocation is possible at all.
• Scope every token to the narrowest set of tools it needs. A token that can call every tool on the server defeats the three-tier matrix above; grant scopes per tool or per tool group, per the specification's own least-privilege guidance.
• Put a gateway in front of more than one MCP server. Once a second server exists, one enforcement point for authentication, rate limiting and logging is simpler to secure and audit than securing each server natively.

Netbase secures this the way it secures anything else it builds: TLS in transit, role-based access control, MFA on any dashboard that can approve a write tool, and the ISO 27001 and SOC 2 Type II frameworks and the GDPR, HIPAA-aligned and CCPA practices it already applies to its own delivery.

Governing MCP at scale: registry, review and revocation

Governance starts before the second tool ships, not after the tenth. Keep a registry of every MCP server, every tool it exposes, and every agent or caller connected to it: without that catalog there is nothing to review, and a connection nobody remembers exists is a connection nobody revokes. A published MCP governance framework treats this registry, with least-privilege scopes and automated credential rotation, as the core of enterprise-scale MCP governance.

Three practices keep the registry useful:

1. Log every call with the caller's identity, the tool name, the arguments, and whether it was auto-approved or escalated, so a disputed write traces back to the call that made it.
2. Review connections on a schedule, the way an access review covers any other system account, and revoke what nobody can justify.
3. Keep a working kill switch. Revoking a token or disabling a tool should take one action, not a deployment.

What delivery record exists, and what does not

Netbase has built the kind of system an MCP server sits in front of, and has delivered AI projects that call defined actions against one, though not yet the two together on one project:

• Multi-tenant cloud ERP for a US client (not named). Since 2020, offshore development and managing partner on a cloud ERP delivered as SaaS; phase 1 covers CRM, a knowledge base, work and project management and API integrations, the surface an MCP tool catalog would draw its first read-only tools from.
• ERP and CRM consultancy (not named). Odoo consultancy and customisation, e-commerce-to-ERP integrations that synchronise catalogues, inventory, orders and customer data by API, and a Vtiger-to-ERP upgrade; each is the kind of defined, bounded action an MCP tool wraps, not a raw database connection.
• A WhatsApp AI chatbot with CRM sync (not named). An agent reading and writing CRM data on a defined action set, delivered before MCP was the calling convention for it.
• Delivered AI beyond these, anonymised: retrieval-augmented knowledge assistants, document AI and MLOps pipelines for clients not named here.

What does not exist. No published Netbase record describes a delivered MCP server, a published tool registry, or an agent calling a client's ERP, CRM or finance system through MCP. The matrix and sequencing plan above come from Netbase's ERP/CRM integration and agent-facing delivery practice and the cited sources, not one measured MCP project; no duration, cost, accuracy or adoption figure is claimed.

Alternatives: who builds and runs the MCP layer

When not to build one yet. A single internal script with one caller and no plan for a second agent rarely needs a protocol, a registry or a gateway; the overhead buys interoperability a one-caller integration does not use. Build toward MCP once a second agent, assistant or partner needs the same tool surface.

In Netbase custom development the client owns the IP created for it, and most projects run on fixed-price contracts agreed after discovery. The underlying API work sits in systems and API integration and ERP and CRM development, the agent-facing layer in AI integration, delivered through agentic AI automation and the enterprise AI agent platform, for sectors such as professional services where ERP, CRM and finance data sit behind the same approval questions.

Limits of this guide

• MCP's specification is young and revises often; check it before building an authorization flow against it.
• The three-tier matrix and sequencing plan are a starting design, not a guarantee that any given tool is safe for your system.
• No duration, cost, accuracy or adoption figure is claimed; real numbers depend on your own systems and call volume.
• Scoping, logging and a registry reduce risk; they do not remove the need to review an unusual write, as OWASP's guidance on excessive agency recommends.

Next step

Tell us which ERP, CRM or finance actions you want an agent to call, and we will book a solution review to scope the exposure matrix, the authentication model and the registry around them. You can also see the agentic AI automation service or browse more Netbase insights.

Related services and solutions