
A Log Is Not A Control
November 2026
Written by: Chuck Doerr
Boards have started asking where the data goes when someone in the firm uses AI. There are two ways to answer. One is to show what happened: the prompt, the destination, the session, all recorded after the fact. The other is to show what could not have happened, because the request was never allowed to touch it. Most security programs are built to give the first answer. Boards are asking for the second.
The usual answer is telemetry, and it is a reasonable place to start. A well-run program can produce the prompt, the destination endpoint, and the authentication on the session. Data loss prevention (DLP) tools and cloud access security brokers (CASBs) have produced that same evidence for years. It matters, since investigations and audits depend on it. The limitation is timing, because all of it is collected after the request has been assembled. A log can tell you that a CRM record left, and roughly how, but it cannot show you a record that never entered the request because the request was never allowed to touch it. The first is forensics and the second is control, and a fair number of programs are running the first while reporting it as the second.
Consider an analyst on a coverage desk. She has a client email open in Outlook, the client’s Salesforce record beside it, and a proposal draft in a third tab, and she wants a summary drawn from all three. She should be able to ask for it without copying each document into a chat window, since everything she needs is already on her screen.
Now consider what the network sees when she asks. A proxy or CASB, if it sees the request at all, sees an encrypted HTTPS POST to an approved endpoint, with the payload already packaged by the time it reaches the inspection point. TLS inspection does not change that; it opens the envelope, but the contents were decided before the envelope was sealed. The proxy cannot tell you which tabs contributed, what she typed or pasted locally, or what was removed before the call left her machine, because those decisions were made earlier and somewhere else.
Those decisions were made in the browser, because the browser is where the request is built. Her work no longer sits in a single application; it sits across several, open side by side, and the AI request is assembled from whichever of them policy allows. Only the place where those applications are open together can decide which of them contributes. That is where the control belongs. An administrator names the applications that may participate, and content from any application left off the list never enters the request. Fields an administrator marks as sensitive, an account number or a client identifier, are stripped before the prompt is sent. The decision happens on the endpoint, while the data is still local, rather than being reconstructed from a log after the fact.
The control also has to fit the way she works. I have started describing it as a well-lit path, and the path has to run through the work she is already doing, or she will step off it. If the approved model cannot see the tabs on her screen, she will paste them into a tool that can, usually a personal account in a browser the firm does not govern. A control that blocks the job creates the leak it was written to prevent.
We built HERE around this problem. HERE is a governed browser that runs only a firm’s authorized work apps, and its controls apply across the whole browser rather than to any single AI tool. Security teams decide which applications can pass content to an AI tool, whether that is the firm’s ChatGPT Enterprise open in a tab or the AI Center built into HERE, and that policy is applied on the device before anything reaches a model. The same scrutiny applies to what the user types. HERE monitors prompts in any chat interface running inside it, so if the analyst pastes a client’s account number or Social Security number into ChatGPT, the firm can block the prompt outright or alert her before she sends it. Application policy governs the context pulled in from her tabs; prompt monitoring covers what she adds by hand, which is the part no proxy downstream will ever see.
The AI tools themselves are the firm’s own instances: its contracted tenant of Claude Enterprise, ChatGPT Enterprise, Google Gemini, Microsoft Copilot, or a model it runs itself, under whatever data handling terms it has already negotiated. The request goes to that instance and nowhere else, so the data stays inside the firm’s own agreement, not a public endpoint. Because the controls sit in the browser, the policy stays the same when the firm changes which instance it authorizes. What the policy allows is what the model receives; what it does not allow never enters the request, and the audit record shows which was which, including every prompt that was stopped or flagged.
A program that can walk a board through that scene, tab by tab, showing what the analyst asked for and what the policy let through, is answering the question the board asked. A program that can only hand over the log is still investigating.
See HERE in action.
Suggested additional reading

The Human Interface Disruption
The SaaSpocalypse aimed at the wrong target: AI won't replace your systems of record, but it can replace the one-size-fits-all interfaces your teams struggle with every day.
Read more -->