Your hostnames are a map of your network
Emails and API keys get the attention. Hostnames rarely do, because on their own they look harmless.
Consider db01.internal. It is not a credential and it cannot be used to log in to anything. What it tells a reader is that you run an internal DNS zone called internal, that you number your database servers, and that a db02 almost certainly exists. Paste a stack trace with a dozen of these and you have described a network topology.
What the rule catches
Eleven formats, tested against the live rule:
| Input | Result |
|---|---|
10.0.1.55 | caught |
192.168.1.10 | caught |
172.20.10.3 | caught |
127.0.0.1 | caught |
localhost:3000 | caught |
db01.internal | caught |
printer.local | caught |
sso.corp | caught |
8.8.8.8 | not flagged (public) |
172.32.0.1 | not flagged (outside the private range) |
api.example.com | not flagged (public) |
The last three matter as much as the first eight. A rule that flagged 8.8.8.8 or every domain name would make logs unreadable, and public addresses reveal nothing about your internal structure.
The 172 range is the fiddly one
RFC 1918 reserves three private ranges. Two are easy: anything starting 10., and anything starting 192.168.. The third is 172.16.0.0 to 172.31.255.255, which is 16 of the 256 possible values in that second position.
This trips up naive rules constantly. Matching 172.\d+ catches your internal 172.20.10.3 and also catches 172.217.x.x, which belongs to Google. The rule has to enumerate the valid second octet:
172\.(?:1[6-9]|2\d|3[01])\.\d{1,3}\.\d{1,3}Our test confirms the boundary holds: 172.20.10.3 is flagged, 172.32.0.1 is not.
Suffixes, not guesses
For named hosts the rule matches on a fixed set of suffixes: .internal, .local, .corp, .lan, .intranet, plus bare localhost.
It does not try to guess whether acme-corp.com is internal, because it cannot know. Some organisations run internal services on public domains; a pattern cannot tell the difference between jenkins.acme-corp.com and www.acme-corp.com. That distinction requires knowing your infrastructure, which is your job rather than the rule's.
What this means when you paste a stack trace
Stack traces are dense with hostnames, ports, and connection strings, and they are the single most common thing developers paste into AI chats. The internal-host rule is on by default for that reason.
If your internal hosts live on a public domain, the rule will not find them, and that is the case to check by eye. Search your text for your own company domain before sending; it takes a second and it is the gap the rules structurally cannot close.