Halton Meter is a local network proxy that handles API keys in transit and may store request and response bodies on disk when body capture is enabled. We treat security reports seriously and respond on a documented timeline. This page is the disclosure contract.
How to report
Do not open a public GitHub issue for security reports.
Email operator@haltonlabs.com with:
- A description of the issue and its impact
- Steps to reproduce — proof-of-concept welcome
- The version (or commit SHA) you tested against
- Your name and any disclosure preferences
Response timeline
| Stage | Target |
|---|---|
| Acknowledge receipt | Within 2 business days |
| Initial assessment | Within 7 days |
| Fix or mitigation for high-severity issues | Within 30 days |
Reporters are credited in release notes unless they ask not to be.
In scope
- The daemon (
daemon/) — proxy interception, certificate handling, local storage, HTTP API - Anything that could leak API keys, prompt content, or response data
- Privilege-escalation paths through the keychain trust step or the launchd plist generation
Out of scope
- Vulnerabilities in upstream dependencies — report those upstream; we’ll bump versions
- Self-XSS or attacks requiring local machine access beyond the proxy
- Denial of service against the local daemon — Halton Meter is a single-user tool by design
Hardening guidance
The defaults are sensible, but these are the operator-side checks worth doing:
Rotate any API key that touched this machine before sharing it. Body capture, if enabled, may have captured the key inside an authorization header. The redaction pass strips it, but treat anything that ever crossed the proxy as potentially recoverable.
halton-meter bodies statsshows whether bodies have been captured at all and what the redaction pass found. If your model of “what’s on this disk” assumes no captures, verify it.
Treat ~/.halton-meter/ as sensitive. It contains your captured
costs and potentially redacted prompt content. Disk-encrypt your
machine; Halton Meter does not encrypt the SQLite at rest.
Remove the CA when you’re done. The mitmproxy CA installed by
init only signs traffic to LLM provider endpoints, but it is still
a CA in your System keychain.
$ halton-meter uninstall
$ sudo security delete-certificate -c mitmproxy /Library/Keychains/System.keychainAudit the certifi patch when changing Python interpreters. The
patch is per-Python — a new venv carries an unpatched certifi bundle
and won’t trust the mitmproxy CA. Re-run halton-meter setup --force
from the new interpreter, or remove the CA from the old one if it
should not still be trusted there.
The daemon itself never reaches out. Halton Meter Cloud is an opt-in sync layer, off by default; enabling it is a separate, deliberate act and does not retroactively share data captured before pairing.
What’s next
- Local-only guarantee — the precise contract on what stays on the machine
- SQLite schema — what is on disk and for how long