Is Your DGX Spark Spying on You? How to Make It Actually Private

Most people buy a DGX Spark because it's private: the model runs on your network and nobody's API logs your prompts. Out of the box, though, it isn't private until you set it up that way.

I audited a GB10 box (DGX OS 7) before putting client data on it.

This is the short version: what it sends, the traps I hit, and how I proved nothing leaves. The full walkthrough with every command is linked at the end.

What it sends home

• A one-time activation event. The first-run wizard starts nvidia-dgx-sol ("Sign of Life"), which posts to events.telemetry.data.nvidia.com and disables itself. If setup is done, it already happened.
• A telemetry service waiting for a switch. nvidia-dgx-telemetry ships two services with a systemd preset of enabled. The Dashboard's "Analytics and data usage" toggle controls them.
• Ubuntu Pro, attached on NVIDIA's account. A setup unit attaches the box to Pro, and ua-timer checks in with Canonical's contract server. Don't detach it: you can't reattach without NVIDIA's token.
• The usual timers: motd-news, apport, firmware refresh, update-notifier and snapd refreshes.
• A dormant setup hotspot. It's how you configure a headless unit, but the scripts and a watchdog stay installed afterward, preset to enabled. None of it is malicious. But "mostly harmless" isn't the bar for client data. Zero unapproved outbound traffic is.

The traps

Simulate every purge. DGX OS ties metapackages together. Purging apport would remove ubuntu-server-minimal. Purging the snapd package would remove dgx-spark-ota-update-meta, NVIDIA's update metapackage.

apt -s purge <package> 2>&1 | grep -E '^(Purg|Remv)'

Protect aptdaemon before any autoremove. Going headless orphans 450+ desktop packages. The Dashboard runs updates through aptdaemon's D-Bus interface but doesn't declare it as a dependency, so autoremove quietly breaks the Update button.

sudo apt-mark manual dgxstation-grub aptdaemon aptdaemon-data python3-aptdaemon

A hold isn't enough for snapd. Remove every snap, mask the services, then pin the package so nothing built on apt (the Dashboard included) offers an update.

apt-cacher-ng ignores hosts.allow unless UseWrap: 1 is set. Without it, rules added after startup are silently skipped. Test from a host that isn't allowed.

ufw can't contain containers. Per Docker's documentation, container traffic is diverted before it reaches ufw's rules. The outbound block has to live on the network firewall.

The lockdown

• Purge and pin nvidia-dgx-telemetry and ubuntu-report; disable the rest of the timers.
• Go headless, remove the desktop and the setup package, and freeze snapd.
• Route apt and firmware through a LAN proxy that only allows approved repositories.
• Sync time from the firewall.
• On the firewall, four rules for the box: pass DNS and NTP to the firewall, a disabled "maintenance window" pass rule, and a logged block for everything else. Then prove it:

curl -sS -m 5 -o /dev/null https://example.com && echo OPEN || echo BLOCKED
sudo ss -tnp state syn-sent   # catch any blocked attempt with its process name

What you give up

The big one: nothing on the box can search the web. Models, container images and packages need a maintenance window. The Dashboard's Updates tab only works while that window is open. That's the trade, and the next articles in the series open services back up one tracked allow rule at a time.

Full article, with every command, the proxy and firewall config, and the complete checklist: Is Your DGX Spark Spying on You? How to Make It Actually Private