macOS 27: Audit What an Interview App Can Record

On macOS, what an interview or assessment application can observe is decided almost entirely by four privacy permissions: Screen & System Audio Recording, Camera, Microphone, and Accessibility (with Input Monitoring and Automation as close relatives). macOS 27 Golden Gate, which Apple released in September 2026, changed how some of those permissions get granted on managed Macs and added a way to list what has already been authorized. This article covers how to read that list before an interview, what each permission actually enables, and what the audit cannot tell you.

What each permission lets an app do

These panes live under Apple menu > System Settings > Privacy & Security. Apple's own guidance for the capture pane is explicit that it covers two different things: "You can allow apps to record both your screen and audio, or just your audio" (Apple, Control access to screen and system audio recording on Mac).

The practical consequence is that Accessibility and Input Monitoring are the permissions worth the most scrutiny. Screen recording captures what is on your display; Accessibility lets an application watch and act on everything else. Apple's own macOS 27 release notes describe the Accessibility grant in exactly those terms, saying the user is notified that the app "can access their data, monitor their keyboard and websites, record their screen, and more" (Apple, What's new for enterprise in macOS Golden Gate 27, published 28 September 2026).

What macOS 27 changed

Three changes in macOS 27 matter if you are deciding what to install or which machine to interview on.

Managed Macs can no longer silently grant Accessibility. Historically, an administrator could set Accessibility, Camera, Microphone, Bluetooth, and Speech Recognition to allowed through a Privacy Preferences Policy Control profile, and the app simply had the access. Those keys are deprecated in macOS 27; an administrator can now specify default values, but the user still has to approve them through a consolidated consent prompt that names the organization, the app, and the administrator's justification, as analysed by Apple Premium Business Partner Too Corporation in its breakdown of the deprecated PPPC services. Apple's enterprise notes add that where the deprecated Accessibility key is still applied, "the user is shown a notification once for each configured app so they are aware the app can access their data," and that users can disable accessibility permissions granted by device management in System Settings.

There is now a command that lists authorizations. Apple documents that "the new tccutil list command can report current privacy authorizations for specified services or apps on managed devices." Note the documented scope: managed devices. tccutil previously existed mainly to reset permissions, not to enumerate them, so this is a genuine addition rather than a rediscovered flag. Treat the System Settings panes, not the command, as the reliable audit path on a personal Mac.

Apps can no longer read the permission database directly. Apple states plainly that "apps can no longer access the local TCC database directly." Tools that used to infer the full permission map by reading that database need a supported interface now, which is relevant if you previously relied on a third-party utility to produce that inventory.

How to audit your Mac before an interview

1. Open Apple menu > System Settings > Privacy & Security.
2. Work through Screen & System Audio Recording, Camera, Microphone, Accessibility, Input Monitoring, and Automation in turn, and read the app list in each.
3. Note anything you do not recognise, and anything that an employer's device management put there. On macOS 27, items that arrived through device management can be turned off from System Settings.
4. On a managed Mac, expect a consolidated consent prompt the first time a newly deployed app launches. Reading the justification text is the one moment you see what the administrator says the app is for.
5. Leave the audit until shortly before the interview. Permission state changes whenever you install something.

Two warnings about step 3. Revoking Screen & System Audio Recording from a proctoring client right before a test will usually stop the test from starting, and the vendor's support flow, not yours, decides what happens next. And on macOS, denial can be sticky: Pearson's candidate requirements note that if access is refused, OnVUE "will not ask again. The candidate must then allow access manually in System Settings" (OnVUE Candidate Tech Requirements v.26.7.1, July 2026).

What assessment applications actually ask for

Vendor documentation is the fastest way to know what a specific client wants before you install it.

HackerRank's candidate support instructions for its desktop app tell macOS users to allow camera access and to allow access to System Events, alongside screen recording and accessibility access, and describe the app as blocking "unauthorized activities such as accessing other applications, browsers, or tabs" (HackerRank, Attempting Tests using HackerRank Desktop App). That combination is what makes a full-screen lock possible; it is also why the client appears in the Accessibility pane. The same documentation tells candidates to close other applications and confirm no additional monitors are attached, which lines up with the HackerRank desktop app requirements and what it blocks.

Pearson's OnVUE requirements are narrower on paper: "Allow OnVUE in the privacy settings for Microphone and Camera. OnVUE may also need access to Automation and Input Monitoring," plus an unambiguous "Multiple monitors are not allowed."

Both are desktop clients, and that is the distinction that matters. A native client can request these permissions; a browser-based assessment cannot, which is why its visibility into your machine is bounded by what the browser exposes. If your assessment runs in a tab rather than an installed app, the relevant question is a different one, covered in what interview websites can see about other running apps and in the broader case for assessments delivered as a desktop application rather than a website.

What a permission audit cannot tell you

A permission list describes capability, not activity. Being listed under Screen & System Audio Recording means an app is allowed to capture; it does not record when it did so, how often, or what it sent anywhere. macOS gives you the indicator in the menu bar during active capture and periodic reminders about apps holding the permission — TechRadar reported the reminder cadence moving from weekly to monthly in macOS 15 Sequoia — but neither is an audit log you can review afterwards.

Three further limits are worth stating plainly:

• Device management still configures a great deal beyond these five deprecated keys. "Accessibility can be disabled by the user" is not the same as "your employer's Mac is not monitored."
• The panes are per-app, not per-feature. An app that legitimately needs screen access for one function holds the same grant for every other function.
• A clean audit says nothing about the assessment platform's server-side analysis of what it legitimately collected. Keystroke timing, paste events, and focus changes can be gathered inside a browser session with no macOS permission at all.

Where a desktop assistant sits in the same list

Any desktop AI interview assistant, Control included, appears in these panes for the same reason a proctoring client does: it needs capture permissions to function. Control documents itself as a desktop-native overlay for Windows and macOS that captures real-time audio and user-triggered screenshots, delivers answers through global hotkeys, and does not take focus from the interview application. Its screen-share behaviour is stated with a scope rather than as an absolute: Control's site describes testing against Zoom 6.16 and earlier and browser-based screen recording as of September 2026, which is a claim about those clients and versions, not a general property. If you are weighing that class of tool, the candidate privacy checklist for AI interview assistants sets out the questions worth asking of any vendor, Control's answers included.

The symmetry is the honest conclusion here. The permissions that let a proctoring client lock your screen and the permissions that let an assistant read it are the same permissions, and macOS 27 makes both of them easier to see.

What to do before your next interview

If the interview involves installing a vendor client, read that vendor's own permission list first, then check the panes afterwards to see what it actually took. If you are interviewing on a Mac your employer manages, assume the audit is incomplete and treat a personal machine as the cleaner option where the format allows it. If you are evaluating a desktop assistant, apply the same scrutiny you would apply to a proctoring client, and prefer vendors that state scope and dates instead of absolutes.

Control offers a small free allowance — 5 messages and 2 minutes of voice, per Control's site as of 1 October 2026 — which is enough to see what the application requests and how it behaves on your own machine before any interview depends on it.