A privacy toggle is a sign, not a lock

Every prompt you send to a hosted AI assistant leaves your trust boundary the moment it crosses the network. That is true of Grok 4.7 and true of every competing assistant that runs inference on vendor infrastructure. The security-relevant question is not whether a privacy feature exists. It is whether that feature is enforced by a boundary the vendor cannot cross without your authorization, or whether it is a policy statement the vendor can revise. Those are two different classes of control. Risk assessments fail at the point where they treat them as equivalent.

A privacy feature is a surface. Toggles, opt-outs, retention windows, and statements such as ‘we do not train on your data’ are all features. A control is something else. A control is a boundary that changes what is technically possible, not only what is permitted. Most consumer AI assistant privacy features are policy controls. The specific enforcement model behind Grok 4.7’s privacy settings is not confirmed. The enforcement model behind most competing assistants, read from vendor claims alone, is also not confirmed. What is confirmed is the shape of the problem: data crosses into vendor-operated systems, and something governs what happens next.

The comparison that matters is not a feature checklist. It is the location of the enforcement point. Client-side, where your device holds the boundary. Vendor-side under contract, where a written agreement binds the processor. Vendor-side under policy, where the vendor’s discretion is the only limit. Identity is the boundary in each case. If your account, not the vendor’s judgment, determines whether your input is retained or used, that is a control. If the vendor can change the outcome without your action, it is a promise. This analysis reads Grok 4.7 and its peers against that distinction, not against the length of their privacy pages.

The default assumption, held by individual users and procurement teams alike, is that a documented privacy setting is a technical guarantee. Turn off training. Set a retention limit. Select the private conversation mode. The assumption is that these settings sit between your data and the vendor’s other systems, and that changing them changes what the vendor’s infrastructure can do, not merely what its policy says it will do. The setting is treated as the boundary. The label is treated as the enforcement.

That assumption drives how these tools get compared. Teams evaluate Grok 4.7 against other assistants by placing privacy feature lists side by side. More toggles, finer retention granularity, and stronger reassurance language win the privacy column. The unstated belief is that the count and presence of features correlates with the strength of protection. It does not. A feature list states intent. It does not state where the input actually travels, which internal systems read it, or who can override the setting. Two assistants with identical feature lists can enforce them at entirely different points, and nothing in the list exposes that gap.

The assumption also carries a trust-continuity error. Users assume that a setting, once chosen, holds. That a ‘do not retain’ choice made today governs data processed tomorrow. That a model update does not silently change the processing path underneath the same toggle. Whether any specific assistant preserves setting state across model versions and infrastructure changes is not confirmed by the existence of the setting. Persistence of a control is a separate property from the existence of a control. Treating the two as one is how a privacy posture is assumed to be stable when its stability was never verified.

What changed is the category. Assistants stopped being stateless question and answer endpoints. The current generation retains memory across sessions, calls external tools, executes multi-step tasks, and in some deployments operates with standing access to accounts and data sources. Each of those capabilities is a new path for your input to reach a system beyond the model. Whether Grok 4.7 ships any specific one of these capabilities, and in what default state, is not confirmed here. The category shift is the point, and it applies to the whole field, Grok 4.7 included.

This changes what a privacy setting means. A ‘do not retain’ toggle on a stateless assistant governs one thing: transcript storage. The same toggle on an assistant with a memory feature, tool access, and agentic execution governs a fraction of the data flow. Memory writes, tool-call payloads, and downstream system logs are separate surfaces. A single privacy control does not necessarily reach all of them, and the feature list will not tell you which surfaces it covers. Whether one setting reaches every surface, for any given assistant, must be verified per surface. It cannot be assumed from the presence of the setting.

The comparison frame changes with it. Measuring Grok 4.7 against other assistants on retention toggles alone measures the smallest surface. The surfaces that now carry the most exposure are memory persistence, tool-call data handling, and the identity boundary around agentic access: what the assistant can reach, under whose credentials, and whether that access is scoped and revocable. Those are enforcement questions. Vendor feature lists describe them. Vendor feature lists do not, on their own, confirm them. Enforcement is what the rest of this analysis measures.

