Why a curl User-Agent Isn't Automatically Malicious

A surprising number of security tools treat user-agent strings as a static blocklist: see curl, python-requests, or Go-http-client, raise an alert. In practice, this produces so many false positives that analysts learn to ignore the alert entirely — which defeats the purpose of having it.

curl hitting a public /health endpoint is completely unremarkable; it’s almost certainly a monitoring probe or a developer’s smoke test. The same curl user-agent posting to /api/v1/admin/users or /api/v1/beacon is a different story. The string itself didn’t change. What changed is the context — the path being accessed, the response it got, what else that source IP did in the same session.

This is why LogTriage’s UA classifier doesn’t operate alone. A suspicious user-agent match is one signal among several: path sensitivity, ASN reputation, IP threat intelligence, and behavioral patterns from session grouping all feed into the same score. The compound-signal rule specifically rewards combinations — three or more independent high-severity indicators on the same event get a 1.25× multiplier, on top of whatever each signal already contributed individually. A curl request to a low-sensitivity endpoint from a clean IP stays low risk. The same user-agent on a sensitive admin path, from an ASN already flagged in a threat intelligence feed, compounds quickly.

The broader principle: a security tool that can’t tell curl apart by context isn’t actually doing risk assessment — it’s pattern matching with an extra step. Real risk scoring has to ask not just “is this signal present” but “given everything else true about this event, does this signal change the picture.”