Devlery
Blog/AI

NetFoundry MCP 게이트웨이, AI 에이전트의 열린 포트 차단

NetFoundry가 MCP와 LLM 게이트웨이를 출시했습니다. 에이전트 도구 호출을 API 키와 공개 포트 대신 identity로 묶는 시도입니다.

NetFoundry MCP 게이트웨이, AI 에이전트의 열린 포트 차단
AI 요약
  • 무슨 일: NetFoundry가 2026년 6월 3일 Zero Trust MCP GatewayLLM Gateway를 AI Enclave에 추가했습니다.
    • 발표 자료는 OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, private Ollama 접근을 OpenAI-compatible gateway에서 통제한다고 설명합니다.
  • 개발자 영향: MCP 서버를 public DNS, WAF, VPN, shared secret로 열지 않고 outbound-only identity path로 붙이는 선택지가 늘었습니다.
  • 주의점: 최대 50% token cost saving과 prompt injection filtering은 공급사 주장입니다. 실제 절감률은 routing policy, 모델 구성, agent loop 설계에 따라 달라집니다.

NetFoundry가 2026년 6월 3일 AI Enclave 제품군에 Zero Trust MCP Gateway와 LLM Gateway를 추가했습니다. 발표문에서 NetFoundry는 AI agent, MCP server, LLM endpoint가 기업 내부 도구와 데이터에 접근할 때 public inbound port와 API key를 만들지 않는 구조를 전면에 세웠습니다. 개발팀 관점에서는 “에이전트에게 어떤 도구를 허용할 것인가”뿐 아니라 “그 도구 서버를 네트워크 어디에 노출할 것인가”가 제품 아키텍처의 새 결정 항목이 됩니다.

NetFoundry Connect의 universal MCP gateway 공식 이미지

발표의 핵심 숫자는 최대 50% AI token cost saving입니다. NetFoundry는 이 수치를 LLM Gateway의 model routing, budget enforcement, per-identity cost tracking과 연결합니다. 같은 발표에서 LLM Gateway는 OpenAI-compatible access layer로 OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, private Ollama instance를 다룬다고 설명했습니다. 하나의 애플리케이션이 모델 이름마다 별도 SDK, key, endpoint를 들고 다니기보다 gateway가 cost, latency, data sensitivity를 기준으로 route를 고르는 방식입니다.

MCP Gateway 쪽 메시지는 더 직접적입니다. NetFoundry는 MCP-compatible client가 기업 내부 MCP server에 접근하되, 해당 server가 unauthorized agent나 attacker에게 reachable하지 않도록 만든다고 설명합니다. 발표문은 “denied tools are removed from the registry entirely”라는 표현으로 runtime check 이전의 schema 노출 자체를 줄이는 방향을 강조했습니다. 한국어로 옮기면 거부된 도구는 목록에 보인 뒤 실패하는 것이 아니라, agent가 볼 수 있는 도구 목록에서 빠집니다.

이 출시가 AI 뉴스인 이유는 MCP가 단순한 개발자 편의 기능을 넘어 production network surface가 되고 있기 때문입니다. MCP server는 SQL, ticketing, source repository, SIEM, CRM, file store 같은 실제 시스템을 agent가 호출할 수 있게 만듭니다. 테스트 환경에서는 local server 하나로 충분합니다. 기업 rollout에서는 server가 private subnet에 있는지, public endpoint인지, cloud model provider가 어떤 경로로 들어오는지가 감사 항목이 됩니다. human user identity가 tool call에 전달되는지도 같은 수준으로 확인해야 합니다.

