Connecting AI agents to internal systems without shadow AI
August 21, 2026
Security teams are no longer debating whether AI agents are coming. They are debating what those agents are allowed to touch. Meanwhile, people already paste CRM notes, tickets, and documents into ChatGPT because the approved assistant cannot see internal systems. That gap — stalled rollout on one side, shadow AI on the other — is the forcing function for custom MCP development.
Off-the-shelf Model Context Protocol servers get a demo working. They do not satisfy a BAA, a federal data-classification rule, or an InfoSec review that asks who the agent is, which fields it can read, and where every tool call is logged. When the system of record is proprietary, clinical, or legacy, you need servers designed for that boundary. That is what MCP development is for.
This guide explains what MCP actually is, when official servers are enough, what a production context layer must include, and when to hire senior engineers instead of pointing a generic filesystem server at production.
The problem is not the model. It is the context.
Claude, Cursor, and internal agents are useful in proportion to the data and tools they can use. Without a governed context layer, organizations get one of two failure modes:
- Shadow AI — employees paste sensitive data into consumer chat products because the approved path cannot query Salesforce, the EHR, or the ticket system.
- Blocked rollout — leadership wants agents on internal systems; security will not allow unbounded tool access, so the program stalls at a slide deck.
Neither is a model-quality problem. Both are a missing interface: authenticated tools, scoped resources, and an audit trail. MCP is that interface — when it is implemented as production software, not as a weekend experiment.
What is the Model Context Protocol?
Model Context Protocol (MCP) is an open protocol — originally published by Anthropic — that standardizes how AI applications connect to tools, data sources, and prompts. An MCP server exposes those capabilities. An MCP client (Claude Desktop, Cursor, a custom agent runtime) calls them over a consistent interface instead of a one-off plugin for every system.
Three primitives matter in practice:
- Tools — actions the model may invoke (create a ticket, look up a patient encounter, query a ledger). Tools are where authorization and side effects live.
- Resources — readable context (files, records, schemas) the client can fetch without implying a write.
- Prompts — reusable instruction templates the host can offer so teams do not reinvent unsafe “just do whatever” system prompts.
That is different from a generic service bus or configuration registry. MCP is specifically about giving models governed context: which tools they can invoke, which data they can read, and what they are allowed to do next. For a developer-oriented walkthrough of servers and transports, see MCP servers for developers.
What good looks like in production
A demo MCP server can wrap an API key and a happy-path tool. A production context layer has to survive a security questionnaire. Expect at least:
- Identity — the agent acts as a principal, not as a shared god-mode key sitting in a desktop config file.
- Least privilege — tools are scoped to fields, records, and environments the caller is allowed to see. “Dump the CRM” is not a tool.
- Audit — every invocation is logged with who, what, when, and which resource. That log is how you answer the next incident or SOC 2 question.
- Transport that matches the risk — local stdio is fine for a developer laptop. Remote HTTP with authentication is what enterprise hosts and shared runtimes actually need.
- Failure modes — tools that must not run (PHI export, bulk delete, payment capture) are denied in code, not in a prompt that a model can ignore.
If you cannot show those controls, you do not have MCP development. You have a demo that will fail the first serious review.
Off-the-shelf vs custom vs a legacy wrap
Choose the smallest thing that is still honest about your boundary:
| Approach | Best for | When it breaks |
|---|---|---|
| Official or community MCP servers | Public tools, low-sensitivity data, vendor-maintained connectors | Proprietary APIs, PHI, classified data, undocumented systems |
| Custom MCP development | Internal systems that security must approve | Treating it as a prompt-engineering project instead of software |
| MCP wrap in front of legacy | Agents that need the system of record now | Pretending a wrap is a modernization program — use legacy modernization when the runtime itself must change |
Healthcare is the sharpest example. An agent that reads EHR or care-management data is creating, receiving, or transmitting PHI. Minimum-necessary access, encryption, and audit logging are design constraints — the same bar as HIPAA software development. For the dedicated HealthTech practice, use Maxiom Labs.
Hire vs DIY
Build it internally when the target system is well-documented, the data is not regulated, your platform team already owns identity and logging, and you can staff senior engineers who will threat-model before they expose tools.
Hire custom MCP development when any of these are true:
- InfoSec has already blocked an agent rollout pending scoped tools and an audit trail
- You handle PHI, payments, or government data and need BAA- or FedRAMP-aware engineering
- The system of record is legacy, undocumented, or too risky to put behind a generic connector
- Shadow AI is already leaking context that should never leave the boundary
- You need a written threat model and handoff, not a repo that only the original prompt author understands
MCP is the build side of agent programs. The govern side still matters: if those same teams ship product code with Copilot or Cursor, pair the context layer with an AI code audit so the code the agents help write is reviewed as well. The two engagements answer different questionnaires.
How an MCP engagement typically runs
- Scope — clients (Claude, Cursor, custom), systems of record, data classes, and the review that is blocking you
- Threat model — what the agent must never do, least-privilege scopes, PHI or classified boundaries
- Build — servers, transports, tools/resources/prompts, tests against real or faithful target systems, in your environment
- Handoff — audit evidence, runbooks, failure modes, and ownership
Maxiom does not process proprietary source or PHI through third-party AI as part of delivery. NDA first. Least-privilege access. Named senior engineers.
FAQ: enterprise MCP development
Is MCP just another API gateway?
No. An API gateway fronts HTTP services for applications. MCP fronts model-usable tools, resources, and prompts for AI clients — with a protocol those clients already speak. You may still sit behind a gateway; you still need tool-level authorization the model cannot bypass.
Can we just use the official GitHub or Slack MCP servers?
Yes, when those are the systems and the data sensitivity matches. They are the wrong answer for proprietary domain APIs, EHR, ERP customizations, or anything your BAA or federal ATO does not cover.
Does MCP replace RAG?
No. Retrieval-augmented generation fetches text into context. MCP exposes tools and resources the agent can call. Many production agents use both — retrieval for documents, MCP for systems of record that must not be dumped into a prompt.
Will this let ChatGPT query our production database?
Not if it is designed correctly. Production MCP servers authenticate the caller, constrain tools to approved operations, and log every invocation. Unbounded SQL from a consumer chat product is the failure mode this work exists to prevent.
Can MCP wrap a mainframe or .NET Framework app?
Often. The wrap is a governed interface, not a rewrite. If the runtime itself must move, that is a modernization program — not an MCP ticket.
How does this relate to vibe coding or Copilot?
MCP is runtime context for agents. Copilot and Cursor are coding assistants that write into repositories. Review that output with an AI code audit or oversight. Do not confuse “the model can call our API” with “the model wrote safe product code.”
Do you train models on our data?
No. Client systems stay in client environments. Delivery is direct engineering, not third-party AI processing of proprietary source or PHI.
Where should a healthcare team start?
With data classification and a BAA-aware threat model, then MCP tools that implement minimum necessary access. Pair with HIPAA software development and Maxiom Labs when clinical systems are in scope.
Next step
If agents are stuck in a demo, or if people are already pasting internal data into consumer AI, do not wait for the first incident. Scope an MCP development engagement, read how we build AI products more broadly, or start from the healthcare practice at Maxiom Labs. If the next questionnaire is about Copilot-written code rather than agent tool access, use the AI code audit guide instead.
