ExecutionGateway — Dynamic MCP with Policy-Filtered Discovery and Zero-Trust Execution

[jmfloreszazo]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

Proposal: ExecutionGateway — Dynamic MCP with Policy-Filtered Discovery and Zero-Trust Execution

Problem it solves

Current MCP servers expose all available tools dynamically, making governance and compliance difficult.
Organizations need a way to filter, audit, and control which tools are visible and executable by AI agents — without modifying every backend service.

Today, most implementations:

• Have full runtime exposure (all tools visible)
• Lack policy-based filtering
• Can’t easily enforce per-tool constraints or approvals
• Don’t separate discovery (catalog) from execution (actions)

---

Idea summary

Introduce an ExecutionGateway pattern — a lightweight MCP-compatible proxy that brings Zero-Trust governance to dynamic MCP environments.

Core features

• Dynamic MCP generation (no static file on disk)
• Fetches backend MCP (from APIs exposing /.well-known/mcp or generated from OpenAPI)
• Filters tools based on a local policy.json
• Applies constraints (max page size, timeout, input limits)
• Supports job tickets (HMAC) for manual or semi-autonomous execution
• Optionally generates a Static MCP snapshot for documentation or caching

---

Architecture overview

┌──────────────────────┐
│  MCP Agent / Client  │
│  (VS Code, LLM, etc.)│
└──────────┬───────────┘
           │
           │ 1. GET /.well-known/mcp
           ▼
┌──────────────────────────────────────┐
│  ExecutionGateway (Port 5050)        │
│  - Loads policy.json                 │
│  - Filters tools by policy           │
│  - Validates constraints & tickets   │
│  - Forwards allowed requests         │
└──────────┬───────────────────────────┘
           │
           │ 2. Fetch backend MCP
           ▼
┌──────────────────────────────────────┐
│  SampleApi (Port 5001)               │
│  - Serves OpenAPI & MCP dynamically  │
│  - May include private endpoints     │
└──────────────────────────────────────┘

Result

• Gateway exposes only allowed tools (per policy.json)
• Hidden tools never appear in discovery
• Non-policy tools are 403 Forbidden at execution time
• Constraints validated on each request
• Optional ticket approval for sensitive actions

---

Security guarantees

Guarantee	Enforcement	Result
No execution without policy	Tool must exist in policy.json	Blocks unknown tools
No discovery without policy	Filter at discovery stage	Hidden tools invisible
Constraint validation	Input limits (e.g., pageSize)	Prevents abuse
Private endpoints hidden	Backend MCP filtered	No leakage
Dynamic policy updates	Live reload (future enhancement)	Instant security tuning

---

Who benefits

Who benefits

• Enterprises deploying MCP in regulated or multi-tenant environments
• Security/compliance teams needing auditability
• Developers who want to safely connect agents to existing APIs
• Organizations where standard MCP deployment is not acceptable due to security or compliance concerns — this pattern is the only viable way to adopt MCP under strict governance
• Enables exposure of legacy or internal APIs that currently cannot be published directly, by wrapping them safely through a policy-controlled ExecutionGateway

---

How it could be implemented

• As a reference “ExecutionGateway” service or spec addendum:
  • Implements dynamic /.well-known/mcp (policy-filtered)
  • Exposes /execute/{tool} endpoint with validation
  • Loads policy.json (local or remote)
• Could extend MCP Lite or become part of a Security / Governance section in the spec.

---

Alignment with existing discussions

• Related to MCP Lite (static/declarative definitions via /.well-known/mcp)
• Expands on security & governance conversations (tool exposure, zero-trust)
• Complements Envoy AI Gateway ideas for multi-server orchestration, but focused on policy filtering & constraint validation

---

Example project (reference implementation)

A working .NET implementation is available here: static-secure-mcp demo repository

It demonstrates:

• A Sample API with Swagger
• A CLI generating a static MCP from OpenAPI
• An ExecutionGateway that filters & enforces policies dynamically

---

TL;DR

A “Zero-Trust” extension of MCP where discovery and execution are policy-aware, dynamically filtered, and secured by local governance — making MCP production-ready for enterprise and regulated use cases.

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[Sentinel-Gate]

This resonates. A gateway/proxy layer that authenticates each call, evaluates deterministic policy rules on tool name + arguments + caller roles, and keeps a full audit trail already gives least‑privilege enforcement and real visibility.

One open question I’d love to see clarified in the proposal is how tools/list should behave under policy: do we filter discovery by the same rules used at execution time, or do we rely on execution‑time denies? From a governance standpoint, hiding tools that a caller can’t use reduces leakage and cuts down on failed calls, but it changes the semantics of discovery. Curious how you’d formalize that in a spec‑compatible way.