What it sends, what it never sends, and your data

Sent, every five minutes

Read-only and outbound-only, and how

• No listener: it opens no port. It sends one HTTPS request to siliconliquid.com every five minutes, and nothing else leaves.
• No commands: there is nothing in it that takes instructions from Silicon Liquid. An answer from our server says only whether the data was stored.
• As a service, it runs as a user systemd creates for it, with a read-only view of the system and no capabilities; its one privileged step copies the machine's DMI system UUID, which only root may read.
• On Kubernetes, its permissions are get and list on nodes, list on pods (to add up GPU requests) and get on the dcgm-exporter endpoints.
• Silicon Liquid's server keeps the clock: a push whose clock is more than an hour off is refused, and first contact is the moment our server first heard of a GPU.

Your data

• You own it. Silicon Liquid may use it to run your console and reports, and beyond that only as the sharing level you choose allows.
• Kept while your fleet exists. Delete it on the console at any time (it is gone at once), or ask us and we delete it within 30 days.
• Turning a sharing level down stops future data at once. Counts already in the anonymous market map stay there, without your name, as they always were.

1. 0. Private. Silicon Liquid processes your data only to run your console and reports. Nothing is shown to anyone else.
2. 1. Anonymous aggregate. Counts by region and GPU type, as bands, shown only where at least five fleets add to a cell, and at least a week late. No name, no host, no tenant data.
3. 2. Listed. Nothing is listed until you press List this window on one. Buyers see the GPU, nodes, dates, region and evidence level, never your name until you agree to meet them.
4. 3. Named share. Each link names its recipient, shows a summary of your fleet, and stops working on the date you choose or when you revoke it.

Uninstall in one command

curl -fsSL https://siliconliquid.com/monitor/install.sh | sudo bash -s -- --uninstall

docker rm -f sl-agent && docker volume rm sl-agent && docker rmi sl-agent:0.3.0

helm uninstall sl-agent -n sl-agent && kubectl delete namespace sl-agent

Then issue a new token or delete the fleet on your console, so nothing can write to it.

Questions a security team asks

Who can see our data?

You, and Silicon Liquid's desk, which can open any fleet's console to support operators and check windows before they are listed; it shows what it sees to no one else. At the default level (Private) the data is used only to run your console and reports. Anything wider is a sharing level you choose on the console, and you can turn it back at any time.

What can the agent do on our machines?

Read. It reads dcgm-exporter (or nvidia-smi), and, where present, the scheduler's view of each node. It runs no jobs, takes no commands, opens no ports, needs no SSH, root or BMC access, and changes nothing in Slurm or Kubernetes. Its Kubernetes permissions are get and list only.

What does it connect to?

One destination: siliconliquid.com over HTTPS (port 443), an outbound POST every five minutes. Nothing connects to it. On Kubernetes it also talks to your own API server and dcgm-exporter pods, inside the cluster.

How is data protected in transit and at rest?

TLS in transit. At rest, by the database provider's disk encryption. A fleet's ingest token and console key are random and stored only as SHA-256 hashes; they are shown to you once, and you can issue a new token on the console at any time, which stops the old one at once.

How do we know the agent we run is the one you published?

Each release lives at its own address (/agent/v0.3.0/) and never changes. Its manifest lists every file with its SHA-256 and is signed with our Ed25519 release key (/monitor/release/manifest.json, manifest.sig and key.pem); the installer checks the signature, then every file, before anything runs, and stops on any mismatch. Pin the key with --key and the installer refuses a site serving any other (today's key: +3tnwq0sCBnBvMurS8EbPZnn99agn9KQl+5BY8Raguw=). The agent is one readable Python file with no dependencies, so you can read every line first. Nothing updates itself.

Can it see our customers' workloads?

No. It reads only its own short list of labels, so the pod, namespace and job labels dcgm-exporter can attach never reach it, and it strips any such key from the payload again before sending. From Slurm it reads node state and GPU counts only: never jobs, users, accounts or the Reason field. From Kubernetes it adds up the GPUs pods request and keeps no pod name.

Will you use our data to sell to our customers?

No. Silicon Liquid never uses an operator's Monitor data to approach that operator's existing customers.

Where is the data stored, and who processes it?

In the United States: the site runs on Vercel, the database is Postgres (Neon or Microsoft Azure), and emails go through Resend. No other processor sees Monitor data.

How long do you keep it, and how do we delete it?

While your fleet exists. Delete your data on the console and the fleet and everything its agents sent are gone at once; or email us and we will do it within 30 days. A line in our audit log records that the deletion happened. An automatic limit of two years on hourly rows is planned and not yet built.

What if something goes wrong on your side?

We tell the operators affected as soon as we know what happened and what it touched. Report a vulnerability to arpit@siliconliquid.com; we answer within one business day.

Do you have SOC 2 or ISO 27001?

Not yet. We will fill in your questionnaire (CAIQ Lite or SIG Lite) and a data processing agreement on request, and say plainly where we fall short.