docs: explain SSRF egress interaction

docs/network-policy/customize-network-policy.mdx

@@ -30,6 +30,12 @@ Do not rely on `host.docker.internal` as a general host-service path because it
 See [Agent cannot reach a host-side HTTP service](../reference/troubleshooting#agent-cannot-reach-a-host-side-http-service).
 </Note>
 
+<Warning>
+Adding a host to the egress policy permits the connection only after the endpoint, port, method, and binary rules match.
+OpenShell still applies SSRF protection separately, so a request can be denied if the final address resolves to a loopback, private, link-local, or otherwise blocked internal range.
+If a package installer or browser runtime download still fails with an SSRF-style denial after you add the public host, install that binary into the sandbox image at build time with [`nemoclaw onboard --from`](/reference/commands#--from-dockerfile) instead of relying on runtime egress.
+</Warning>
+
 ## Prerequisites
 
 - A running NemoClaw sandbox for dynamic changes, or the NemoClaw source repository for static changes.

docs/security/best-practices.mdx

@@ -91,6 +91,7 @@ flowchart TB
 ## Network Controls
 
 NemoClaw controls which hosts, ports, and HTTP methods the sandbox can reach, and lets operators approve or deny requests in real time.
+Network policy allowlists do not disable OpenShell's SSRF guard; see [Customize the Network Policy](/network-policy/customize-network-policy) for the interaction between egress rules and internal-address blocking.
 
 {/* OpenShell provides additional network enforcement mechanisms not covered here, including network namespace isolation, SSRF protection, TLS auto-detection and termination, and audit-vs-enforce modes.
 See the [Network Controls](https://docs.nvidia.com/openshell/latest/security/best-practices.html#network-controls) section of the OpenShell Security Best Practices. */}