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
