Filed deliberately for LATER at the operator's instruction, so that it is a known accepted risk rather than an oversight. Binding to 0.0.0.0 and opening TCP 5198 so the steward can reach us exposes the WHOLE application to the subnet, not just the MCP door: every board, every list, the admin surfaces, the provisioning endpoints and Tool.XQuery - which is the tool that had a proven arbitrary-file-read in it on 2026-09-21. Nothing on the served surface requires a credential today. On a trusted LAN with three machines that is a reasonable trade, and it is the operator's to make; it stops being reasonable the moment this box is on any network he does not control, or the moment a peer on .69 is compromised. WHAT A REAL ANSWER LOOKS LIKE, cheapest first: expose only /mcp/jsonrpc and /.well-known/ to the LAN and keep the rest on loopback, via a reverse proxy or URL-prefix binding; then a shared secret on the MCP door, since the hub protocol already speaks Bearer; then real OIDC, which the platform already uses for human sign-in. Do NOT let this row become permanent - the whole point of writing it down is that the accepted risk has an expiry.