What the agent can and cannot do
The InfraNest agent runs on your server. It only reads, and only sends. It reads what the questions on your server page need, sends that to InfraNest over HTTPS, and does nothing else: it changes nothing on your server, takes no instructions, and opens no port.
Every promise on this page is checked by code you can read. Where you can check it yourself, the command is right next to it. The agent's source is at https://github.com/InfraNest-Infrastructure-Organized/infranest-agent.
Six promises, and the check behind each
1. It only reads, and only sends
It never changes anything on your server, takes no instructions and opens no ports. A push gets an answer, and the only things an answer can change are how often the agent reports and which InfraNest address it reports to (HTTPS, under infranest.io only — see Network requirements).
The check: scripts/check-only-sends.sh runs on every change and every release. It fails the build when anything the service is built from can start a process (os/exec) or serve a request (net/rpc, CGI, FastCGI), on Linux, Windows, macOS and FreeBSD.
2. It never has root
It runs as its own user, infranest-agent, with no login, in a locked-down systemd sandbox: no capability and no way to gain one, a read-only view of the system, no home directories, no devices, no kernel tunables or modules.
Check it yourself:
systemd-analyze security infranest-agentOn Ubuntu 24.04 that reads 1.4 OK — 0 is a unit that can do nothing, 10 one with no restrictions at all, and a stock service scores 9.6. CI runs the same command on every change and fails if the number rises. The agent's README lists what is still flagged and why each stays.
Reading the system log is the one permission you can add, and only by hand: the agent joins the systemd-journal group, which can read logs and nothing else. It is off until you run the command, and the System tab of your server shows the way back.
3. It runs nothing by itself
The one exception is infranest-agent run, which you put in front of your own cron job so InfraNest hears whether it worked. It runs your command as the same user, exactly as before.
The check: the same scripts/check-only-sends.sh: only internal/jobrun may start a process, and only the run command may use it — never the service.
4. Login records never leave your server
When a service fails, the agent can send its last few lines so you can see why. The lines of a login service (sshd, logind, su and sudo, polkit and the others) are records of who logged in, so they are never read; from any other service, a line that is a login record is dropped. Failed logins are only ever counted per hour — a number, not who tried or from where.
The check: the list is in the agent, internal/journal/login.go, and InfraNest applies the same rules again on arrival, whatever version sent it. A test on our side holds the agent's own sample of names and fails when the two drift.
5. Secrets are masked twice
Passwords, tokens and keys in a failed service's lines or a failed job's output are masked on your server, before they leave it, and again when they arrive.
The check: both sides run one shared test corpus, testdata/masking-corpus.json: provider tokens, password= and its relatives, credentials in a URL, Authorization headers, private keys, JWTs, AWS keys and connection strings, each with the exact output expected. A shape added on one side fails the other until it learns it.
If something private still gets through, anyone who can manage the server can remove those lines from InfraNest at once — Something private got through? Remove these lines under them. The card keeps who removed them and when, and the audit log records it.
6. It is the binary we built
Every release is checksummed and carries a build attestation from our release workflow. The installer refuses a binary whose checksum does not match, and — if gh or cosign is installed — one our workflow did not build.
Check it yourself (cosign 2.4 or later):
cosign verify-blob-attestation --bundle infranest-agent.sigstore.json --new-bundle-format \
--type slsaprovenance1 --certificate-oidc-issuer https://token.actions.githubusercontent.com \
--certificate-identity-regexp '^https://github\.com/InfraNest-Infrastructure-Organized/infranest-agent/\.github/workflows/release\.yml@refs/tags/v' \
infranest-agent_linux_amd64Or build it from the tag and compare the hash to SHA256SUMS, which needs no trust in us at all. The agent's README has both, and the gh attestation verify form.
What it sends
Every field is listed in What it sends. Before you install, infranest-agent print takes one reading and prints the exact JSON it would send, and sends nothing. Once it runs, your server's System tab shows What this agent sent in the last 24 hours: each kind of thing, how much of it arrived, what it never includes, and how long it is kept.
Who sees the lines: a failed service's last lines and a failed job's output are shown only to members who can manage that server. Everyone else sees that it failed, when, and what to do.
Where your data lives
In the EU, on Hetzner servers.
How long we keep it
| What | Kept |
|---|---|
| Readings — CPU, memory, disks, network, load | as sent for 48 hours, then hourly for as long as your plan keeps monitoring history |
| A failed service's last lines | 30 days |
| A failed job's last output | 30 days |
| Errors and warnings per service per hour | 8 days |
| Failed login attempts per hour (a number only) | 8 days |
| Each program's hourly memory and CPU | 15 days |
| Programs, services, cron jobs, setup facts | the latest only: each report replaces the one before |
The plans' numbers are in What it sends.
Deleting a server
Deleting a server in InfraNest stops its agent's token at once: a push from it is refused. In the same moment everything the agent said about the machine is removed — the lines, the lists of programs, services, containers, ports and cron jobs, and the setup facts. What stays with the deleted server is numbers and your own decisions: its metric history, its reboots, and your alert rules. Those go when the workspace itself is deleted.
Found a vulnerability?
Email security@infranest.io. We acknowledge your report within 3 business days and give you a triage assessment within 7, and we welcome research done in good faith. Please don't open a public issue first. How to report, and what is in scope: Report a security vulnerability.
Related
- Network requirements: one outbound HTTPS host, nothing inbound.
- What it sends: every field, and how long each is kept.
- Install the agent on many servers.