Hello team, Thanks Ian for taking a look at the PR and for raising this. I think we're largely converging on the same design. As we discussed, the design I have in mind is similar to the agent-service integration in Apache Texera. Texera runs its agent service as an independent process, while the browser reaches it through the application’s same-origin nginx route (/api/agents/*). The agent service can be deployed separately, but its address is deployment configuration rather than something exposed directly to the frontend. The existing backend services remain authoritative for datasets, workflows, execution, and access control.
I think the analogous shape here would be: dashboard browser -> dashboard/CC proxy -> configurable MCP server URL -> CC query and metadata APIs So I agree that the proxy should not imply that the MCP process is colocated with the CC. localhost would only be a convenient default for the sample or single-node deployment; an operator could configure any MCP endpoint reachable from the dashboard backend. The reason I still prefer the proxy over allowing the dashboard to call that endpoint directly is that it keeps the MCP credential and deployment topology on the server side. It also gives the browser a same-origin endpoint and lets us apply the normal web-facing controls for eg. Origin/Host validation, request-size and concurrency limits, and appropriate timeout handling before traffic reaches the MCP service. So the checklist would be, a. the browser talks only to the existing web application origin; b. the MCP service remains independently deployable and configurable; c. credentials stay outside browser JavaScript; and d. the CC continues to enforce SQL++ semantics and read-only execution - only query authority Best, Suryaa On Wed, Jul 15, 2026 at 7:26 PM Vivek Gangavarapu < [email protected]> wrote: > 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 > > >
