Short answer: no file, no file content, no sample and no hash of a customer file is transmitted to us. There is no cloud analysis queue. Findings, quarantined content, paths, the audit chain and the metrics all stay in /var/lib/shelltrap and /var/log/shelltrap on your machine.
This is a property of the architecture rather than a promise in a contract: the scanning worker has no network access at all.
The two outbound connections
1. The licence check — to license.shelltrap.com, at activation and then daily with up to an hour of jitter. It transmits:
- the prefix of your licence key, never the key itself,
- a hash derived from
/etc/machine-idas a server fingerprint, - the host name,
- the product version and the operating system.
Purpose: proving an active licence and issuing a signed token. The service logs the key prefix, the fingerprint, the IP address and the result of the operation; those records are kept for at most 12 months.
2. The signature feed — to the same service, at the configured interval. It transmits the signed licence token as a bearer credential and fetches signed rule generations. It transmits nothing about your files.
Both endpoints are operated by Panomity GmbH, Munich, on its own infrastructure in Germany.
Telemetry and samples
Telemetry code is not merely switched off in the default configuration — it is not loaded at all without an explicit opt-in. Sample submission requires a per-case release by an administrator. If you send us a file with a false-positive report, that is a deliberate act by you, per file.
Controller and processor
For the personal data of your own customers that Shelltrap encounters on your server, you are the controller and we are not a processor, because we never receive it. That is a consequence of the architecture, not a contractual construction.
For the licence and billing relationship — your account data, invoices, tickets, licence keys and server activations in this client area — Panomity GmbH is the controller. Details are in the privacy statement.
What is in the logs
Logs contain no secrets and no file contents. Retention defaults: findings 180 days, quarantine 30 days with advance warning, audit one year — all configurable through policy. A purge is never silent. Outbound notification targets are allowlisted.
Questions a data protection officer will ask
- Where is the processing? On your own server. Only licence and feed metadata reach us, in Germany.
- Is there a sub-processor outside the EU? Not for the software. For the shop and client area, spam protection and payment providers are described in the privacy statement.
- Can we audit what leaves the machine? Yes — the two endpoints are documented above, the daemon is restricted to
AF_UNIXunless you install the notification network drop-in yourself, and the worker has no network at all. - What happens to a file we quarantine? It stays on your disk, in a root-only directory, restorable with full metadata, until your retention policy removes it.