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
