What Actually Hides an AI Assistant During a Screen Share (And What Does Not)

Windows has had an API for this since May 2020. SetWindowDisplayAffinity, called with the WDA_EXCLUDEFROMCAPTURE flag, tells the compositor to leave a window out of anything that captures the screen, and it landed in Windows 10 version 2004 (Microsoft Learn). macOS has had its own version of this for longer, exposed on NSWindow as a sharing type (Apple Developer).

Neither API was built for interview candidates. They exist because video players with DRM contracts and password managers asked for them. That is the entire technical basis of every “undetectable” claim in this category, and my honest opinion is that the marketing around it is worse than the underlying technology deserves. The technology is real, well documented, and pretty boring. The marketing is usually none of those things.

So this post is an attempt to say what a screen-share safe AI assistant actually does, where the guarantee stops, and which parts of the problem no API solves. I work on one of these tools, which you should factor in. I’ve also spent enough time staring at the failure modes to be less confident than our own landing page.

What “screen-share safe” actually means

A screen-share safe AI assistant is a window the operating system refuses to include in screen captures. The app asks the OS to exclude it, the compositor honors that at the point where the frame is assembled, and every capture path on the machine gets a frame with the window missing. It is enforced by the OS, not by the meeting app, which is why it holds across Zoom, Teams, Meet, and any recorder.

That last part matters more than people realize. The exclusion isn’t negotiated with Zoom. Zoom asks the OS for the screen, and the OS hands back a composited image that never contained the window in the first place. Zoom has no way to know something was withheld, because from its side nothing was withheld. It got a screen.

This is also why the guarantee doesn’t depend on which meeting platform you use, and why “works with Zoom” is a slightly odd thing for a vendor to advertise. There is nothing Zoom-specific to support.

Why a browser extension cannot do this

An extension renders inside the page, and the page is the thing being captured. When you share a tab or a window, the browser hands over that surface, including every element an extension injected into it. There is no OS-level window to exclude, because the extension doesn’t own a window. It owns some DOM inside yours.

You can find extensions that claim otherwise. What they usually mean is that they render into a popup, or a separate small browser window, which you then have to remember not to share. That is a workflow rule, not a technical guarantee, and workflow rules fail at exactly the moment you’re under pressure. We wrote a longer comparison in desktop AI assistant vs browser extension if you want the architectural version.

The two operating systems do not behave identically

The Electron abstraction is genuinely nice, and it also hides a lot. Setting transparent: true on a Windows window, for instance, makes Electron drop the thick frame, which is the style Windows uses to draw resize borders. The result is that resizable: true quietly stops doing anything. We shipped that bug. Users on Windows couldn’t resize the overlay at all, and nothing in the code looked wrong, because the flag that broke it was three properties away from the flag that appeared broken.

What content protection does not protect you from

Here is the part vendors tend to skip, and I think it’s the only part worth reading carefully.

Content protection hides a window from capture APIs. It doesn’t hide anything else about your machine or your behavior. Specifically, it does nothing about:

• A phone pointed at your monitor. Obvious, and still the most common way this gets caught.
• Proctoring software that enumerates running processes. Locked-down assessment platforms often don’t need to see your screen. They can list what is running. Content protection is invisible to a capture, not to a process list.
• Your eyes. People read. Reading moves your gaze in a way that’s different from thinking, and interviewers on video calls are looking directly at your face for forty minutes.
• The cursor. This one is genuinely non-obvious and it cost us something to learn.

The OS draws the mouse cursor into the captured frame separately from window contents. So the window can be perfectly excluded while the cursor sitting on top of it is captured normally. When we ported resize handles onto the Craqly overlay, the natural thing to do was give those handles a resize arrow, the way every application does. That would have meant a resize arrow appearing over empty desktop, changing shape as it crossed the boundaries of a window nobody else could see. A cursor doing that is a much louder tell than a visible window would be. Someone would just think you had a notes app open. Nobody has a theory for why the arrow keeps turning into a resize handle over blank space.

So the grips keep the default cursor on purpose. It makes the app feel slightly worse to use, and we picked that trade deliberately. I don’t think most tools in this category have thought about the cursor at all, though I could be wrong, and I haven’t tested every competitor’s build on this specific behavior.

What we actually ship

In Craqly the overlay window calls setContentProtection(true) once, at the window level, in the main process. It isn’t per-mode, and it isn’t per-feature. Interview, Sales, Pitch, Meeting/Notes, and Recruiting all run in the same window and inherit the same protection, which is why we describe it as a property of the overlay rather than a feature of a mode.

It also defaults to on. The config key is read at window creation and content protection is applied before the first paint, because toggling it after the window is visible produces a brief flicker where the window is capturable. A flicker is a small thing that happens at the worst possible moment, so it’s worth the extra care at startup.

The rest is unremarkable and probably should be. There is no bot joining your meeting, no participant named after the tool, and no browser surface to leak. It runs as a desktop app, captures system audio locally, and stays out of the frame.

Where I would push back on our own category

If your threat model is a recorded interview reviewed later by a hiring team, OS content protection genuinely solves the capture problem, and it does so at a layer that no meeting app can inspect. That is a real technical property, not a marketing claim, and you can read the API docs yourself.

If your threat model is a proctored assessment with an agent installed on your machine, none of this is the right tool and no vendor should be selling it to you as one. I would rather say that plainly than let someone find out during a real test.

And there’s a broader question I genuinely can’t answer, which is how long the OS-level exclusion stays available in its current form. It exists because DRM and credential managers need it. If the platform vendors ever decide the tradeoff has shifted, the API changes and every tool in this category changes with it. Nobody building on top of it, us included, controls that.

If you want the practical version rather than the architectural one, we covered which tools hold up under a real share in screen-share safe interview tools, and the narrower Zoom-specific behavior in invisible screen share. Craqly’s overlay is free to try on the Starter plan with 20 credits a month, which is enough to see whether the thing disappears on your own machine, which is the only test that should convince you.