Hey folks, I've been knee-deep in trying to get a local NIM container instance running for my Nano-Claw project, and I have to say, NVIDIA's recent "Securing AI Inference with NVIDIA NIM" blog post felt... incomplete for our use case. It's a great high-level overview for enterprise deployments, but for us self-hosters and tinkerers who want to run this stuff on our own metal, it glosses over some critical practical details.

Specifically, I'm wrestling with the image provenance and runtime model. Pulling the container from NGC is straightforward, but the verification story feels opaque. The blog mentions signed containers, but the practical steps for verifying those signatures outside of a full NGC ecosystem aren't detailed. When I pull `nvcr.io/nvidia/nim/nim-runtime:24.05`, how do I, as an individual, validate its integrity back to NVIDIA? A simple `docker trust inspect` seems to come up empty, which makes me nervous.

Then there's the runtime privilege question. The default run command they suggest uses `--gpus all` and `--shm-size=2g`. That's fine, but what's actually running inside? I did a quick `docker inspect` on the image and the default user is root (UID 0). For a service that's going to be exposing an inference endpoint, that's a significant attack surface to consider, especially if we're networking these containers. Has anyone dug into creating a non-root user Dockerfile for this, or does the internal setup require root for the GPU communication?

And the network exposure! The blog post talks about secure APIs, but the NIM container by default exposes its ports pretty openly. Here's the typical compose snippet I'm playing with:

```yaml
services:
nim-llama:
image: nvcr.io/nvidia/nim/nim-runtime:24.05
command: ["/bin/bash", "-c", "chmod +x /opt/nim/entrypoint.sh && /opt/nim/entrypoint.sh"]
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
ports:
- "8000:8000"
environment:
- "NIM_MODEL=meta/llama3-8b"
- "NGC_API_KEY=${NGC_API_KEY}"
shm_size: '2gb'
```

Exposing port 8000 directly on the host network gives me pause. I'd love to hear how others are fronting this with a reverse proxy (Traefik, Caddy) or implementing stricter network policies. Are we using `network_mode: "host"` for performance and then relying on host firewall rules, or is a user-defined bridge with careful port mapping the better path?

The blog post is a good start, but it feels like the real security work for our homelab and openclaw-agent deployments is just beginning. I'm documenting all my missteps and hope we can pool our knowledge. What are your findings? Have you hit any snags with volume mounts for custom models, or seen unexpected processes inside the container?