Security settings¶
The Security tab in Admin (/admin/security) contains policies that apply to all users
across the deployment.
Multi-factor authentication¶
People sign in through Philter, which handles their MFA, so this tab has no MFA setting. To require
MFA, turn on Philter's mfaRequired setting; each person then enrolls at their next sign-in. See
Sign-in through Philter.
Data-source host allow-list¶
Philter Workspace ships with a host allow-list that gates outbound connections to
external systems (OpenSearch, Elasticsearch, Ollama, and any
other URL an admin types into a Test button or saves on a data source).
The allow-list combines two protections: a default-deny on private-range
addresses (RFC-1918, loopback, and link-local) and an operator-supplied
allow-list of public hosts configured via the
philter-workspace.data-sources.allowed-hosts property. Both are documented in
Data sources → Trust model and host allow-list.
The Enable host allow-list checkbox on Admin → Security is the master switch for both protections.
| State | Behavior |
|---|---|
| Enabled (default) | Outbound endpoints are checked against the configured allow-list and the private-range default-deny. Hosts that don't match are refused with the "Endpoint host is not on the data-source allow-list" error. |
| Disabled | The allow-list is bypassed entirely. Any well-formed URL an admin enters is accepted. The private-range default-deny is also bypassed. |
The setting is read at request time, so toggling it takes effect on the next request without a restart.
Enabling the allow-list¶
This is the default state for new installs. To re-enable after disabling:
- Navigate to Admin → Security.
- Check Enable host allow-list.
- Click Save.
Disabling the allow-list¶
Uncheck Enable host allow-list and click Save. A red banner appears on the Security page confirming the switch is off.
Disabling is not recommended
The host allow-list is the primary defence against server-side request forgery (SSRF) through the admin UI. With the allow-list off:
- Any admin (or anyone who has compromised an admin session) can use the data-source Test buttons, ingest workers, or Philter/Ollama probes to reach internal infrastructure the Philter Workspace process can route to — internal metadata services, intranet HTTP servers, bastion hosts, or other private-range systems that should not be reachable from operator input.
- Misconfigured or hostile data-source rows can be saved against arbitrary public endpoints — the operator-supplied URL is no longer sanity-checked against a curated list.
- Cloud instance metadata endpoints (
169.254.169.254,metadata.google.internal, etc.), which are private-range by address, become reachable when they otherwise wouldn't be.
Disable only as a temporary measure for a known-good, short-lived
troubleshooting session. Configure
philter-workspace.data-sources.allowed-hosts to cover the legitimate hosts
you need to reach, and turn the allow-list back on as soon as
practical. Toggling produces a SECURITY_SETTINGS_CHANGE audit row
so the off-window is auditable after the fact.
Audit trail¶
All changes to security settings are recorded in the audit log:
| Event | Trigger |
|---|---|
SECURITY_SETTINGS_CHANGE |
Admin saves the Security settings form (logged whether or not the value changed); payload names the switch (hostAllowListEnabled) and its previous value |