The failure occurs at a single point. It is the moment an assessment assigns a privacy feature a protection value without locating the enforcement point behind it. A feature list presents a toggle. The toggle presents an outcome: do not train, do not retain, keep this conversation private. The outcome the user observes is the label. The outcome the vendor infrastructure produces is not observable from the user position. Between the label and the infrastructure sits the enforcement point, and the feature list does not state where it is. The assessment fills that gap with an assumption. It treats the label as the enforcement. That substitution is the mechanism.

Once the substitution is made, every downstream conclusion inherits it. A privacy comparison that ranks Grok 4.7 against other assistants by counting toggles has already assumed each toggle enforces where its label claims. It has not verified that any of them do. When data crosses the network into vendor-operated systems, what governs it next is the enforcement point, not the label the user selected. If that point sits vendor-side under policy, the vendor can produce a different outcome without the user acting. The label still reads the same. The observable state on the user device does not change. The failure is silent because nothing the user can see reports the difference between a control the vendor cannot cross and a policy the vendor can revise.

For Grok 4.7 the enforcement model behind its privacy settings is not confirmed. For the competing assistants, read from vendor claims alone, the enforcement model is also not confirmed. This is not a gap to be filled with a plausible answer. It is the condition. The mechanism of failure is not that one assistant enforces poorly and another enforces well. It is that the comparison method cannot see enforcement at all, and produces a ranking anyway. A ranking built on an unverified enforcement point is a ranking of labels. It carries no information about what the vendor infrastructure can do with the input after it crosses the boundary.

The pattern is general. Any control whose enforcement point is not visible to the party relying on it is a control that party cannot verify, and an unverifiable control is indistinguishable from a promise. This holds regardless of vendor, feature count, or the specific wording of a privacy page. Identity is the boundary. The operative test for every privacy setting is whether the account holder action, and only the account holder action, determines the outcome. If the vendor can change what happens to the input without the account holder doing anything, the account holder never held the control. The setting was a display of the vendor current intent.

The same mechanism repeats across every surface the current assistant generation added. A retention toggle governs transcript storage. Memory persistence, tool-call payloads, and agentic access each have their own enforcement point, and each is invisible from the feature list in exactly the way the retention toggle is. Whether one setting reaches all of them, for Grok 4.7 or any peer, is not confirmed. The pattern does not change with the surface. A memory write governed by policy is as revisable as a transcript governed by policy. An agentic action taken under standing user credentials reaches whatever those credentials reach, and whether that access is scoped and revocable is an enforcement property, not a feature-list property. More surfaces means more enforcement points that the label method cannot see.

This is why a longer privacy page and a larger toggle count do not raise protection. They raise the number of claims. Each claim adds an enforcement point the relying party has not located. The exposure scales with the feature list, not against it, because every additional feature is another outcome the vendor states and the user cannot observe. Two assistants with identical feature lists can enforce at entirely different points, and the list will report them as equal. The pattern is that feature comparison and enforcement verification are different measurements, and only one of them describes what the infrastructure can do with your input.

Define what must now be true. A privacy feature is not confirmed as a control until its enforcement point is located. That applies to Grok 4.7 and to every assistant it is compared against, without exception. The one confirmed fact across the field is the shape of the problem: input crosses into vendor-operated systems, and something governs what happens next. Everything past that point, for every named product, is either directly stated by the vendor under a binding the user can enforce, or it is not confirmed. Treat the second case as the default until the first is demonstrated.

Controls that are not enforced are not controls. A setting the vendor can revise without the account holder action is a policy statement rendered as a switch. Record it that way. Do not place it in the control column. The location of the enforcement point is the entire measurement: client-side, where the device holds the boundary; vendor-side under contract, where a written agreement binds the processor and the user can enforce it; or vendor-side under policy, where vendor discretion is the only limit. Grok 4.7 placement on that scale is not confirmed here. Neither is any competitor placement from feature text alone. The scale is the instrument. The feature list is not.

The procurement decision does not turn on which assistant lists more privacy features. It turns on which enforcement points you can verify and which you cannot, surface by surface, under whose identity the assistant acts, and whether that access is scoped and revocable by the account holder rather than the vendor. Where the answer is not confirmed, the correct entry is not confirmed, and a not-confirmed enforcement point is a risk you are accepting, not a control you are holding. If a system allows an outcome, that outcome will occur. Rank the assistants by what their infrastructure can do with your input, not by what their settings say it will. Anything else is a ranking of labels.