Last Updated: September 24, 2026
How do you connect Claude to internal systems without exposing customer data?
To connect Claude to your internal systems while keeping your customer data private, you will need to: connect the MCP server inside your network, authenticate through your identity provider, expose narrow read-only tools, and mask customer fields before any response reaches the model.
To connect Claude to internal systems safely, work in this order: pick the deployment surface, host the Model Context Protocol server behind your own gateway, wire authentication to your IdP using Enterprise-Managed Authorization, expose a small set of read-only tools, strip or tokenize customer identifiers in the server response, log every tool call with the identity that made it, and test the whole path against prompt injection before a single production record moves.
The protocol side of this got substantially easier in 2026. The 2026-07-28 MCP specification dropped the stateful session model, so a gateway no longer needs sticky routing or deep packet inspection to work out which conversation a request belongs to. Enterprise-Managed Authorization went stable on 18 June 2026, which moved access decisions to the identity provider you already run. What remains yours to build is the data minimization layer and the audit schema.
What’s in this article: Deployment surface · Where the server runs · Authentication · Keeping data out of the model · Logging · Prompt injection · Control checklist · What to do next · Scadea services · FAQ
Which Claude deployment surface should you use?
Pick based on who uses it: Claude Enterprise connectors for business teams, Claude Code for engineering, or the Messages API with an MCP connector for embedded product workflows.
Claude Enterprise and Team support custom connectors, which is the shortest path for a support or operations team that needs Claude to read a ticket or a customer record. Administrators control which connectors exist and who can reach them, so the governance conversation happens once rather than per user.
Claude Code suits engineering teams working against internal repositories, build systems, and observability tools. The MCP servers it talks to run on the developer machine or on infrastructure you control, which keeps the blast radius small while you learn the pattern.
The API route fits when Claude sits inside a product or an internal application and the end user never sees Claude directly. You own the orchestration, so you also own every control described below.
Where should the MCP server run?
Inside your network or behind your own gateway. The server is the boundary where customer data either gets filtered or gets sent, so it belongs on infrastructure you control.
The 2026-07-28 specification removed the initialize handshake and the Mcp-Session-Id header. Client metadata now travels in _meta on every request, so any request can land on any server instance behind a plain round-robin load balancer. For a platform team, that turns an MCP gateway into ordinary HTTP infrastructure they already know how to scale and monitor.
Routing and metering now read request headers rather than parsing JSON bodies. A gateway, rate limiter, or web application firewall can enforce policy without opening the payload, which reduces incidental exposure of protected health information and nonpublic personal information at the enforcement point. Put the gateway in front of every server, including the ones your teams think are internal only.
How does MCP authentication work for enterprises now?
Enterprise-Managed Authorization makes your identity provider the authority. An administrator sets policy once, users sign in with corporate identity, and per-user consent screens disappear.
The flow runs in four steps. The client sends an RFC 8693 token-exchange request to your IdP, presenting the user’s ID token plus the identifier of the MCP server it wants. The IdP checks that identity against group membership, role, and conditional access rules, then returns a short-lived Identity Assertion JWT Authorization Grant, known as an ID-JAG. The client presents that grant to the MCP server’s resource authorization server under RFC 7523. That server validates it and issues an access token.
Two hardening details matter for a security review. Authorization servers should return the iss parameter per RFC 9207, and clients must validate it before redeeming a code, which closes authorization-server mix-up attacks. Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents, so plan new work on CIMD. OAuth 2.1 with PKCE has been mandatory for remote servers since the November 2025 revision.
How do you keep customer data from reaching the model?
Filter at the server, before the response is serialized. Use field allowlists, tokenize identifiers, and design tools that answer questions rather than returning whole records.
Start with the tool contract. A tool named get_customer that returns a full record will send every field it has, including the ones nobody needed. A tool named get_open_ticket_summary that returns status, age, product, and a tokenized customer reference answers the actual question and carries far less risk. Write the narrow tool first and add fields only when a real workflow fails without them.
Tokenize direct identifiers at the server boundary. Replace the account number with a reference the model can pass back to you, and resolve it on your side when an action needs the real value. Names, dates of birth, government identifiers, and full payment details rarely need to reach the model at all for the work to get done.
Keep the first release read-only. Write access introduces a second question, which is what happens when the model is wrong, and that question deserves its own design pass with human approval steps and rollback.
What should you log on every tool call?
The identity, the tool, the parameters, the timestamp, the server instance, and the decision. MCP has no standard audit schema, so define yours before the first pilot.
Audit trails and observability remain an open gap on the official MCP roadmap. Header-based routing made gateway-level metering cheaper to implement, and the log schema itself is still yours to design. Treat that as an advantage: you can shape it to what your examiners already ask for.
For banks above 30 billion dollars in total assets, SR 26-2 replaced SR 11-7 on 17 April 2026 and moved model risk management toward risk-based oversight tied to materiality. Commentary consistently describes a demonstrable evidence standard, which means showing the work rather than asserting it. A gateway audit feed that records who asked what, which tool answered, and what came back is exactly the evidence an examiner expects to see.
How do you defend against prompt injection and tool poisoning?
Treat every tool response as untrusted input, keep tool descriptions under version control, and require human approval for any action that changes state or moves money.
Prompt injection arrives through content your tools return: a ticket comment, a document, a CRM note that contains instructions aimed at the model. The defense is architectural. Anything a tool returns is data, and no instruction inside that data should be able to trigger another tool call without a human in the path.
Tool poisoning is the supply-chain version. A server author changes a tool description, and the model starts behaving differently with no code change on your side. Pin server versions, review description changes the same way you review code, and run an internal registry rather than letting teams point at arbitrary public servers. The official MCP Registry API listed 9,652 server records as of May 2026, which gives a sense of how much unvetted surface exists.
Scope creep is the quiet risk. Cloudflare’s portal pattern cut token usage from roughly 9,400 tokens across 52 tools to roughly 600 tokens across 2 portal tools. Fewer, better-scoped tools improve both cost and security review.
What controls belong at each layer?
Map each risk to one control and one owner. The table below is the shortest version of a control matrix a security review will ask for.
| Risk | Control | Where it lives |
|---|---|---|
| Unauthorized access | Enterprise-Managed Authorization, ID-JAG, conditional access | Identity provider |
| Authorization-server mix-up | RFC 9207 iss validation before code redemption |
MCP client |
| Customer data reaching the model | Field allowlists, tokenized identifiers, narrow tools | MCP server |
| Unlogged activity | Per-call audit record with identity and parameters | Gateway |
| Prompt injection | Tool output treated as data, human approval for writes | Orchestration layer |
| Tool poisoning | Pinned versions, reviewed descriptions, internal registry | Change control |
| Payload inspection exposure | Header-based routing, policy without opening bodies | Gateway and WAF |
| Runaway scope | Portal tools, periodic tool inventory review | Architecture review |
What to do next
Pick one workflow where a person currently copies information between two systems, and give Claude read-only access to the source through a single narrow tool. Set the audit schema before that pilot runs, since retrofitting logs after the fact is how evidence gaps start. Once the read path is stable and logged, design the write path with approval steps as a separate piece of work.
Scadea services for this work
Scadea builds these integrations for enterprises in banking, insurance, healthcare, and manufacturing. Agentic AI covers the tool design, permission model, and approval steps, and enterprise AI orchestration covers running it across the systems you already have.
Where the work touches the network and identity layers, AI infrastructure covers gateway and hosting decisions, and human in the loop covers the review points that keep a model from acting alone on a regulated process.
Frequently Asked Questions
Does Anthropic train on data sent through MCP?
Commercial terms and enterprise plans differ from consumer ones on training and retention. Confirm the current terms for your specific plan with Anthropic during procurement, and record the answer in your vendor file rather than relying on a blog post.
Can an MCP server run entirely inside our network?
Yes. Servers can run local to a machine or remote inside your own infrastructure. Keeping the server inside your network is what lets you filter fields before any response leaves your control.
What changed in the 2026-07-28 MCP specification?
The protocol core became stateless, dropping the initialize handshake and session header in favor of _meta on each request. Routing moved to headers, extensions became first class, and a formal deprecation policy now guarantees at least twelve months before a feature can be removed.
Do we still need per-user OAuth consent screens?
No. Enterprise-Managed Authorization moves that decision to your identity provider, where an administrator sets policy once and access follows group membership and conditional access rules.
How is MCP different from building a normal API integration?
MCP standardizes how a model discovers and calls tools, so one server works across compatible clients. The security work is familiar: authentication, authorization, field-level minimization, logging, and change control.
What happens if the model calls the wrong tool?
With read-only tools, the outcome is a wasted call and a log entry. That is the reason to start read-only, and to place human approval in front of anything that writes, pays, or notifies a customer.
How many tools should one server expose?
Fewer than teams expect. Large tool catalogs raise cost and widen the review surface, and portal-style consolidation has been shown to cut token usage substantially while keeping the same capability.
Does the EU AI Act affect this work?
The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and deferred Annex III high-risk obligations from 2 August 2026 to 2 December 2027, with Annex I moving to 2 August 2028. Article 50 transparency duties and general-purpose AI enforcement apply now, so the deferral is runway for building your evidence base rather than a reason to wait.
Read next: Agentic AI for Enterprise: Architecture and Governance
