Every AI tool your company buys has a settings page. Somewhere on it is a privacy control. The question almost nobody asks is whether any code reads it.
I ran into that question the hard way. Team-X, an open-source, local-first desktop app for running AI-agent organizations, shipped a Local Only privacy tier that promised no data would leave the machine. The v3.5.0 changelog, published 2026-10-08, describes what it actually did: max_privacy_tier only drew an "allowed" flag in the panel; nothing that chose a provider read it.
The risk is the gap between label and behavior
A missing control is honest. A decorative control is a representation. Your staff set it, read Allowed or Blocked beside each provider, and stop checking. The control has answered the question for them, falsely.
Regulators treat the gap between a security claim and product behavior as the problem. In its 2020 Zoom announcement, the FTC said: "In reality, the FTC alleges, Zoom maintained the cryptographic keys that could allow Zoom to access the content of its customers' meetings," and used a lower level of encryption than promised. Those were allegations that ended in a settlement. The point for an operator is narrow: a label has to match what the product does.
The Incognito litigation has the same shape. The Register reported that the settlement requires Google to "delete and/or remediate billions of data records" reflecting class members' private browsing activities. And in September 2024 the FTC said "there is no AI exemption from the laws on the books."
What Team-X changed
v3.5.0 makes three paths check the tier at the moment of the call: the provider factory, every embedding call, and external runtime profiles. A change to the setting applies to the next call, with no restart.
A provider above the tier is refused with a PrivacyTierViolationError that names the provider, both tiers, and the way out. The run fails before any API key is read or process spawned. It is never silently swapped for another provider, because a silent swap hides the policy that just fired.
The shared rule fails closed. A provider tier the code does not recognize ranks as least private. A corrupted max tier ranks as Local Only. That is the engineering form of what OWASP's secure product design guidance calls establishing secure defaults and failing securely.
| Control | Problem | v3.5.0 action |
|---|---|---|
| Local Only privacy tier | Drew a flag; nothing read it | Enforced on every model call |
| Streaming Responses, Multi-Turn Planning | Read only by code the app never calls | Deleted |
| Max Tokens, Temperature | No provider adapter accepts either | Deleted |
team-x-ai CLI | Every command printed fabricated output | Deleted |
| Cloud link, invites | Green Linked lamp for a reserved link | Labeled Preview, local only |
Why deletion beat fixing
Fixing a control means building the capability behind it. For token caps and temperature that means changing the provider stream contract, which is a project, not a patch. A deleted setting costs a user nothing they had. A fake one costs trust the first time someone notices.
The same discipline applies to evidence. The release adds tests that pin the wiring: one fails the build if any provider factory, embedding adapter, or runtime resolver in the boot sequence is built without the tier getter. Others assert the removed controls stay absent. They are source pins, so they prove the argument is passed, not that no fourth path exists. The behavioral suite for the factory covers the refusal itself.
The governance angle
Data protection by default is not a slogan in Europe. GDPR Article 25(2) requires that by default "only personal data which are necessary for each specific purpose of the processing are processed." A default that is displayed but not enforced does not meet that sentence.
Usability research points the same way. Nielsen Norman Group's first heuristic says the design should always keep users informed about what is going on, through appropriate feedback. An indicator reporting "allowed" over a setting nothing enforces is feedback about the wrong thing.
What I still will not claim
The changelog says v3.5.0 ships unsigned installers because no signing credentials are configured yet, and the release notes say so. The enforcement list is the three paths above. A path outside them that reaches a model is a bug I want reported. Existing users also face a behavior change: employees on cloud providers under a stricter tier now stop with a refusal instead of quietly using the cloud.
What an operator should do this week
- Inventory every setting in the AI tools you run and ask the vendor which function reads each one.
- For privacy and data-residency controls, ask for a test that proves a violation is refused, not a screenshot of the toggle.
- Require that unknown or corrupted values fail to the restrictive state.
- Delete internal settings that no code reads. Removal is a feature.
- Treat any control label as a statement your company may have to defend.
The full engineering account, including the code and the guard tests, is in the Team-X post.
-Rocky
#TeamX #AIGovernance #DataPrivacy #EngineeringDreams #StrategiaX
Originally published on Team-X Blog.