Loading page
About this tool
Review a HAR network trace locally to see which hosts an AI app contacted and where outbound bodies, credential headers, or sensitive query names appeared.
The Local AI Data-Egress Monitor reads a HAR network trace in your browser and sorts every recorded request into three scopes — loopback, expected, and unlisted — so you can see whether an app claiming to run locally actually talked to anything else. For each host it counts requests carrying an outbound body, requests sending one of four credential headers (authorization, cookie, proxy-authorization, x-api-key), and requests whose URL contains one of fourteen sensitive query names such as prompt, input, message, email or api_key. It is for people evaluating a local LLM app, browser extension or desktop tool who want evidence from the trace rather than a marketing claim.
Open Local AI Data-Egress Monitor on AltFTool — it loads instantly in your browser.
Press Open HAR to load a .har or .json capture — up to 10 MB and the first 10,000 entries — or paste it into the HAR JSON box.
List the hosts the app is allowed to reach under Expected remote hosts, one per line, as exact names or *.trusted.example wildcards.
Read the Host inventory for unlisted hosts carrying outbound bodies, then press Counts-only report to save local-ai-egress-summary.json.
Requests are bucketed as loopback (localhost, 127.0.0.1, ::1, 0.0.0.0), expected (matching your allowlist), or unlisted, and unlisted hosts sort to the top.
Expected hosts accept exact names or *.example.com patterns, and the tool rejects anything containing a path or whitespace so a malformed rule cannot silently pass traffic.
The exported summary carries counts and scopes only — hostnames, URLs, header values, query values and bodies are all excluded, so it is safe to paste into a ticket.
Record a HAR trace of the app's session, load it here, and look at the unlisted-scope hosts with a non-zero body-request count. Requests with an outbound body going to a host that is neither loopback nor on your allowlist are the ones worth investigating, especially if they also carry a prompt, input or message query name.
Four credential headers — authorization, cookie, proxy-authorization and x-api-key — and fourteen sensitive query names: access_token, apikey, api_key, authorization, content, email, input, key, message, prompt, query, search, text and token. It reports that these names appeared, never their values.
Up to 10 MB of source text and the first 10,000 entries, whichever comes first; anything beyond that is reported as truncated rather than silently dropped. It accepts a standard HAR with log.entries, a bare entries array, or a top-level array of entries.
No. A HAR only captures what the recorder saw during that session, so traffic outside the capture window, non-HTTP channels, or requests made by a helper process will not appear. It also cannot tell you whether a body that did leave contained anything sensitive — it only reports that a body existed and how large it was.