The Layer No Standard Audits
How renaming a capability reroutes it past the control that watched the old name
A capability can be described in two ways. Under the first description it would not survive review: it reads what is typed, captures what is shown, holds the credentials, and acts without the person at the keyboard. Under the second it is shipped, demonstrated, and praised. Both descriptions refer to the same capability. Only the name has changed — and with the name, the verdict.
This is rarely deception in the narrow sense. The flattering description is usually accurate as far as it goes. The problem is that the name has been left to do the work the analysis was supposed to do, and the analysis is then never run, because the name has already settled it.
One capability, three names
Three instances from the public record make the shape visible. None is unusual; that is the point.
A browser was found to write a multi-gigabyte language model to the device with no consent prompt, reinstating the file when a user deleted it. The capability was framed as on-device privacy. Forensic examination showed that the prominent feature presented to the user routed its queries to remote servers regardless — the storage and bandwidth were borne locally, the privacy was not delivered. Filed under on-device, the install slipped past the consent that silent download onto the user's machine would have demanded.
An operating-system feature captured the screen at short intervals and indexed the result, so that anything once displayed could be retrieved later. Presented as a memory aid, it was assessed on release as a surveillance database in waiting, and was subsequently constrained to off-by-default with presence checks after sustained objection. The mechanism — continuous capture of everything shown, including everything typed into it — is the mechanism that, under a different name, every endpoint policy is written to detect and remove.
Robotic process automation reads application screens, injects keystrokes, and authenticates with stored credentials to act as a user. It is filed under transformation, not threat. Yet the same bot, examined rather than named, authenticates with standing credentials and acts unattended, holding access the human role it replaced never had without a person present. The mechanism is screen-scraping, keystroke injection, and credential use. Under one name that is spyware. Under another it is a digital worker.
What the name is doing
Controls are bound to names. An endpoint policy watches for keyloggers and screen capture. A data-protection review is triggered by collection and monitoring. A procurement gate fires on surveillance. None of these controls inspects a data flow directly; each inspects the category the flow has been filed under. The category is supplied by the name.
Rename the capability and it is re-filed. The flow is unchanged, but the control that watched the old category no longer fires. The name — not the architecture, not the data flow — has become the operative access-control layer. It is also the one layer that no standard requires anyone to audit.
That layer has a further property worth stating plainly: it is set by the party with the least incentive to classify accurately. The owner of the capability chooses its name. The reviewer inherits it.
The reading no standard requires
One move exposes the substitution. It carries no clause number, and it is cheap.
The rename-and-re-vote test: take a capability that has already been approved, describe it again in plain, unflattering terms — the words its least friendly competitor would use — and put the approval back to the vote. If the verdict moves, the vote was cast on the name. What was approved was a description, not a capability.
The instrument is not the discovery. The effect it relies on — that a description can move a decision the underlying facts do not — is the framing effect, set out by Kahneman and Tversky decades ago, and every governance review is exposed to it. What is new is narrower: the discipline of running the re-description on purpose, inside the approval, before the signature rather than after the incident.
What governs was never the name. It is consent, legitimate authority, accountability, and proportionality. A capability earns approval by satisfying those, in whatever words it happens to arrive in. A capability that fails them fails them under every name it is given. The work is to read the flow and not the label — and that work is precisely what the renaming is built to make feel unnecessary.
The asymmetry is not that the supplier holds the power. It is that the supplier's power works only while it goes unread. The name on the capability is chosen by the party that benefits from the classification; the signature under the approval belongs to the party that inherits the risk. Between the two sits the one control the rename is designed to pass — the reader deciding whether feature or finding applies. Where the rename succeeds, it has not defeated a system. It has been signed for.