Spotted · Checked · Timestamped

Spots by DeHub

ai tools · Explainer

extensible-mcp: A Proxy That Keeps MCP Tool-Call Policy Outside the LLM's Reach

extensible-mcp is an open-source proxy that sits between an LLM and the MCP servers exposing its tools, keeping tool-call policy enforcement in a layer the model itself cannot reach. The project was posted to Show HN by a user identifying as Banu, a cofounder at sentelabs.ai, and its stated premise is that an agent should not need to load every available tool to do its job. This guide covers what the proxy actually does, who should run it, and where its narrow scope stops.

Capture taken while checking “extensible-mcp: A Proxy That Keeps MCP Tool-Call Policy Outside the LLM's Reach”

Disclosure: this article contains affiliate links. If you buy through them we may earn a commission at no additional cost to you. Our recommendations are based on the evidence recorded alongside this article, and prices were verified on the date shown.

What changed and why it matters

A repository called extensible-mcp went up on GitHub and was posted to Show HN by a user identifying as Banu, a cofounder at sentelabs.ai. The checkable fact, as of this writing: the extensible-mcp repository exists now, publicly, with a specific and unusual design claim attached to it — policy enforcement that sits outside anything the connected language model can reach.

That claim matters because most setups that connect an LLM to external tools let the model see the full tool list and, in many implementations, the rules governing that access. If the model itself is the thing an attacker can manipulate — through a prompt, a document it reads, or a web page it fetches — then policy logic living inside the model's reach is policy logic an attacker can potentially influence. extensible-mcp is built around separating those two things.

The detail

extensible-mcp is a proxy layer, not an agent and not an MCP server itself. It sits between an LLM and the MCP (Model Context Protocol) servers that expose tools to it, so both sides talk through it rather than to each other directly.

Two design decisions define the project:

  • The model doesn't load every tool. The stated premise is that an agent shouldn't need to see the entire catalog of available tools just to do its job. Narrowing what the model can even perceive is the first line of defense.
  • Policy lives outside the model's reach. Enforcement of which tools can be called, and under what conditions, is architected to sit in a place the model cannot touch or rewrite, regardless of what instructions it has been given.

The reasoning behind the second point is the more interesting part. The maker's stated threat model isn't a malicious user typing a bad prompt — it's prompt injection via any input the agent reads: a webpage, a file, a support ticket, an email thread. If that input can steer the model, and the model also controls the policy, the policy is compromised the moment the input is. Moving enforcement outside the model's reach means a manipulated agent still can't grant itself access it wasn't scoped to have in the first place.

SetupWhere policy livesExposure if the model is manipulated
Model with direct MCP tool accessInside or alongside the model's own contextPolicy can potentially be reasoned around or ignored
extensible-mcp proxyOutside the model's reach, in the proxy layerPolicy enforcement is unaffected by what the model is told

This is a narrow, specific fix for a narrow, specific problem — not a general security product. It addresses one failure mode (policy that a compromised prompt can talk its way around) and leaves everything else — network security, credential storage, the MCP servers' own code — exactly where it was before the proxy was introduced.

What it means for you

If you're building or operating agents that call tools through MCP, the practical takeaway isn't "install this one repo" — it's that the architecture question of where your policy lives is now a live design decision, not an afterthought you patch in later. A proxy the model can't see or edit is one answer to that question. Where you host that proxy, how you deploy it alongside your agent infrastructure, and what the rest of your AI tooling stack costs to run are separate, practical questions worth pricing out before you commit to an approach.

If you're evaluating where to host and run that kind of agent infrastructure, you can See current pricing at the merchant and see what a managed platform charges for the compute, deployment, and scaling pieces that sit around a setup like this.

Best for: teams already running MCP-based agents who want tool-call policy to survive a compromised prompt, and who are comfortable auditing and self-hosting the proxy themselves.

Skip it if: you need a general-purpose security product, a drop-in replacement for your MCP servers, or a fully managed service rather than code you run and maintain yourself.

The decision isn't whether extensible-mcp is good engineering — the repository and its stated design goal are verifiable on GitHub right now. The decision is whether your own agent stack needs policy enforcement the model can't reach, and where you're going to run it once you build it.

What this costs right now

Prices move. We print the figure we read and the moment we read it, and suppress anything older than its window rather than guess at the current number.

Primary source for the news
citation · checked 2026-10-05 02:48Z · github.com

Sources

Primary source for the news
github.com · retrieved 2026-10-05 02:48Z

How this page was produced and checked →