AI Agents, Without the Operational and Security Headaches

As the executive accountable for your organization’s AI rollout, you don’t lose sleep over MCP protocol mechanics; you lose sleep over the program stalling in a security review…or, clearing review only to become the reason for next year’s audit finding. 

Every AI agent program eventually needs a way for agents to reach enterprise tools and data that your security team will actually approve, regardless of which model provider you’re using this year. 

Claude MCP Tunnel’s Solutions vs. the Remaining Gaps 

Announced by Anthropic in May 2026, Claude MCP Tunnel solved how an AI agent reaches internal tools and data without your team opening a public MCP server or standing up a VPN in the corporate network. 

The remaining gap is scope. Most enterprise AI programs aren’t single-vendor. You’re piloting Claude in one business unit, GPT in another, evaluating a self-hosted model for anything that can’t leave the building, and inheriting AI-infused SaaS tools that bring their own access requirements. A tunnel that only covers one provider requires your security architecture to change (and your board-level governance story to be rewritten) every time a business unit picks a different model.

The Three Places AI Agent Programs Stall

Talk to enough security teams and the stall points repeat themselves regardless of the agent’s use case:

• The firewall exception queue. Publishing an MCP server publicly, even behind a WAF, adds a new internet-facing asset to the patching and pen-test cadence, plus an LLM-provider IP allowlist that has to be maintained by hand.
• The VPN objection. A site-to-site VPN from the model provider’s tenant into your network flattens exactly the segmentation your security team has spent years building, and it pulls the provider’s cloud into your compliance scope.
• The vendor lock-in question. Whatever access pattern you approve for one model provider has to be re-approved, re-architected, and re-explained to the board for the next one.

Zero trust AI agent security removes all three at once. Every MCP server stays on its private subnet. A small gateway inside your network makes a single outbound, authenticated connection out to wherever the model is running, whether that’s a public provider or an environment you host yourself. The firewall rule shrinks to one outbound destination instead of a growing exception list, and the same pattern covers every provider your organization decides to use.

Non-Human Identity: The Layer Your Board Will Ask About

Boards are starting to ask a version of the same question: if an AI agent can call your systems, who is accountable when it does something it shouldn’t have? That’s a non-human identity question, and it’s becoming a Zero Trust governance requirement rather than a technical nicety.

Under this architecture, every agent, gateway, and MCP server enrolls with its own cryptographic identity rather than a shared API key sitting in an environment variable. Every connection authenticates through mutual TLS, and per-tool authorization happens at the MCP server itself, scoped to the identity of the calling agent. If an agent is compromised, the blast radius is exactly the tools that agent was authorized to call, because there’s no network path to anything else. That’s a materially different answer to give your audit committee than “we trust the API key rotation policy.”

How Identity-First Reachability™ Changes the Governance Conversation

This is the same architecture NetFoundry already runs for billions of API, site-to-site, and machine-to-machine sessions across thousands of enterprises, built on Identity-First Reachability™: nothing is reachable on the network until identity is verified, by construction, not by firewall rule maintenance.

For your program specifically, that means:

• One access architecture across Claude, GPT, Gemini, and self-hosted models, so a vendor switch doesn’t trigger a new security review.
• A change management model where adding a new AI tool is an identity and policy assignment, not a firewall-rule request routed through a change board.
• Session-level audit data (identity, service, time, success or failure) that feeds your SIEM directly, so “can you show the auditor what an agent touched” has a real answer.
• A control plane your organization owns, not a dependency on any single model provider’s tunnel infrastructure.

That last point matters more than it sounds. The AI vendor landscape reprices, deprecates models, and gets displaced by the next release cycle faster than most enterprise architecture decisions should be made. An access model that only works for one provider gets rebuilt every time that cycle turns. One that’s provider-neutral doesn’t.

How to Brief Your Board on AI Agent Security

If you’re accountable for your organization’s AI program, the governance story you need is short: every agent has its own identity, nothing is reachable until that identity is verified, and the same model holds regardless of which LLM provider is running underneath. That’s a governance answer that survives a vendor change, a new business unit, and an audit, in a way that “we rotate the API keys” never will.

NetFoundry is built by the team behind OpenZiti, the open source zero trust platform underlying this architecture, and already secures billions of sessions for critical infrastructure across regulated industries including financial services, healthcare, and energy. For your next AI rollout, that means the security review happens once, not once per model.

Request an executive AI governance briefing to walk through what this looks like for your specific AI roadmap. You can also read more on how AI governance became a board-level issue, or see our AI Security solution for the full architecture.

---

Frequently Asked Questions

How do you secure AI agents and MCP servers with zero trust?

Zero trust AI agent security gives every agent, LLM, and MCP server its own cryptographic identity and requires mutual authentication before any connection is allowed. At NetFoundry, we deploy this through a gateway that makes a single outbound connection from inside your network, so MCP servers never need a public IP address and there’s no inbound path for an attacker to find.

What is non-human identity, and why does it matter for AI governance?

Non-human identity refers to the authentication and authorization credentials assigned to machines, services, and AI agents, as distinct from the identities assigned to people. As AI agents take on more autonomous actions inside enterprise systems, boards and auditors increasingly expect the same identity rigor for agents that already exists for employees: a unique, revocable identity per agent, not a shared API key.

Does this only work with Claude, or does it cover other AI models too?

It’s provider-neutral. The same architecture covers Claude, GPT, Gemini, and self-hosted models like Llama, so switching or adding a model provider doesn’t require a new security review or a new network design.

Do we need this if our AI agents run entirely inside our own private network?

If every AI interaction stays within one isolated network with no need to reach other sites, business units, or cloud regions, the exposure this architecture addresses may not apply yet. Most enterprise AI programs outgrow that boundary quickly, once an agent needs to reach a tool, dataset, or partner system outside its original environment.

What’s the difference between this and a VPN?

A VPN typically grants broad network-level access, which is what security teams object to when a model provider requests one. This architecture grants access at the level of a specific tool or service, tied to a verified identity, with no broader network reachability granted at all.