What each macOS permission actually lets an app do
Screen Recording, Accessibility, Full Disk Access, and the rest. What they grant, what they don't, and which ones leave no trace.
Screen Recording lets an app capture every pixel on your display, including windows belonging to other apps. Accessibility is narrower in what it can see but far broader in what it can do: it reads the interface elements apps expose and can click, type, and navigate on your behalf.
Most people grant both without knowing the difference. Here is what each permission on your Mac actually covers.
| Permission | What it can read | What it can control | Indicator |
|---|---|---|---|
| Screen & System Audio Recording | All visible pixels, window titles, system audio | Nothing | Yes |
| Accessibility | UI elements apps expose to the accessibility API | Clicks, keystrokes, menus, window position | No |
| Full Disk Access | Mail, Messages, Safari history, backups, other apps' containers | File writes in those locations | No |
| Automation | Whatever the target app exposes via Apple Events | Actions inside that specific app | No |
| Input Monitoring | Keyboard input system-wide, even in the background | Nothing | No |
| Camera / Microphone | Live camera and audio input | Nothing | Yes |
Three of these grant real power with no visual indication that they are being used. That is the part worth understanding.
What Screen Recording actually grants#
It grants pixels. An app with this permission can capture the contents of your display at any time, including windows belonging to applications it has nothing to do with. If a document is visible, it is capturable. If a password field is revealed, it is capturable.
It also gates something less obvious: the list of open windows and their titles. An app without this permission cannot enumerate what else you have open.
What it does not grant is control. An app with Screen Recording can watch, but it cannot click a button, type into a field, or open a menu.
On macOS Tahoe the panel is named Screen & System Audio Recording, and audio is a separate toggle inside it. An app can be granted screen capture without system audio. On Sonoma the panel is simply Screen Recording.
This permission does produce an indicator in the menu bar while capture is active, which makes it one of the more honest ones on the list.
What Accessibility actually grants#
Accessibility exists so that assistive software can operate a Mac on a user's behalf. That means it grants two things: the ability to read the accessibility tree that applications publish, and the ability to send synthetic input.
An app with Accessibility can read the text of a button, find a field by its label, click it, type into it, select a menu item, and move a window. It can observe when focus changes between applications.
What it cannot do is see pixels. If an application draws its interface as an image and exposes nothing to the accessibility API (some games, some remote desktop clients, some canvas-based editors) an Accessibility-based app sees nothing there at all.
The tradeoff is real in both directions. Accessibility sees less of your screen than Screen Recording does. It can do considerably more with what it sees. And unlike Screen Recording, macOS shows no indicator while an app is using it.
What Full Disk Access actually grants#
This is the broadest permission on the list and the one most often granted casually.
Full Disk Access lifts the file-level protections macOS normally applies. An app that has it can read your Mail store, your Messages history, Safari browsing history, Time Machine backups, and the private container directories of other applications. Those locations are otherwise off limits regardless of file permissions.
It does not grant screen capture and it does not grant control of other apps. It is purely about files, but it covers nearly all of them.
Backup software and security tools have a legitimate need for it. Most other categories do not.
What Automation actually grants#
Automation, sometimes shown as Apple Events, is scoped per target application. Granting an app permission to control Mail is a separate decision from granting it permission to control Calendar.
Within a target app, it grants whatever that app chooses to expose through its scripting interface. For Mail that includes reading and sending messages. For Finder it includes moving and deleting files.
Because it is scoped, it is one of the better-designed permissions on macOS. The prompts are specific, and revoking one target does not affect the others.
What Input Monitoring actually grants#
It grants the ability to read keyboard input across the entire system, including while the app is in the background and not focused.
The legitimate uses are narrow: text expanders, custom keyboard layouts, hotkey utilities. The illegitimate use is the obvious one. Of every permission listed here, this is the one to be most reluctant about, and it produces no indicator of any kind.
The permission you might not be able to see#
There is a case where a granted permission does not appear in System Settings at all.
On macOS 26.1, developers reported that plain executables (programs not packaged inside an .app bundle) could request and receive Screen Recording permission and capture the display normally, while never appearing in the Screen & System Audio Recording list. The same behaviour was observed with Full Disk Access. Identical code inside a proper app bundle appeared as expected. The behaviour changed from 26.0.1 and was not documented in the release notes.
The practical consequence: the System Settings list is a record of what asked politely through the front door. It is not a complete inventory of what has access.
This is worth knowing before you treat that list as an audit.
Why Melvin uses Accessibility instead of screen capture#
Building a tool that remembers what you have seen means choosing how it sees. There are two paths.
The capture path
Records the display and reads text back out of the images. It works everywhere. It needs Screen Recording. A recording of your screen exists somewhere.
The accessibility path
Reads the structured content apps already publish. It misses anything an app fails to expose. It needs Accessibility. No recording is created.
We took the second path. It cost us coverage in a handful of apps and it meant cutting OCR as the default way to fill those gaps. What it bought is that Melvin does not ask for Screen Recording on first launch, and no recording of your display is created unless you later turn Vision on yourself.
The easy mistake is thinking that is enough. Electron's desktopCapturer.getSources() asks macOS for Screen Recording the moment you call it, if the status is still undecided. A background timer, a vision fallback, even a launch check can trip that prompt. We found it because a capture path on startup would pop the dialog every time the app opened, before anyone had asked for Vision.
That is how easily an app can request more than the user intended. The API looks like a screenshot helper. On macOS it is also a permission request.
We put a master switch in front of every capture path. Vision is off by default. The visual fallback we call Eyes, and local OCR, cannot turn themselves on if Vision is off, even if an environment variable says otherwise. We never call getSources unless Screen Recording is already granted. Background timers are not allowed to prompt.
How to audit what you have already granted#
Open System Settings, then Privacy & Security. Each permission is its own panel, and each lists the apps that have requested it.
Go through them in this order, since it roughly tracks how much damage each one can do:
- Full Disk Access
- Input Monitoring
- Accessibility
- Screen & System Audio Recording
- Automation
For anything you do not recognise or no longer use, toggle it off. Revoking takes effect immediately for new requests, though an already running capture session may continue until the app stops it. Quitting and relaunching the app is the safest way to be sure.
One caveat worth repeating: apps only appear in these lists after they have requested the permission at least once, and as above, not every granted permission reliably shows up.
Common questions#
Is Accessibility more dangerous than Screen Recording?
They are dangerous in different ways. Screen Recording sees more. Accessibility does more, and does it without an indicator. For a tool you trust, Accessibility is the smaller privacy footprint. For a tool you do not, it is the larger risk.
Does Screen Recording let an app see my passwords?
It can capture whatever is visible, so a revealed password is capturable. Most password managers detect active capture and blur revealed credentials as a defence, but this is a mitigation rather than a guarantee.
Why does an app need Screen Recording just to list my open windows?
Window titles can reveal document names, email subjects, and browsing activity, so Apple gated window enumeration behind the same permission as capture itself.
Can I grant screen capture without system audio?
On macOS Tahoe, yes. They are separate toggles within the same panel.
Does revoking a permission delete data the app already collected?
No. Revoking stops future access. Anything already indexed or stored remains wherever the app put it.
Melvin is a Mac assistant that indexes what you have read and worked on so you can find it by describing it, and runs tasks across your apps. It uses the Accessibility API and a local encrypted index. By default it does not request Screen Recording.