ProctorTrack and AI overlays, a technical breakdown

ProctorTrack is Verificient's proctoring product. It is delivered as a downloaded application that runs alongside your LMS, most often Canvas, Blackboard, Moodle, or D2L. The student installs the app, runs through a system check, completes a biometric enrollment, and then sits the exam while ProctorTrack records video from the webcam, audio from the microphone, and a recording of the screen. Review happens after the fact by a mix of automated flags and human reviewers.

On macOS the app asks for the same set of permissions any screen-recording app does. Screen Recording for the display capture, Camera for the webcam feed, Microphone for audio. The biometric piece is the part most schools talk about in their student-facing docs, because it is the most visible difference from older proctors that only watched the screen. Everything the app records is uploaded to Verificient's servers for scoring and review.

The screen recorder uses the same macOS APIs as any other capture tool. On modern macOS that means ScreenCaptureKit, which is the system framework Apple introduced to replace the older CGDisplayStream path. ScreenCaptureKit hands the application frames from the compositor, one frame per requested interval, and the application encodes those frames into video. The capture happens at the display level, which is the same level Zoom screen share, QuickTime recording, and OBS operate at.

The webcam stream is a separate pipeline. ProctorTrack runs the video through a face-detection model in near real time, looking for a few specific signals. Whether a face is present in frame at all. Whether the face matches the enrolled biometric. Whether the head turns away from the screen for sustained periods. Whether a second face appears. Those signals get timestamped and attached to the session for a human reviewer to look at later.

Audio is captured for review but is not usually the primary flag source. Reviewers can hear the room, which is the relevant thing for them, but the automated scoring pass leans on the visual signals first.

A common search is whether ProctorTrack catches a second monitor. The honest answer is that it asks the operating system how many displays are connected, during the pre-exam system check. If two displays are attached, the system check warns the student and most institutions configure the exam to refuse a start until the student disconnects the extra display. This is a hardware enumeration, not a clever runtime detection. macOS exposes the number of attached CGDirectDisplayIDs through the standard CoreGraphics calls, and the proctor reads that list.

What this means in practice: if you have a single display connected at launch, ProctorTrack records that one display. If you connect a second display mid-exam, behavior depends on the institution's configured policy. Some configurations will flag the session, some will pause it, some will do nothing visible at the moment and surface the event for the post-exam reviewer. None of this is overlay detection. It is display count detection.

The Whisply overlay does not change the display count. It draws into the active display the user summons it on, as a floating window. It is not a virtual monitor and it does not appear as an extra display to CoreGraphics. The question of whether ProctorTrack sees an overlay is a separate question from the second-monitor question, and the answer to the overlay question lives further down this page.

A screen recorder records what the compositor renders into a captured frame. On macOS, every NSWindow has a sharingType property. The default is NSWindowSharingReadOnly, which means the window shows up in screenshots, screen recordings, and screen shares. The other option is NSWindowSharingNone, which tells the WindowServer to exclude that window from any capture stream initiated by another process. This is the same flag the system uses for password autofill prompts, Apple Pay sheets, and the system caps-lock indicator. It is a documented Apple API.

Whisply uses NSWindowSharingNone for its overlay. The result is that ProctorTrack's screen capture pipeline receives a frame from the compositor with the Whisply window already excluded. There is no extra filtering happening inside Whisply, no race condition where the window briefly appears, no flicker on a slow frame. The compositor itself never composites the window into the captured surface. This is the same reason the Whisply overlay does not appear in Zoom screen share, Cmd+Shift+5 screenshots, or QuickTime screen recordings unless the user explicitly disables content protection.

What ProctorTrack does see is your normal screen activity, your webcam, and your microphone. None of those change because of an overlay. The detection question is therefore narrower than people expect. It is not 'can ProctorTrack see Whisply'. It is 'does the webcam show a person behaving like they are reading from somewhere off-screen'. That is a behavior question, not a software question.

The overlay is a borderless NSWindow that lives above normal application windows but below the menu bar capture surface. It is summoned with Cmd+Return, which is registered as a global hotkey through the Carbon hotkey API. The window content is rendered with the standard AppKit drawing path, the same path any other Mac app uses, which means the OS handles compositing it onto the display surface.

Because the window carries NSWindowSharingNone, every system capture path skips it. ScreenCaptureKit skips it. The legacy CGDisplayStream path skips it. The screencapture command-line tool skips it. The QuickTime screen recorder skips it. A Zoom screen share skips it. This is the system behavior, not a Whisply behavior. We set the flag, the OS does the work.

The overlay also does not inject itself into other processes. It does not hook into ProctorTrack's binary, it does not modify any system frameworks, it does not run as root. It is an ordinary user-space application that uses an ordinary user-space Apple API. The reason this matters is that there is nothing for ProctorTrack to detect even if it wanted to look. Whisply is, from the operating system's perspective, just another well-behaved Mac app that asked to be excluded from screen sharing.

Content protection is a property of the macOS compositor. If a future version of macOS changes how NSWindowSharingNone interacts with ScreenCaptureKit, that behavior could change. Apple has been broadly consistent about respecting content protection because it is the same mechanism Netflix, Apple TV, and the system itself use, so we treat it as a stable foundation, but it is not a contract.

There is also the matter of what the webcam shows. No amount of overlay isolation changes the fact that ProctorTrack is watching your face. If a reviewer sees a person whose eyes are tracking content that is not on the recorded screen, that is a reviewer judgment. The overlay's privacy guarantee is about what gets recorded, not about what gets observed by a human looking at the recording.

And on the institutional side, some schools require a room scan, a second device showing the room from a different angle, or other procedures that sit outside the proctor software. Those are policies the proctor app cannot enforce on its own and that no overlay can address. Read your exam's instructions. The technical answers on this page only describe the software.