What the agent sends, in full.

You are putting this on a server, and the honest objection to a product like this is that it reads your logs. So rather than describing the payload, this page is the payload.

What leaves your machine

One event, in full. Every field the agent can send is in here; there is no second channel and nothing is collected in the background.

{
  "vm_id":        "vm-jkt-01",
  "ip":           "198.51.100.23",
  "jail":         "sshd",
  "action":       "ban",
  "timestamp":    "2026-02-14T03:27:25Z",
  "failures":     9,
  "log_lines":    [ "…the matching lines, 10 at most…" ],
  "origin_source": "socket",
  "agent_version": "1.4.0"
}

A web firewall event adds the rule id, the category, the method, the host and the request path. A mail event adds the score, the authentication results, the envelope sender, the subject and the recipient's domain.

What never leaves it

These are not settings you have to find and switch on. They are what the agent does.

Query strings are stripped from every URL before it is sent. Tokens and reset links end up in query strings far more often than anyone admits, and an abuse report does not need them.
The local part of a recipient's address is never sent. Mail abuse keeps the domain, so you can see which of your domains is being targeted without handing over who works there.
Only the lines that matched are sent, ten of them by default. The agent reads your log; it does not copy it.
No file contents, no process list, no configuration, no inventory of what you run. The agent has no command to collect any of it.

How it travels

Every request is signed over its timestamp, a single-use nonce, the method, the path and a hash of the body — so a captured request cannot be replayed, and a modified one does not verify.
Each host has its own key and secret. A machine that is compromised can speak for itself and for nothing else in your fleet, and you can rotate that one pair without touching the others.
A host must prove it operates from a real, routable address before anything is reported on your behalf. Until it does, its reports are held.

Where it lives once it arrives

One customer's reports are unreachable from another's, enforced by row level security in the database rather than by remembering to write a filter. The application connects as a role that cannot bypass those policies — a superuser would ignore every one of them.
Passwords are stored with scrypt. Eight failed sign-ins inside fifteen minutes locks the account, and the correct password does not unlock it early.
Every send, every policy change, every invitation and every removal is written to a log that can be added to and never edited.
Owners and admins set policy, operators work the queue, viewers can look but not send. An invitation names the role before it is accepted.

What is sent on your behalf

Reports go out with your organisation's name and your reply address, so an abuse desk replying reaches you. A report held for want of evidence is never sent at all, and a contact that bounced or complained is suppressed rather than retried. If you remove an agent, the reports it already filed stay — they are the record of what was sent in your name, and an abuse desk may still write back about one.

Read the payload, then try it

Open the portal How it works