A pricing page changed overnight. The word "unlimited" was gone and a monthly cap was in its place. No email went out, no banner appeared in the product, nothing was announced. A subscriber found out on a Tuesday afternoon, mid-task, when the cap arrived.
Nothing broke. There was no outage and no bug. The product worked exactly as documented. The documentation had changed.
Every protection a cloud AI tool offers you is a document. The privacy policy. The retention schedule. The pricing page. The rate limits. The disclosure timeline. The account terms that determine whether you keep having an account at all.
Documents have amendment clauses. The clause usually says that continued use constitutes acceptance of the revised terms, which means the mechanism for changing your protections is that you keep working.
This is not a scandal and it is not unusual. It is how nearly all commercial software works, and for most software it works fine. If a project management tool changes its pricing tiers, you evaluate the new price against the new value and you stay or you leave. The decision is annoying and it is bounded.
The question worth asking is what changes about that arrangement when the thing governed by those documents is not a feature set but the accumulated context of how you work.
In a single week in August, three separate things happened at three separate companies.
A premium tier stopped promising unlimited usage and started publishing caps, with no notification to existing subscribers.
A model's price was raised by roughly 93 percent.
A critical security flaw in a personal AI assistant was disclosed publicly after having been patched eight months earlier.
Different companies, different categories, no connection between them. The structure underneath is identical in all three. A term someone was relying on changed, on a schedule they did not set, through a process they had no part in.
None of these were violations. Each one was the normal operation of an agreement working exactly as written.
A pricing change applies going forward. You pay the new price for the next month, and the months you already paid for are settled.
A data term does not behave that way. When a retention policy or a training-use policy or an ownership clause changes, it can apply to material that was collected under the previous version. There is no copy of your data still living under the old terms, because there is only one copy and it is on their infrastructure.
Consent was given once, at signup, before there was anything to protect. It carries forward through every amendment.
This is the part most people have not thought through, and it is not because they are careless. It is because the context accrued invisibly. Nobody sat down and decided to entrust a vendor with two years of working background. It arrived one conversation at a time, and by the time it was worth protecting, the terms governing it had already been agreed to and revised twice.
The eight month gap in that third item is worth sitting with, because it is the least obvious of the three.
Delayed disclosure exists for legitimate reasons. Patch first, publish second, do not hand attackers a map to unpatched systems. Every serious security team operates this way and it is the responsible practice.
The effect on the user is still the same. For eight months, the people affected had no way to reason about their own exposure, because the information required to reason about it was held by the party that created it.
Timing of disclosure is a policy. Policies are documents. You cannot audit a system you cannot see, and you cannot see a system that is not yours.
An application that makes no network calls has no amendment surface for any of this.
Not because the promise is stronger. Because there is no transfer to govern. There is no retention schedule, because nothing is retained anywhere except on the device. There is no breach disclosure timeline for a server that does not exist. There is no clause about training use, because no text ever arrives anywhere that could train anything.
Briefed stores your context vault on your computer, encrypted with AES-256-GCM. There are no accounts and no servers. A terms of service can be revised at any time by the party who wrote it. The absence of a network call cannot be revised by a document.
The useful property here is that this is checkable rather than promised. Open DevTools, select the Network tab, use the extension, and watch what happens. A privacy policy tells you what a company intends to do with your data. A network trace tells you whether your data moved.
Architecture does not protect you from everything, and any version of this argument that implies otherwise is overselling.
Local storage means the security of your computer becomes your responsibility. Disk encryption, screen lock, who else uses the machine, what happens if it is stolen. Those were someone else's problem in the cloud model and now they are yours. If the machine is lost and there is no backup, the vault is lost with it.
That is a real trade and it is not free. It moves the failure mode from a decision made by a company you do not control to a responsibility that sits with you. What it buys is that both the risk and the remedy are in the same pair of hands.
There is a second limit worth naming. Briefed governs where your context is stored, not what happens after you paste a briefing into an AI. When you send a briefing, you are making a deliberate decision about what that provider receives. The value is that it is a decision at all, made at the item level, rather than an accumulation you never approved and cannot inspect.
Neither limit is addressed by a better privacy policy. That is rather the point.
Briefed is a context vault that runs entirely on your computer. Zero network calls, no accounts, no servers. The vault is encrypted with AES-256-GCM and the key is derived from your password.