How 'undetectable' AI overlays work (2026)
By The Assistly team ·
"Undetectable" is one of the most overused words in the AI-assistant market. Every tool claims it. Almost none of them explain what it means.
So let's do that. This is a technical but readable walkthrough of how these overlays hide, why the mechanism is real, where it quietly breaks, and the second detection layer most people never hear about. By the end you'll be able to read any vendor's "100% undetectable" banner and know what they are and aren't promising.
The core trick: telling the OS "don't capture this window"
Modern operating systems have a built-in feature for keeping a window off the screen-capture buffer. It was originally designed so that DRM-protected video and password fields wouldn't leak into screenshots and recordings. AI overlays borrow the same mechanism.
In plain terms, your screen has two layers:
- What your eyes see: the pixels lit up on your physical monitor.
- What a capture tool sees: the frame buffer that screen recording, screen sharing, and proctoring software read.
Normally those two are identical. The capture-exclusion feature lets a single window opt out of layer 2 while staying in layer 1. The window is right there on your display, but when Zoom, OBS, or a proctoring tool grabs a frame, that window is absent, usually rendered as a black box or skipped entirely.
Both major operating systems expose this capability through different mechanisms:
- Windows has a window-level display-affinity setting that tells the desktop compositor to withhold a window from capture APIs. A window opts in, and the compositor leaves it out of the frames it hands to recorders and screen-share tools.
- macOS has a per-window content-protection setting: the window declares it shouldn't be shared, and the window server keeps it out of captured output.
That is the whole trick. It is not a hack, a kernel exploit, or a virus. It is a documented OS capability that a well-built app calls correctly. When it works, the overlay sits on top of your call notes, your interviewer's video, or your shared code editor, and nobody on the other end sees it in the stream.
Why it works (when it does)
This is robust because it happens at the operating-system compositor level, below any individual app. Zoom doesn't get to choose whether to honor it. Neither does a recorder. They request a frame of the screen, and the OS hands back a frame that already has the protected window removed. The capturing app can't "try harder" to see it, because it never receives those pixels in the first place.
This is why a properly engineered overlay is invisible in a screen share. It is not merely hard to notice; it is not present in the data. That is the verifiable, defensible claim behind the word "undetectable."
The caveats (where it breaks)
Now the part most vendors skip. Capture exclusion is real but conditional. It depends on the OS, the version, and how the capture is being done.
macOS 15 and ScreenCaptureKit. Newer macOS capture paths (ScreenCaptureKit, on macOS 15 and later) can composite all visible windows together before capture in certain modes. That can bypass the older content-protection flags an app might be relying on. If a tool was built against the old behavior and never updated, its "undetectable" overlay can quietly start showing up after an OS update. This is the single biggest reason "undetectable" is an ongoing engineering commitment rather than a one-time checkbox. It has to be maintained as the OS changes.
Whole-screen vs single-window sharing. Exclusion can behave differently depending on what is being shared. Sharing one specific window behaves differently from sharing the entire display, and the protection that holds in one mode can leak in another. Some coding-tool vendors openly admit this. LeetCode Wizard's own docs, for example, acknowledge that some screen-share software can bypass its hide mode and recommend reading answers off a separate phone instead. Interview Coder users have reported that on macOS, Zoom's default capture can see the overlay.
The takeaway: invisibility is not a constant. It is a function of how well a tool is engineered and how closely it keeps pace with OS updates. A tool that got it right in 2024 and went quiet can be visible today.
What vanilla video calls can and can't do
Here is a comforting fact that cuts through a lot of marketing fear: a normal Zoom, Google Meet, or Microsoft Teams call cannot detect a third-party overlay or recorder. There is no "screen-recording-detection API" that a regular video call can use to scan your machine. They have no idea what other apps you're running.
On a plain video call, the only risk is behavioral, not technical (more on that below). If you're invisible in the screen share, you're invisible. Nobody is silently scanning your process list during a standard sales call or team meeting.
The other detection layer: process-list scans
Plain video calls are the easy case. Proctored coding platforms are a different animal. HackerRank, CodeSignal, Codility, Proctorio and similar tools are designed to catch exactly this kind of help, and capture exclusion is only half the battle.
These platforms can flag a long list of behaviors: tab and focus switching, copy-paste, "unusually linear" typing, a connected second monitor, and, through an installed agent, virtual machines. CodeSignal has reported that cheating-attempt rates more than doubled to roughly 35% in 2025, so these platforms are investing heavily here.
But the one that defeats most "invisible" overlays is the simplest: the process-list scan. Some proctoring platforms read the list of running applications on your machine and compare it against a blocklist of known assistant names. Your overlay can be perfectly excluded from screen capture and still get caught, because the proctoring agent sees a process named after a popular AI interview tool sitting in your Task Manager or Activity Monitor. You don't appear in the video; you appear in the process list.
This is where renaming matters.
How a renamable app defeats name-based scans
Assistly lets you rename the app and swap its icon/logo. To the OS process list, Activity Monitor, and Task Manager, it doesn't show up as a recognizable assistant. It shows up as whatever you named it. That directly defeats the name-based scans some proctoring platforms (HackerRank, Codility) rely on, because there is no known assistant name in the list to match against.
To be clear: this defeats name-based process matching. It is not a claim to defeat every behavioral signal a proctoring platform watches for. Renaming hides what the process is called; it doesn't change how you behave.
The tells software can't hide
No overlay, whether invisible, renamed, or otherwise, can fix the human signals. Interviewers who suspect AI help look for:
- Flat latency. A consistent ~3–5 second pause before every answer, as if you're waiting on something.
- Reading eyes. Left-to-right "reading" eye movement while you "think."
- Over-structured phrasing. Answers that sound like documentation: perfectly enumerated, suspiciously complete, oddly formal.
- Collapsing under follow-ups. A flawless first answer, then a freeze when someone digs deeper.
This is also why latency is a real product differentiator and not only a spec. Independent tests measured 5–10+ seconds of latency on some tools versus advertised numbers, and Trustpilot reviewers describe a "latency stare" on others. A tool that streams guidance token-by-token in real time gives you something you can react to naturally. A tool that makes you wait creates the flat-pause tell interviewers are trained to spot.
For a deeper breakdown of what interviewers catch (and the famous "caught" cases that were not caught by detection tech), see can interviewers detect AI.
So what makes an overlay "undetectable"?
Putting it together, real undetectability is the sum of several things rather than one banner:
| Layer | What's needed | What fails without it |
|---|---|---|
| Screen capture | Correct, current use of OS exclusion flags | Overlay appears in the screen share |
| OS maintenance | Updated for macOS 15 / ScreenCaptureKit changes | Worked yesterday, visible today |
| Process list | Renamable app + swappable icon | Caught by name-based proctoring scans |
| Latency | Real-time, low-latency streaming | The flat-pause behavioral tell |
| The human | Your own delivery | Reading eyes, robotic phrasing |
A tool can ace one and fail the rest. "Undetectable" only means something when it covers the whole stack.
Where Assistly lands
Assistly is built as a native desktop overlay for macOS (Apple silicon, macOS 13+) and Windows 10/11, not a browser tab or extension that gets captured along with the page. The overlay is excluded from screen capture at the OS level, so it stays out of recordings, screen shares, and screen-monitoring tools' frames. It is a native app we maintain against OS changes rather than a flag we set once and forgot.
For the process-list layer, you can rename the app and replace its icon so it doesn't surface as a recognizable assistant in Activity Monitor or Task Manager. It captures the call's own audio (so headphones are fine), separates your voice from others, and streams guidance in real time, which keeps you out of the flat-latency tell. Both plans include every feature: Free gives you 3 sessions a month (15 minutes each, no card), and Pro is $14.99/month for unlimited, untimed sessions. There is no separate "undetectability" tier; it is how the app works.
One note: we built Assistly to help you be prepared and present, and it should be used within the rules of any meeting, call, or interview, respecting recording-consent laws. You control your data and can delete sessions and notes at any time.
Want to see how Assistly compares with the rest of the field on these criteria? Read the most undetectable AI assistants, or check can interviewers detect AI for the full picture on getting caught.
Ready to try a well-engineered, renamable overlay for yourself? Sign up for Assistly free, no card required.