See what your AI tools actually send

Not since v0.4.0. Each release ships one-file executables for Windows x86_64, macOS Apple Silicon, and Linux x86_64 (glibc 2.35 or newer), built by PyInstaller on GitHub's runners and smoke-tested on each platform before upload. They bundle Python and mitmproxy. They are unsigned, so macOS needs xattr -d com.apple.quarantine and Windows shows SmartScreen once; a .sha256 sits beside every file. Intel Macs and other architectures use pipx install upbox-sh, which needs Python 3.12 or newer.

Stored locally in ~/.upbox/upbox.db (SQLite, WAL mode, owner-only permissions). The body_excerptcolumn holds up to the first 100 KB of each body; when a body is larger, the dashboard shows a “first 100 KB of N” notice rather than silently cutting it. body_hash (SHA-256 of the full body) and req_bytes (true size) are always recorded, so a truncated excerpt is still provable. Auth headers and credentials in URL query strings are replaced with markers before anything is written. By default, retention clears stored bodies and headers after 7 days while the row and the hash chain stay intact. Or store no bodies at all: see the next question.

Yes. ~/.upbox/rules/capture.yaml has two switches, bodies and headers. With both false, upbox keeps timestamps, tools, hosts, paths with credentials removed, sizes, status codes, the SHA-256 of each body, and the redaction and allowlist outcomes, and nothing a prompt contained. Redaction still runs on the way out. The setting is live-reloaded, editable on the dashboard settings page, and recorded in every audit export. A file that fails to parse puts upbox in metadata-only mode rather than storing more than you meant. It is the recommended configuration on machines you do not own.

It scales with how large the captured bodies are and how long you keep them. Retention is configured in ~/.upbox/rules/retention.yaml: body_days (default 7) clears bodies and headers but keeps the row, and record_days (default: never) deletes whole rows and records the gap in the chain so upbox verify reports a disclosed deletion rather than tampering. upbox prune --dry-run shows what a pass would remove; upbox hold exempts a range. With the defaults, the database stays small: once bodies are cleared, a row is roughly a kilobyte of metadata and hashes.

Yes, since v0.2.0. Every row carries a SHA-256 over its own fields plus the previous row's hash. upbox verify recomputes the chain and reports edited content, deleted rows, inserted or reordered rows, and a botched restore. What it cannot do: the algorithm is public and keyless, so anyone with write access to the file could recompute a consistent chain or truncate the tail. The chain is worth something once a head hash has left the machine, which is what upbox checkpoint is for: seal the head, then mail it, commit it, or have it timestamped. upbox will not anchor it for you, because it makes no outbound calls. Erasures on request are disclosed, not hidden: a tombstone keeps its position and hash, and verify counts it.

Yes. upbox erase --id N --reason "..." (or --host, --tool, --since, --until) erases individual records for GDPR Article 17. The row becomes a tombstone: tool, host, path, sizes, headers, body, and hashes of the content are cleared, and only the timestamp and the chain hashes stay, so upbox verify still passes and reports the erasure with its reason. Preview with --dry-run. A row under legal hold refuses the whole operation until you release the hold.

upbox report -o report.md --records records.ndjson. The Markdown says what upbox holds about this machine's user: the categories of data and whether each is stored, recipients per tool and host, the retention policy in force, any erasures, chain status, and how to get a copy or erase. The NDJSON is the machine-readable copy of the records. The dashboard shows the same at /transparency. The controller's identity is yours to fill in; upbox says so rather than guessing.

Not by upbox, on purpose. It runs as an unattended daemon, so any in-app key would sit next to the database and defeat strings upbox.db and nothing else. upbox sets ~/.upbox to 0700 and the database to 0600, and leaves encryption to the volume: FileVault, BitLocker, or LUKS, with keys in a TPM or Secure Enclave. upbox doctor reports whether that is on, along with file modes and chain health. The stronger control is not storing the data in the first place: metadata-only capture, redaction, and retention.

Negligible. The mitmproxy core handles tens of thousands of requests per second; AI tools peak in the low hundreds per hour. Latency added per request: ~1–5 ms.

A handful of mobile and certain desktop clients ship with hard-coded CA fingerprints. Without modifying the app binary, you can't MITM them. Known-working and known-broken tools are listed in the docs. Banking, health, webmail, government, and identity-provider destinations are deliberately never decrypted at all, whatever else you configure.

Yes. Edit ~/.upbox/rules/tools.yaml (or redact.yaml, allowlist.yaml, capture.yaml), or use the dashboard's /settings page. The running proxy picks up the change within about two seconds, no restart. A broken edit keeps the previous rules loaded. Adding a brand-new intercepted host still needs a restart, since the TLS scope is fixed at boot.

Technically yes. Legally, intercepting TLS on an employee device is employee monitoring, and GDPR Article 88 leaves the rules largely to national law; in Italy it needs a union agreement or Labour Inspectorate authorisation. Inform workers and their representatives first, run metadata-only capture, keep the default never-decrypt list, and read the Article 88 section of the AI Act mapping doc. Running upbox on your own machine raises none of this.