Hi Ian, I looked at how other web UIs talk to MCP servers before replying, and the proxy turns out to be the common pattern rather than something specific to the single-machine case. Even MCP Inspector, the official debugging tool, works this way—it's a browser UI, and it always goes through a small proxy instead of hitting the MCP server directly, even when that server is remote (https://github.com/modelcontextprotocol/inspector).
The main reason isn't CORS, it's credentials. If the browser talks to the MCP server directly, the auth token has to be in the dashboard's JavaScript, and anyone who can load the page can read it. Going through the proxy keeps the token on the server side, where the dashboard backend holds it. On top of that, the MCP server's no-auth mode only accepts local connections, so a browser on another machine couldn't connect directly anyway without setting up auth first. Where I think you're right is that the proxy shouldn't assume the MCP server is on the same machine — and it doesn't need to. The proxy target is just a URL. So I'd take your config suggestion but point it at the proxy: an AsterixDB config option for where the MCP server runs, the proxy forwards there, defaulting to localhost for the sample cluster. Operators change one value and nothing sensitive ever reaches the browser. Happy to restructure the PR that way if it sounds reasonable. Vivek On Thu, 16 Jul 2026 at 04:35, Ian Maxon <[email protected]> wrote: > Hi Vivek, > I'm not sure having a proxy to the MCP server on the CC side makes > sense to me. At least by default. Isn't it only really for the case > where everything resides on one machine? I do understand the issue > with CORS though. Perhaps we need to have an optional configuration on > the AsterixDB side to configure where the dashboard's MCP panel should > be allowed to make requests to (i.e. where the MCP server is)? I saw > the PR you raised for the dashboard that contains the proxy, so I was > reading that patch and going off that. > > I'm not entirely sure I understand the problem completely though, so > please correct me if I'm going off track. Also curious to hear what > others think. > > Thanks, > - Ian > > On Wed, Jul 8, 2026 at 9:21 AM Vivek Gangavarapu > <[email protected]> wrote: > > > > Hi all, > > > > This is the companion thread to the MCP deployment discussion (other > thread > > <https://lists.apache.org/thread/zg4lx9t4tym5jsgmrtzrdx2fozycc03b>), > here I > > want to lay out the security thinking on its own, because it deserves > > scrutiny independent of where the process lives. > > > > The one principle everything hangs on: the sidecar never parses SQL++. No > > grammar, no query rewriting, no deny-list. Anything like that would be a > > second authority that drifts from the CC's parser — a split-brain to > > exploit. Instead the CC stays the sole authority: > > > > - Every query goes to the CC with readonly=true, so the CC's own parser > > rejects all writes/DDL. Nothing in the sidecar to bypass. > > - Runaway queries are bounded by time and byte ceilings (plus concurrency > > limits), not by rewriting the query. > > - Schema info comes from declared metadata only — no dynamic sampling of > > the data. > > > > Net: even a fully compromised sidecar is capped at read-only reads, at a > > bounded rate. > > > > The part I'd most like eyes on is the browser-facing seam — once the > > dashboard proxies to the sidecar, the usual web risks apply > (DNS-rebinding, > > unauthenticated reach, token handling). My plan is to validate > Origin/Host > > at the proxy, keep the default bind loopback-only, and generate the > shared > > token fresh per start (env var, never logged). I'd land those proxy-seam > > fixes first and independently, since they're worth having regardless. > > > > What are your thoughts on: > > 1. Is "sidecar never touches SQL++, CC is the sole authority" the right > > posture, or is there a case where you'd want an independent second check? > > 2. Does proxying MCP through the dashboard raise concerns beyond > > Origin/Host validation I should design against? > > 3. Anything in AsterixDB's existing auth/network model I should conform > to > > rather than build next to? > > > > I've got a fuller threat model + checklist written up and can share it > with > > anyone who wants to tear into it. > > > > Thanks, > > Vivek >
