What your software is allowed to know about you
August 1, 2026
Every tool you install says it collects usage data to improve the product. Very few say what that means, and the gap between “how often was this button clicked” and “here is the contents of the file they were editing” is enormous. The only version of this promise worth anything is a written list — this may be sent, that must never be — enforced by the software rather than by good intentions.
The allowed list is short and boring on purpose
On the products where I control this, a usage event may contain operational metadata only: which command ran, when, how long it took, whether it succeeded or failed, what class of error it hit, which version of the software and adapter were involved, and whether it ran automatically or by hand. Account and workspace identifiers are included only as one-way hashes, never as the real values, and never in a reversible encoding.
That’s the whole list. If a field isn’t on it, it doesn’t get sent — and the point of writing it as a list rather than a principle is that a list can be checked mechanically.
The forbidden list is the part that matters
Anything in these categories is rejected before it can be stored, rather than filtered out later or apologised for afterwards:
- Anything you typed as an instruction, and anything the system generated in response.
- Source code, file contents, and diffs.
- Absolute file paths, which quietly carry your name and your directory structure.
- Usernames, email addresses, and IP addresses.
- Tokens, keys, and anything shaped like a secret.
- Environment variables, which are where secrets usually hide.
Default deny, and the same rule for diagnostics
The same posture applies to anything that can act rather than observe. Anything capable of executing code, reaching the network, or widening what an automated agent is permitted to do stays blocked until someone explicitly approves it. Approval is recorded, and approving something for yourself on your own machine is deliberately not the same as approving it for an organisation.
Diagnostic bundles — the “send us your logs” request every support team makes — get the harshest treatment, because that is where the accidents happen. Environment values are stripped, file paths are normalised, anything on the forbidden list is removed, identifiers are hashed, and the redacted bundle is shown to you before it is written to disk, let alone sent.
What to ask a vendor — and what to require of anything built for you
These are reasonable questions and a good vendor has the answers written down already. If the reply is a paragraph about caring deeply about privacy rather than a list of field names, you have learned something useful.
- Can you show me the list of fields you send? “Anonymous usage data” is not a list.
- Is anything I type or anything my files contain ever transmitted, under any circumstance, including error reports?
- What is in a support diagnostic bundle, and do I see it before it leaves my machine?
- Can I turn it off, and does the product still work when I do?
The takeaway
Privacy is an enumerated contract, not a value statement. Write down exactly which fields may be sent, reject everything else at the door, and show people their diagnostic data before it leaves their machine.
Capabilities this touches