Building an MCP server for enterprise data takes 2-4 weeks once OAuth 2.1 authorization, tool-level Read, Write, and Admin scoping, and audit-trail design are treated as requirements, not afterthoughts. Nexla now pitches “governed MCP servers,” and Atlan’s own hosted MCP server already enforces per-user OAuth identity passthrough, evidence the market agrees an MCP server is a new trust boundary, not a protocol adapter. This guide covers that boundary: scoping, the token-passthrough anti-pattern the Model Context Protocol specification bans, and the audit-trail architecture that closes it.
| Time to complete | 2-4 weeks (single domain, existing IdP) to 4-8 weeks (multi-source) |
| Difficulty level | Advanced. Identity and auth engineering plus governance coordination |
| Prerequisites | Existing IdP/SSO, a policy engine or RBAC/ABAC model, a governed context source, a named tool-scoping owner |
Why build an MCP server for enterprise data?
Permalink to “Why build an MCP server for enterprise data?”Generic MCP tutorials cover SDK mechanics but treat “add authentication” as a footnote. Cargill’s own security team raised the access-boundary question directly: could an agent’s query “go down into minerva and create a query off of information that is outside of its bounds”? No competitor content shows the concrete patterns that answer it, though CVE-2026-48526, the first public CVE in the MCP servers stack, and Nexla’s “governed MCP servers” pitch, confirm this is becoming a distinct buying concern.
Teams with an existing IdP and RBAC/ABAC model are ready to start now; others should resolve identity and policy ownership first, since tool-level access control needs an authorization model to bind to. Local versus remote deployment changes what a gateway can enforce. See what the Model Context Protocol is and when to use MCP vs. an API for adjacent questions. The access model a server enforces is only as good as the context feeding it.
What do you need before building an MCP server for enterprise data?
Permalink to “What do you need before building an MCP server for enterprise data?”| Prerequisite | Why it matters |
|---|---|
| Existing IdP/SSO with OAuth 2.1 | Mandatory once a server implements HTTP-transport auth. |
| A policy engine or RBAC/ABAC model | Tool scoping needs a model to bind to, not a green-field one. |
| A governed catalog or context source | Without one, the server exposes raw connectors, Cargill’s exact concern. |
| Executive sponsorship and a named tool-scoping owner | Budget and a business judgment call, the same reason AI agent identity and AI agent governance need named owners. |
Team and time: a project lead, security engineer, platform engineer, and governance reviewer, 2-4 weeks single-domain, 4-8 multi-source. Skip these and the build ships an ungoverned floor underneath a protocol that looks governed.
Still mapping vocabulary before you scope tools?
The CIO's Guide to Context Graphs walks through how enterprise teams turn scattered definitions into one shared, queryable context model before wiring up access control.
Get the CIO Context Guide
The enterprise MCP trust boundary flow. Source: Atlan.
Step 1: Choose your transport and scope the server
Permalink to “Step 1: Choose your transport and scope the server”What you’ll accomplish: Pick a transport for the deployment model and scope one data domain.
Time required: 3-5 days
- Choose transport based on deployment: STDIO for local, single-user tools (inherits local credentials, no OAuth) vs. Streamable HTTP for anything shared or remote (requires OAuth 2.1); this changes what a gateway in front of the server can enforce.
- Scope to one data domain first, not the whole estate, mirroring the over-modeling failure mode teams hit building a knowledge graph for AI agents.
- Identify who owns tool-scoping decisions for this domain, a security and business call, not engineering alone.
Validation checklist:
- [ ] Transport choice documented and justified against deployment model
- [ ] Domain boundary agreed with security and data owners
- [ ] Tool-scoping owner named
Step 2: Implement OAuth 2.1 and PKCE authorization
Permalink to “Step 2: Implement OAuth 2.1 and PKCE authorization”What you’ll accomplish: Wire per-user OAuth 2.1/PKCE and reject the token-passthrough anti-pattern the spec bans.
Time required: 1-2 weeks
- Implement OAuth 2.1 with PKCE for the HTTP transport, the mandated mechanism with no substitute accepted, using a purpose-built library like giantswarm/mcp-oauth.
- Publish OAuth Protected Resource Metadata at
/.well-known/oauth-protected-resourceper RFC 9728 for client auto-discovery. - Bind the token to the signed-in user’s existing identity, not a shared service-account token, the exact assurance Cargill asked for: “I assume that any use of MCP or otherwise would honor that security already set up in Atlan, right?”, where AI agent identity and MCP authorization must agree.
- Reject token passthrough entirely, the specialized case of giving AI agents access to enterprise data covered under Pitfall 2 below.
Validation checklist:
- [ ] OAuth 2.1 with PKCE implemented for HTTP transport
- [ ] Protected Resource Metadata published and discoverable
- [ ] Token bound to per-user identity, not a shared credential
- [ ] Token-passthrough pattern explicitly tested against and rejected
Step 3: Define tools with Read, Write, and Admin scoping
Permalink to “Step 3: Define tools with Read, Write, and Admin scoping”What you’ll accomplish: Tag every tool with an access level and ship a read-only mode.
Time required: 3-5 days
| Tool category | Access level |
|---|---|
| Search and discovery | Read |
| Lineage and impact analysis | Read |
| Glossary and classification lookup | Read |
| Glossary and classification edits | Write |
| Quality and monitoring | Read |
| Lifecycle and workflow actions | Admin |
- Inventory every tool and assign one access level each. Server-level allowlists are, per r/mcp consensus, “too broad to serve as effective approvals,” the same principle behind zero-trust data governance.
- Ship read-only mode as a first-class option so risk-averse teams adopt discovery and read use cases first, matching Medtronic’s rollout.
- Avoid “full schema dump” tools in favor of narrow, on-demand ones; a governed data catalog makes that possible.
Validation checklist:
- [ ] Every tool tagged with Read, Write, or Admin
- [ ] Read-only mode implemented and tested
- [ ] No full-schema-dump tools shipped without a narrower alternative
Step 4: Wire resources to a governed context source
Permalink to “Step 4: Wire resources to a governed context source”What you’ll accomplish: Close the gap Cargill raised about a query reaching “outside its bounds.”
Time required: 1 week
- Back resources with a governed catalog or context source, not a raw-connector pass-through, since a raw connector has no permission model of its own, true even for an MCP server for dbt.
- Scope the claim precisely: metadata or context-level access, or true row and column security, don’t conflate the two, a distinction that matters as much for a semantic layer as an MCP resource.
- Decide where enforcement sits: local server, remote server, or a gateway in front of both, the boundary a context graph resolves for any consumer.
Validation checklist:
- [ ] Resources backed by a governed context source, not raw connectors
- [ ] Permission-inheritance claim scoped accurately to what’s enforced
- [ ] Enforcement boundary (local, remote, or gateway) documented
Not sure how mature your context layer actually is?
Run the Context Maturity Assessment before you scope Read, Write, and Admin tools. It flags where governed context ends and raw connectors begin.
Take the AssessmentStep 5: Build the audit-log pipeline and validate least privilege
Permalink to “Step 5: Build the audit-log pipeline and validate least privilege”What you’ll accomplish: Close the audit-trail gap real customers have flagged (see below).
Time required: 3-5 days
Audit-log schema fields: user identity, tool called, data object or resource accessed, invoking agent, purpose or context, result, timestamp.
- Log the full schema above for every tool call, not just errors or write actions.
- Test least-privilege enforcement directly: attempt an out-of-scope call with a read-only token and confirm it’s rejected.
- Route logs to a queryable pipeline, not flat files, so “who touched X” is answerable in minutes, using a proxy pattern like atrawog/mcp-oauth-gateway.
This is also where MCP and data lineage intersect: a log that can’t trace a call to a data object is a request log, not an audit trail, the reasoning root-cause analysis with MCP-delivered lineage depends on.
Validation checklist:
- [ ] Every tool call logged with the full field set
- [ ] Out-of-scope calls tested and confirmed rejected
- [ ] Audit log is queryable by user, tool, and data object, not just append-only text
What goes wrong when building MCP servers for enterprise data?
Permalink to “What goes wrong when building MCP servers for enterprise data?”Pitfall 1: Treating server-level allowlists as sufficient access control
Permalink to “Pitfall 1: Treating server-level allowlists as sufficient access control”Server-level gating looks secure until someone asks what a tool can reach. Tag every tool with Read, Write, or Admin from day one instead.
Pitfall 2: Forwarding the user’s raw token to downstream APIs (token passthrough)
Permalink to “Pitfall 2: Forwarding the user’s raw token to downstream APIs (token passthrough)”It’s the shortest path to “it works,” but mint a new, audience-scoped token per call instead; the spec bans passthrough for breaking audience validation and enabling confused-deputy attacks, the same failure class prompt-injection attacks exploit differently, and why data privacy for AI agents treats token scope as first-class.
Pitfall 3: Shipping “full schema dump” tools instead of narrow, scoped ones
Permalink to “Pitfall 3: Shipping “full schema dump” tools instead of narrow, scoped ones”Replace dump-style tools with narrow, on-demand tools, expanding only when a real use case demands more.
Pitfall 4: Skipping the gateway or proxy layer for centralized logging and identity binding
Permalink to “Pitfall 4: Skipping the gateway or proxy layer for centralized logging and identity binding”A gateway feels like extra infrastructure when the server “already has auth.” Put one in front instead, the reasoning behind AI agent guardrails checklists: centralize enforcement, don’t scatter it.
Each traces to one root cause: treating MCP as a protocol adapter, not a trust boundary. Toyota Industries EU’s black-box concern is the sharpest version of Pitfall 4, covered below.
Best practices for building MCP servers for enterprise data
Permalink to “Best practices for building MCP servers for enterprise data”- Default new deployments to read-only mode until a team requests write access, matching Medtronic’s rollout.
- Treat local-vs-remote transport as a security decision, since it determines what a gateway can enforce.
- Adopt a gateway or proxy layer for centralized logging, the most consistent pattern across Reddit r/mcp threads.
- Pin dependency versions and scan before production, the same discipline that patched CVE-2026-48526; punkpeye/awesome-mcp-servers is a reasonable vetting start.
- Scope permission-inheritance claims precisely: what’s proven (metadata or context access) versus what isn’t (native row and column security), the same discipline AI agent governance and AI agent guardrails and risks apply to any access-control claim.
Teams getting this right aren’t solving an MCP problem; they’re extending the same governed context that exists elsewhere in the stack into a new protocol.
How does Atlan approach MCP server governance?
Permalink to “How does Atlan approach MCP server governance?”Manual MCP deployments often gate access only at the server level. Toyota Industries EU has not turned on MCP access to some systems because it “feels like a black box, no audit trail of what was updated, by whom, or by which agent.”
Atlan’s own MCP server is a hosted, per-tenant Remote server where every call runs under per-user OAuth and inherits permissions already configured in Atlan, evidenced for metadata and context-level access, not as a generic row or column-level broker end to end. Docs describe 29 tools across eight categories, each tagged Read, Write, or Admin, with read-only mode. The Context Lakehouse stores context with versioning and time-travel; the Context Engineering Studio logs the question, context, and response with a draft-review-approve-deploy trail, aimed at this gap, not yet closed.
Medtronic is live on this server inside “Medtronic GPT,” scoped to discovery and read, write and create off. Fennia paused MCP to narrow sign-in to its company domain, an access-control pause, not an incident, proving per-user OAuth and tool-level scoping today; a universal mutation-audit guarantee is the direction, not a closed case.
Want to see per-user access control in action?
Watch Atlan's live Context Layer demo series to see how OAuth-scoped MCP tool calls, read-only mode, and audit trails actually work end to end.
Watch the Demo SeriesReal stories from real customers: MCP servers built on governed context
Permalink to “Real stories from real customers: MCP servers built on governed context”Workday and DigiKey describe what a governed context layer underneath MCP looks like in practice.
"We're excited to build the future of AI governance with Atlan. All of the work that we did to get to a shared language at Workday can be leveraged by AI via Atlan's MCP server…as part of Atlan's AI Labs, we're co-building the semantic layer that AI needs with new constructs, like context products."
— Joe DosSantos, VP of Enterprise Data & Analytics, Workday
"Atlan is much more than a catalog of catalogs. It's more of a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models."
— Sridher Arumugham, Chief Data & Analytics Officer, DigiKey
Why the trust boundary matters more than the protocol
Permalink to “Why the trust boundary matters more than the protocol”An MCP server sits at the seam between the AI Control Plane and the Context Layer beneath it. Every claim it makes about access, and every line in its audit log, depends on the context underneath: a governed catalog, a context graph that has already disambiguated what a term means, and an enterprise context layer that knows who is allowed to see what before any tool call happens.
Once live, measure success by out-of-scope-call rejection rate and audit-log query latency, not uptime, expanding coverage gradually and revisiting the local-vs-remote decision as adoption grows.
The generic build mechanics this page didn’t re-cover, SDK setup, transport code, schema definition, live in the MCP Server Implementation Guide. Once the delivery layer is governed, the next floor up is the AI Control Plane itself, only as trustworthy as the context feeding it, and teams that have done this for MCP often find implementing an enterprise context layer for AI elsewhere a smaller lift than expected.
FAQs about building MCP servers for enterprise data
Permalink to “FAQs about building MCP servers for enterprise data”1. How long does it take to build an MCP server for enterprise data?
Permalink to “1. How long does it take to build an MCP server for enterprise data?”A single-domain deployment with an existing IdP typically takes 2-4 weeks; multi-source deployments needing a new policy engine can run 4-8 weeks.
2. Do I need a dedicated security or identity team to build an MCP server?
Permalink to “2. Do I need a dedicated security or identity team to build an MCP server?”Yes: at minimum an identity engineer for OAuth 2.1/PKCE and a named tool-scoping owner, a business judgment, not a pure engineering task.
3. How do I implement OAuth 2.1 and PKCE for an MCP server?
Permalink to “3. How do I implement OAuth 2.1 and PKCE for an MCP server?”The spec leaves authorization optional but mandates OAuth 2.1 with PKCE for HTTP transports once implemented, plus OAuth Protected Resource Metadata per RFC 9728 for auto-discovery.
4. Can I run an MCP server on-premises instead of exposing it remotely?
Permalink to “4. Can I run an MCP server on-premises instead of exposing it remotely?”Yes. STDIO transport suits local, single-user deployments and skips OAuth; a remote deployment centralizes identity binding and logging more easily.
5. Does OpenAI support the Model Context Protocol, or is it Claude-only?
Permalink to “5. Does OpenAI support the Model Context Protocol, or is it Claude-only?”MCP is an open specification, authored by Anthropic and now governed by the Agentic AI Foundation under the Linux Foundation, not Claude-exclusive. Adoption varies by client, so confirm current support first.
6. How do I prevent prompt injection and token-passthrough vulnerabilities in MCP tools?
Permalink to “6. How do I prevent prompt injection and token-passthrough vulnerabilities in MCP tools?”For passthrough, never forward a raw token unchanged; mint a new, audience-scoped token per call. For injection, scope tools narrowly, validate inputs against a schema, and log every call.
Sources
Permalink to “Sources”- Model Context Protocol Specification, Anthropic: https://github.com/modelcontextprotocol/modelcontextprotocol
- modelcontextprotocol/servers, official reference server implementations: https://github.com/modelcontextprotocol/servers
- modelcontextprotocol/typescript-sdk, official TypeScript SDK: https://github.com/modelcontextprotocol/typescript-sdk
- modelcontextprotocol/python-sdk, official Python SDK: https://github.com/modelcontextprotocol/python-sdk
- modelcontextprotocol/go-sdk, official Go SDK: https://github.com/modelcontextprotocol/go-sdk
- Cerbos, open-source policy-as-code engine: https://github.com/cerbos/cerbos
- giantswarm/mcp-oauth, OAuth 2.1 authorization server library for MCP: https://github.com/giantswarm/mcp-oauth
- atrawog/mcp-oauth-gateway, OAuth and logging proxy pattern for MCP servers: https://github.com/atrawog/mcp-oauth-gateway
- punkpeye/awesome-mcp-servers, community discovery index for MCP connectors: https://github.com/punkpeye/awesome-mcp-servers
