Resource
How to connect Claude to an on-prem application
On-prem and internal applications are not in Claude's connector directory and cannot be reached from the public internet. A custom MCP connector, paired with a network path your IT controls, bridges that gap with scoped read-write access.
Key takeaways
- Claude reaches an on-prem app through a custom MCP connector plus a network path your IT controls, not by putting the app on the public internet.
- Three common patterns: IP allowlist, an outbound tunnel, or a small in-network agent, scoped to only the endpoints Claude needs.
- The connector authenticates as a scoped service account and never gets more access than that account already has.
- Read flows freely; create and update run in a flow you start; destructive or outbound actions sit behind a confirmation step.
- Works even when the app has no public API, only an internal endpoint, a database, or a private service.
How do you connect Claude to an on-prem application?
To connect Claude to an on-prem application, you pair a custom MCP connector with a network path your IT controls. The connector exposes your app's read and write actions as MCP tools, while an allowlist, an outbound tunnel, or a small in-network agent gives it a route to a system the public internet cannot reach.
Off-the-shelf connectors assume a SaaS app with a public, internet facing API and a hosted OAuth flow. An on-prem application breaks both assumptions: there is nothing in the directory to install, and even a custom connector cannot call an endpoint it cannot reach. So the work splits in two. The connector is the part that speaks the Model Context Protocol to Claude. The network path is the part that lets that connector talk to your application without opening your system to the outside world. This is the same category of problem as putting Claude in front of any internal tool or in-house system, and it is handled as a build, not a download.
What are the ways to give Claude access behind a firewall?
The ways to give Claude access behind a firewall fall into three patterns: allowlist the connector to a private API, run an outbound tunnel so the app never accepts inbound traffic, or place a small scoped agent inside your network. Which fits depends on what your app exposes and what your IT will permit.
| Pattern | When it fits | How it reaches the app | Notes |
|---|---|---|---|
| IP allowlist | App has a private API reachable once a known address is permitted through the firewall. | Your firewall allowlists the connector's egress address; no new public exposure of the app. | Simplest when IT can permit a fixed source address to a private endpoint. |
| Outbound tunnel | App cannot accept inbound traffic, but the network allows outbound connections. | A tunnel dials out from inside your network, so the app never listens for public requests. | Good default when inbound firewall changes are off the table. |
| In-network agent | App has no public API, only an internal endpoint, a database, or a private service. | A small scoped agent runs inside your network and exposes only approved actions to the connector. | Best for legacy or in-house systems with no internet-facing surface. |
In every pattern the principle is the same: the connector reaches only the endpoints you approve, and your application never has to start accepting public inbound traffic. We pick the pattern with your IT, not for them, so it fits the controls you already run.
How does authentication and scoping work?
Authentication works through a scoped service account, API key, or token issued inside your network. The connector inherits exactly that account's permissions and never grants Claude more access than the credential already has. Credentials live in the connector, not in the conversation, and your team can rotate or revoke them at any time.
- Read access lets Claude pull records, look up status, and answer questions from your internal data.
- Create and update run inside a flow you start in the conversation, scoped to what the service account can change.
- Destructive or outbound actions, like deleting a record or sending a message, sit behind a confirmation step you control.
- Every action is bounded by the underlying account, so the connector is never a back door to more than that account has.
What if our on-prem app has no public API?
An on-prem app with no public API can still connect to Claude. We build the connector against whatever the system exposes inside your network: an internal HTTP endpoint, a database, or a private service. The connector translates those into clean MCP read and write tools, so Claude works with the app without it ever needing an internet-facing API.
This is the usual reality for legacy and in-house software. The lack of a public API is not a blocker; it just decides which connection pattern fits and what the connector talks to on the inside. If you want the broader picture of how these builds work end to end, the complete guide to custom Claude connectors walks through scoping, auth, and maintenance, and you can also see the full list of tools we build connectors for on the connectors directory.
Who maintains the connector and the in-network component?
We maintain both the connector and any in-network component over time. When your application changes its endpoints, schema, or auth, we update the connector so it keeps working. The in-network agent, if you use one, stays small and scoped, makes only outbound connections, and can be logged or shut off by your team at any time.
That ongoing maintenance is what separates a connector your team can rely on in production from a one-off script that breaks the next time the app is updated. You own the network and the controls; we own keeping the bridge working.
Frequently asked questions
Can Claude connect to an application that is not on the internet?
Does connecting Claude to an on-prem app expose it to the internet?
How does authentication work for an on-prem connector?
Can Claude write back to an on-prem application or only read?
What if our on-prem app has no public API, only a database or an internal endpoint?
Who runs the part that lives inside our network?
Got an on-prem app you want Claude to work with?
Book a 30-minute scoping call. We'll map your application, the actions Claude should take, and the connection pattern that fits your network.