Data privacy & scope
Running a closed-source agent on your servers deserves scrutiny. This page states, precisely and completely, what the agent reads, what leaves the host, and the boundaries it will not cross — so you can decide based on facts, not trust.
The short version: the agent reports operational metadata, never secrets or file contents. It is not a general-purpose collector that can be pointed at arbitrary data. It runs a small, fixed set of collectors (see the full list) and nothing else — there is no scripting, no plugin system, and no remote instruction channel that could tell it to read something new.
The fears, answered directly
my.cnf, .env, connection strings), and it never connects to or queries a database. It knows only that a database package is installed and its version — exactly what dpkg -l already shows./etc/passwd or /etc/shadow, and never reports usernames, shells, home directories or password hashes.| You might fear it reads… | What the agent actually does |
|---|---|
Database / app passwords, .env, connection strings | Never opened. No config files are read for their contents. |
/etc/shadow, password hashes | Never read. |
Local users, usernames, shells (/etc/passwd) | Not enumerated. |
Environment variables (printenv, Environment=) | Not collected. |
Process command lines (--password=… in ps) | Not collected — there is no process-argument collector. |
| SSH keys, API tokens, cloud credentials | Never touched. |
| TLS private keys | Never read. Only the public certificate metadata is observed. |
| Your application source code or data files | Not read. The agent does not crawl your filesystem. |
Exactly what leaves the host
This list is exhaustive. Everything the agent transmits falls into these categories, and nothing else:
- Host identity — hostname, OS and version, kernel, CPU architecture, and a stable machine fingerprint (a hash used to recognize the same machine across reports; it is not a hardware serial or personal data).
- System metrics — numeric usage figures over time (CPU, memory, disk). Numbers, not contents.
- Package posture — installed package names and versions, plus counts of pending and security updates and whether a restart is required. The names/versions are needed to correlate published vulnerabilities against what you actually run; they are the same non-secret identifiers your package manager exposes.
- Service posture — how many services are running, how many failed, and the names of the failed units. No process contents, no arguments.
- Served domains — the domain names (FQDNs) served, whether TLS is enabled, the document-root path, and which web server. These specific directives are extracted from your Apache/Nginx virtual hosts — nothing else in those files is read (no rewrite rules, no
proxy_passcredentials, no included secret files, no auth directives). - Certificate metadata — the public parts of the TLS certificates in use: issuer, subject and validity dates. This is the same information any client sees during a TLS handshake. Private keys are never read.
Notice what is absent: no file contents, no credentials, no environment, no user lists, no process arguments.
Read-only, and least-privilege
The agent observes and summarizes only. It performs no remediation, opens no inbound port, and accepts no command channel — a compromised Demerzel server still has no path to execute anything on an agent host (see Security & mTLS identity).
Run it as a dedicated unprivileged user that owns only its config directory. This is defense-in-depth: the code doesn’t attempt to read secrets, and because it isn’t root, the OS wouldn’t permit it to read /etc/shadow or another user’s files even if it tried.
Summarized on the host
Facts are reduced on the machine before anything is sent. Demerzel receives compact, structured facts — counts, versions, names, timestamps — not raw logs, config dumps or file streams. Less data leaves the box than most monitoring agents send.
You don’t have to take our word for it
Because the agent is closed-source, these guarantees are designed to be verifiable from the outside, regardless of the binary:
- Control the egress. The agent is outbound-only and talks to a single endpoint. Firewall it so it can reach nothing but your Demerzel instance, and observe its connections — there is no second destination.
- Inspect the payloads. Point
--serverat an endpoint you control and rundemerzel-agent --once. You will see the exact JSON it posts: the categories above, and nothing else. - Constrain it with the OS. Run it unprivileged; audit what that user can access. The agent can only ever read what the OS lets that user read — and it deliberately reads far less.
- No inbound surface. There is no listening socket, so there is nothing to exploit as a foothold.
In transit and at rest
Everything is sent over HTTPS, authenticated by the agent’s own certificate identity (mTLS). On the server, observations are stored as immutable, append-only evidence — records are never rewritten, so what was reported is always auditable.