항목기존 MCP 노출 패턴NetFoundry 발표의 게이트웨이 패턴
접속 경로public DNS, reverse proxy, WAF, allowlist, 또는 provider VPN기업망 내부 gateway가 outbound-only 연결을 열고 identity와 policy로 service path 생성
권한 기준API key, service account, IP 기반 network rule에 의존하기 쉬움agent, MCP server, LLM endpoint에 cryptographic identity를 부여하고 service-level authorization 적용
모델 호출애플리케이션이 provider별 endpoint와 key를 직접 보유OpenAI-compatible gateway가 provider routing, budget, PII, prompt injection policy를 중앙화
감사 단위network log, API log, app log가 분리되어 agent action 추적이 끊김agent에서 LLM call, tool invocation까지 single audit trail로 묶는다고 발표

NetFoundry가 2026년 5월 29일 올린 공식 블로그는 이 문제를 Claude MCP Tunnel 이후의 범용화 문제로 설명합니다. Claude MCP Tunnel은 Anthropic 쪽 agent가 기업 내부 MCP server에 더 안전하게 접근하도록 돕지만, 기업은 Claude 하나만 쓰지 않습니다. 같은 팀 안에서도 Claude, GPT, Gemini, self-hosted Llama 계열, private Ollama, cloud provider model이 workload별로 섞입니다. NetFoundry는 이때 LLM provider를 enterprise network architecture의 소유자로 두지 말고, inference backend로 낮추는 구조를 제안합니다.

그 구조는 두 층입니다. 첫째는 AI gateway입니다. 사용자 chat UI나 calling application 앞에서 어떤 model provider를 호출할지 정하고, fallback, prompt budget, cost control, moderation, OpenAI-compatible API surface를 담당합니다. 둘째는 MCP gateway입니다. 현재 agent loop를 돌리는 provider가 무엇이든 동일한 identity-bound, outbound-only path로 기업 내부 MCP server에 닿게 합니다. provider가 바뀌어도 private tool server를 다시 public으로 열거나 VPN 범위를 다시 협상하지 않는 것이 목표입니다.

NetFoundry의 AI Enclave solution brief는 이 방식을 layer 7 virtual connectivity로 설명합니다. identity와 policy가 허용하기 전에는 routable path가 없고, 모든 inbound port를 닫는 default deny 접근을 취한다고 적었습니다. 연결 관리와 visibility도 IP 주소가 아니라 identity 기준으로 둡니다. 이 대목은 보안팀만의 관심사가 아닙니다. 에이전트가 여러 도구를 오가며 비용과 권한을 소비할 때, IP 기반 로그만으로는 “어떤 agent가 어떤 사용자 권한으로 어떤 도구를 호출했는가”를 재구성하기 어렵습니다.

LLM Gateway 기능 목록은 enterprise AI 플랫폼팀이 직접 부딪히는 문제와 맞닿아 있습니다. 발표문은 heuristic, embedding, optional LLM classifier로 구성된 3-layer semantic routing cascade를 언급합니다. 요청이 cost-sensitive인지, latency-sensitive인지, data-sensitive인지 판별해 모델을 고르는 구조입니다. 여기에 PII detection, content safety filtering, topic controls, prompt injection detection, team/project별 budget enforcement가 붙습니다. 이 조합은 model router와 AI firewall, finance dashboard가 한 제품 안에 묶이는 방향입니다.

다만 “최대 50% token cost saving”은 그대로 받아쓰기보다 조건을 붙여 읽어야 합니다. 비용 절감은 gateway 자체보다 routing policy가 실제로 어떤 traffic을 낮은 비용 모델이나 private model로 보낼 수 있는지에 달립니다. 예를 들어 deterministic SQL formatting, 간단한 classification, internal ticket summarization은 cheap model로 빠질 수 있습니다. 반대로 long-context code review나 incident response reasoning은 고성능 모델을 계속 요구할 수 있습니다. 게이트웨이가 비용선을 만들 수는 있어도, agent task 설계가 token을 낭비하면 절감률은 줄어듭니다.

MCP Gateway의 structural permission filtering은 더 흥미로운 실무 포인트입니다. 많은 agent system은 tool schema를 model prompt에 넣습니다. 금지된 도구가 schema에 남아 있으면 model이 그 도구를 호출하려 하거나, prompt injection이 tool name과 argument shape를 악용할 수 있습니다. NetFoundry 발표처럼 denied tool을 registry에서 제거하면 agent가 보는 action space 자체가 좁아집니다. 이는 “호출하면 거부한다”보다 “애초에 보이지 않는다”에 가까운 control입니다.

