Splunk Web UI and HEC exposure with missing deny-by-default network boundary

Goal is to define a configuration posture that prevents accidental public exposure of Splunk Web UI and HTTP Event Collector endpoints in Splunk Enterprise and Splunk Cloud deployments.

Current behavior relies on operator-controlled settings such as enableSplunkWeb and mgmt-ui.conf anonymous access, with app-level sharing able to grant visibility to the everyone role. HEC uses token-based authentication independent of UI roles, so ingest can be reachable even when UI is protected. Reverse proxy deployments are typical to avoid exposing port 8000 directly, but Splunk does not enforce a mandatory client certificate or header validation boundary.

With version-dependent defaults and differing on-prem versus cloud handling of anonymous access, the effective permission boundary between UI and ingest is unclear.

Is the intended permission boundary enforced at the Splunk service level or assumed to be provided by external network controls? Should anonymous access and public dashboard sharing be denied by default regardless of proxy presence? How should HEC token scope be constrained relative to UI authentication requirements?