diff --git a/docs/content/features/runtime-settings.md b/docs/content/features/runtime-settings.md
index 6ea021ea03..baba52663c 100644
--- a/docs/content/features/runtime-settings.md
+++ b/docs/content/features/runtime-settings.md
@@ -154,7 +154,7 @@ The **Tools** tab lists the built-in chat tools, from `GET /api/chats/admin/tool
 - **Sandbox network** (applies at the next connection of a command; an allow the proxy cached lives at most 30 seconds). The commands a chat runs in the Sandbox reach the network only through the proxy of the Sandbox add-on, and these settings bound it. They are on the Settings tab of the add-on that runs the commands (its `network-policy` host control), not on this page; `chats_egress_audit_days` is on both, since it also keeps the audit of the commands on this machine. They do not apply to commands on this machine (`chats_host_exec`), which have the network of the server. See [Network access]({{%relref "features/addons#network-access" %}}).
   - `chats_egress_ceiling` (`off`, `registries` or `all`, default `off`): the widest preset any chat may use. `registries` admits the package registries only; `all` admits every public host. A chat chooses its own preset up to this.
   - `chats_egress_default` (`off`, `registries` or `all`, default `off`): the preset a new chat starts with, capped by the ceiling.
-  - `chats_egress_allow_private` (default off): let a host that an administrator allowed, by a rule or a card answer, reach addresses inside your network. A preset alone never does, and the cloud metadata addresses and the server's own addresses stay refused. Turning it on needs `chats_egress_private_confirm` in the same request, with the phrase *I understand that commands can reach my private network*; the phrase is not stored. The add-on's Settings tab asks for it.
+  - `chats_egress_allow_private` (default off): let a host that an administrator allowed, by a rule or a card answer, reach addresses inside your network. A preset alone never does, and the cloud metadata addresses and the server's own addresses stay refused. Turning it on needs `chats_egress_private_confirm` in the same request, with the phrase *I understand that commands can reach my private network*; the phrase is not stored. The add-on's Settings tab asks for it. With add-ons enabled the add-on owner checks the same phrase, so a direct `host-settings-update` call needs `chats_egress_private_confirm` in its patch too.
   - `chats_egress_ports` (default `80,443`): the ports a command may reach, comma separated. Ports 22 and 25 are refused.
   - `chats_egress_extra_registries` (default empty): exact host names added to the package registries, comma separated, at most 64; for example an internal mirror (which also needs the private switch, since its address is private). No patterns. They count as registries: a chat reaches them on HTTPS with the Package registries choice, and on any request with All public sites.
   - `chats_egress_allowed_hosts` (default empty): exact host names or whole-label wildcard patterns an administrator allows, comma separated, at most 64. Each entry is a host name, or `host:port` to allow that one port (the ports setting still applies); names are lower-cased and written in punycode, and a partial-label pattern, a scheme, a path or an IP address outside the public internet is refused (an IP literal of a private network is accepted only while `chats_egress_allow_private` is on, and then still needs a rule or a card answer from an administrator like any private address). A listed host is allowed, on any kind of request, in every chat whose effective preset is Package registries or All public sites, with no card. With the network off, or with the limit (`chats_egress_ceiling`) off, the list does nothing, and a limit below a chat's choice caps it as for the presets. Private, loopback, link-local, metadata and server addresses stay refused unless the private switch rules allow them, the TLS server name is still checked (on any port, when the tunnel starts with TLS), and every use is audited with the reason `allowed_host`. A change applies at the next check (an allow the proxy cached lives at most 30 seconds). The add-on's Settings tab has a list editor next to the extra registries, and the Network panel of a chat shows the list read only. `get_chat_egress` of the LocalAI Assistant returns it as `allowed_hosts`; no assistant tool changes it.