이 접근은 최근 identity vendor들이 말하는 “agent as first-class identity”와도 이어집니다. Ping Identity는 2026년 5월 27일 agent discovery, lifecycle governance, desktop coding agent privileged access를 발표하며 agent에게 long-lived secret을 직접 노출하지 않는 구조를 강조했습니다. Workday Agent Passport, Microsoft Agent 365 같은 발표도 같은 문제를 다른 계층에서 다룹니다. NetFoundry가 다루는 위치는 identity policy와 network reachability가 만나는 지점입니다.

경쟁 축은 넓습니다. Anthropic Claude MCP Tunnel은 특정 provider 경험에서 출발합니다. Cloudflare Tunnel, Tailscale, Teleport는 private resource access를 오래 다뤄온 network/security 쪽 선택지입니다. LLM gateway 영역에는 Vercel AI Gateway, LiteLLM, Portkey, OpenRouter, cloud provider model router가 있습니다. NetFoundry의 차별점은 OpenZiti 기반 zero trust fabric, MCP gateway, LLM gateway, identity-first reachability를 하나의 enterprise-operated 구조로 묶겠다는 데 있습니다.

개발팀이 바로 확인할 항목은 세 가지입니다. 첫째, 내부 MCP server가 public endpoint로 열려 있는지입니다. 둘째, agent가 provider API key나 database secret을 직접 들고 있는지입니다. 셋째, tool call log가 user, agent identity, model request, MCP invocation, downstream system action까지 이어지는지입니다. 이 세 가지가 분리되어 있으면 incident가 났을 때 “모델이 무엇을 했는가”가 아니라 “어떤 경로가 열려 있었는가”부터 다시 찾아야 합니다.

NetFoundry 발표가 모든 문제를 해결한다는 뜻은 아닙니다. Agent가 받은 권한 안에서 잘못된 도구를 호출하거나, 승인된 MCP server가 business logic 취약점을 갖고 있거나, prompt injection이 허용된 tool scope 안에서 damage를 만드는 문제는 여전히 application layer에서 다뤄야 합니다. Gateway는 reachability와 identity, routing, observability의 control plane입니다. Tool semantics, approval workflow, dry-run, rollback, human review는 agent application이 설계해야 합니다.

커뮤니티 반응은 아직 제한적입니다. Hacker News와 GeekNews에서 NetFoundry 발표 자체의 큰 토론은 확인하지 못했습니다. 대신 GeekNews에는 6월 초 AI 기업 IPO와 에이전트 경제 분석처럼 agent infrastructure와 governance를 둘러싼 거시 논의가 이어지고 있습니다. 이 공백은 제품의 중요도가 낮다는 뜻보다, MCP 보안이 아직 developer convenience 뒤에 숨어 있다는 뜻에 가깝습니다. 많은 팀은 agent가 실제 내부 시스템을 수정하기 전까지 network surface를 news topic으로 보지 않습니다.

이번 발표를 읽는 실무적 결론은 단순합니다. MCP server는 “LLM 플러그인”이 아니라 내부 시스템으로 들어가는 programmable door입니다. LLM Gateway도 “모델 선택 도구”가 아니라 어떤 request가 어떤 provider와 model로 나가고, 어떤 비용과 policy를 소비하는지 정하는 control point입니다. NetFoundry의 출시는 이 두 문을 하나의 identity-bound fabric 안에 넣겠다는 시도입니다. AI agent rollout을 준비하는 팀이라면 model benchmark보다 먼저, agent가 닿을 수 있는 network path와 tool registry를 그려봐야 합니다.

출처: NetFoundry launch announcement, NetFoundry Connect blog, AI Enclaves solution brief, Ping Identity agentic enterprise announcement.