Part two of a six-part series on AI Agent Frontdoor
At A Glance
- Allow-lists still put the system on the internet, and vendor IP ranges drift.
- VPNs and private links rarely exist for AI vendors, and they hand over broad network reach.
- Vendor tunnels place a vendor-controlled connector inside your network, once per vendor.
- Cloudflare closes the inbound-port problem for web apps, but it routes you through one vendor’s edge and authorizes at the app, not the tool.
- The AI Agent Frontdoor wins when systems sit off the vendor’s cloud, several vendors need the same systems, or auditors want identity-level records and a kill switch.
In this series
The first post explained how vendor-hosted AI agents reversed your attack surface and turned every internal system into a public-facing service. This post takes the next question head-on: given that pressure, what are your actual options for letting an agent in, and what does each one cost? The honest answer is that most teams are choosing between bad trades.
The job on the table
A vendor’s agent needs to reach an internal system, a Git server, an ERP, a core banking API, or an MCP server you run. The agent lives in the vendor’s cloud. The system lives in yours, or on-prem. Something has to connect the two without handing an attacker the same path. Here is what each familiar option really does.
Publish it behind an allow-list
You expose the system on a public endpoint and restrict it to the vendor’s IP ranges. The system is now on the internet, which is the outcome you were trying to avoid. Vendor IP ranges also drift, so the allow-list becomes a standing maintenance task, and any gap in it is an open door. You have reduced the blast radius a little and kept the exposure.
Stand up a VPN or a private link
A VPN or a cloud private link can work when both sides support it. Most AI vendors do not offer one into a customer environment, so the option often does not exist. Where it does, a VPN grants network-level reach, which is far more than one agent calling one service needs, and it widens what a compromised agent could touch.
Run the vendor’s tunnel
Many vendors ship their own connector or tunnel. It solves the inbound-port problem for that vendor, and it puts a vendor-controlled piece of software inside your network to do it. Now multiply that by every agent you adopt. Each vendor wants its own connector, its own update cycle, and its own trust, and your network fills with one-off software you did not write.
Use Cloudflare Access plus Tunnel
Cloudflare deserves a fair hearing, because it gets real things right. Cloudflare Tunnel dials outbound, so the system needs no inbound port, and Access adds identity in front of it. If your systems are web apps and you already run Cloudflare at the edge, it is a reasonable path. The limits show up with agents. You route every session through one vendor’s global network, you authorize at the application rather than per MCP tool, and the model fits HTTP well and other protocols less so. For on-prem or air-gapped systems, and for per-tool control over what an agent may call, it leaves gaps.
Self-host the agent, or say no
You can run the vendor’s model and stack yourself, which trades a connectivity problem for an operations burden and often forfeits the reason you bought a managed agent. Or you can decline, and strand the investment while competitors move. Neither is a security strategy.
Where the Frontdoor wins
The NetFoundry Frontdoor is built for the cases these options handle the worst. It fits when the systems run on-prem or in a different cloud from the vendor, when several vendors’ agents need the same systems, when auditors want identity-level records and a per-vendor kill switch, and when policy rules out a vendor-specific connector inside the network. One neutral control plane replaces a connector per vendor, authorization runs per identity, per service, and per MCP tool, and the systems never appear on the internet. It is software-only, open source based, and it runs NetFoundry-hosted, self-hosted, or air-gapped. The next post looks at what this does to the network team’s workload.
Read the rest of the series
- Prior: You Are Now Salesforce, how AI agents reversed your attack surface.
- Next: A Hostname Instead of a Hole, the network team’s view.
Frequently Asked Questions
Isn’t an allow-list good enough if the vendor’s IPs are stable?
Vendor IP ranges drift, and the system is still reachable from the internet for anyone who lands in an allowed range. The exposure remains even when the list is current.
We already use Cloudflare. Why change?
If your systems are web apps behind Cloudflare and you want app-level access, Cloudflare can serve you. NetFoundry Frontdoor adds value when systems sit off that edge, when you need per-tool authorization, or when you want one neutral control plane across every vendor rather than routing through a single provider’s network.
What’s wrong with a vendor’s own tunnel?
Nothing, for one vendor. The problem is scale: each vendor’s connector is separate software inside your network, with its own trust and update cycle, and the count grows with every agent.
Does Frontdoor work for non-web protocols?
Yes. It carries any IP-based application, not only HTTP, and it enforces identity and policy on each connection.
