How to manage app permissions on Mac for better security

Every app on your Mac holds a list of things it is allowed to reach - your camera, your microphone, your screen, your files, your entire disk. Each grant you approved once, usually in a hurry, during a first launch you have long forgotten. This guide shows you how to see that list, decide what still deserves to be on it, and take back whatever does not.

You will find how macOS decides what an app can touch, which grants carry the most weight, how to change them in System Settings, how to deal with login items and background agents, and how to audit every installed app in one pass instead of clicking through categories one at a time.

Where to start

This guide covers several jobs. Pick the one that matches what you came for.

What app permissions actually are

Behind every “…would like to access your camera” dialog sits a framework called TCC - Transparency, Consent, and Control. Apple introduced it in macOS Mojave 10.14 and has widened its reach with almost every release since: Screen Recording and Input Monitoring arrived in Catalina 10.15, Local Network in Sequoia 15. Apple’s platform security documentation describes TCC as the mechanism governing access to files, Accessibility, and Automation.

~/Library/Application Support/com.apple.TCC/TCC.db

~/Library

/Library/Application Support/com.apple.TCC/TCC.db

Two rules follow from how the system works, and they answer most of the anxiety around this topic. An app appears in a permission list only after it has asked for that access at least once. The list is a record of requests, not a catalogue of everything installed. And every grant is reversible: switch it off and the app loses that capability until it asks again, which it will do the next time it needs it. Apple’s own security guide confirms that users can review and revoke any permission they have granted.

Terminal has a direct equivalent. The tccutil command resets the approval status for one service, optionally scoped to a single app by bundle identifier:

tccutil reset ScreenCapture us.zoom.xos

One category sits outside all of this. Local Network access, added in Sequoia and carried into Tahoe, runs on a separate mDNS and multicast mechanism rather than TCC, which is why it behaves differently from everything else in the Privacy & Security list. More on that in the next section.

Architecture makes no difference here. TCC behaves identically on Intel and Apple Silicon Macs, including for apps running under Rosetta 2; the same prompts, the same categories, the same database.

The permissions worth auditing first

Some grants hand over a keyhole view. Others hand over the building. The table below ranks the ones worth checking first by how much reach they actually confer.

Accessibility deserves particular care because it is the one grant that lets an app act as you. Apple’s support documentation advises allowing it only for apps you trust, and that advice is worth taking literally - an app with Accessibility can read window contents and issue clicks and keystrokes anywhere on the system.

Screen Recording works on a timer that no other permission uses. In the early macOS Sequoia betas Apple asked users to reconfirm it every week; the company relaxed that to monthly before release, and monthly is where it stands in Tahoe. There is no supported way to switch the reminder off; you reconfirm each time, or you revoke the permission for good. The recurring prompt makes a decent calendar reminder for the rest of your audit.

Local Network is the category most likely to confuse you, because denying it produces silence rather than an error. A NAS mount that stops appearing, a Home Assistant dashboard that never loads, a local dev server your API client cannot reach… all of them look like network faults, and none of them announces a permission problem. The failure mode also survives app updates: Insomnia users on Tahoe 26.3.1 lost localhost access after an update changed the app’s signature. When a LAN app breaks for no visible reason, check this list first.

Review and change permissions in System Settings

The graphical route covers everything you need and requires no Terminal, no SIP privileges, and no risk of leaving the system in an odd state. Apple’s support page documents the canonical path, and it has not changed in Tahoe.

1. Open System Settings from the Apple menu or the Dock.
2. Click Privacy & Security in the sidebar.
3. Pick the category you want to inspect - Camera, Microphone, Full Disk Access, Screen & System Audio Recording, Accessibility, Local Network, and so on.
4. Switch off the toggle next to any app that should not hold that access.

The summary line under each category tells you how much work is waiting. Full Disk Access - 11 full access on the test Mac above means eleven apps can read every file on the disk; Files & Folders - 16 apps means sixteen hold narrower, folder-scoped grants. Start with the categories carrying the largest counts.

Inside a category you get one row per app and one toggle each. Anything you do not recognize by name is worth a search before you decide, and anything you recognize but no longer use is a straightforward switch-off.

Automation works differently from the rest, and most guides skip past it. Each row has a disclosure arrow, and clicking it expands the list of apps that this app is allowed to drive through Apple Events. That nesting is where the real detail sits: an app permitted to control Finder can reach files across your disk without ever appearing in the Full Disk Access list. Expand every row here at least once.

If you check permissions often, a Terminal shortcut saves the clicking. This URL scheme opens the Privacy & Security pane directly and has worked unchanged from Big Sur through Tahoe 26:

open "x-apple.systempreferences:com.apple.preference.security?Privacy"

Login items and background tasks

Permissions govern what an app can reach. Login items govern when it runs, and an app that starts itself every morning gets to use its permissions every morning. Apple’s support page covers both lists, which live at System Settings → General → Login Items & Extensions. The section moved out of Users & Groups back in Ventura 13 and has stayed put since.

The two lists do different jobs. Open at Login holds ordinary apps that launch when you sign in, and the - button under the list removes any of them. App Background Activity holds the agents and daemons that apps register through the ServiceManagement framework, a mechanism Apple added in Ventura 13; each entry has a toggle and a count of how many items that app registered. An app with a background item can run and use its permissions without ever showing a window.

For a complete picture, Terminal has one command the interface cannot match:

sfltool dumpbtm

The output lists every registered background item with its UUID, developer name, type, and disposition, including legacy daemons and entries the graphical list renders as Unknown Developer. Treat it as a verification tool: when something clearly runs at startup but nothing in System Settings admits to it, this is where you find the record.

Audit every app’s permissions in one place

System Settings organizes permissions by category, which is the wrong axis for the question most people actually have. “What can this app reach?” requires opening a dozen categories and reading each list for one name. App Cleaner & Uninstaller by Nektony inverts that: a 2026 update introduces a privacy permission view that lists apps first and shows the grants attached to each one.

The app list carries a permission count under every name - 3 Permissions, 1 Permission - so a scan down the sidebar tells you which apps hold access before you click anything. Selecting an app opens its card, where App Access shows each grant as a labelled chip: Camera, Microphone, Screen Recording, Full Disk Access, Location Services, and the rest of the TCC categories.

Two more fields on that card feed the keep-or-remove decision. App verification reports whether Apple notarized the build, which separates a known developer from an unsigned binary you no longer remember installing. AI App Summary gives a one-line description of what the app is for - useful when the name alone tells you nothing.

Right-clicking a permission chip opens the actions. Revoke Permission drops that single grant, Revoke All Permissions clears every grant the app holds in one step, and Open in System Settings jumps to the matching category if you would rather confirm the change there.

That bulk action is the part System Settings has no equivalent for. Clearing every grant an app holds takes one click here and a walk through six or seven categories there.

Revoke, then uninstall properly

Revoking and uninstalling solve different halves of the same problem, and doing only one leaves the other open.

/Applications

So the order that actually clears everything is: revoke first, uninstall second.

1. Open the app’s card and use Revoke All Permissions to clear its TCC records while the app is still installed and its signature still matches.
2. Uninstall it with a tool that finds its service files - App Cleaner & Uninstaller scans

   ~/Library/LaunchAgents

   Copy

   ,

   /Library/LaunchDaemons

   Copy

   ,

   Application Support

   Copy

   ,

   Caches

   Copy

   , and

   Preferences

   Copy

   for files tied to that bundle ID and removes them together with the app.
3. Check Login Items & Extensions afterwards and clear any entry the app left in either list.

Doing it in that order means no orphaned database rows, no stray launch agents, and no reappearance in a permission list you thought you had cleaned.

Build a permission-audit habit

Permissions accumulate quietly. Every install adds a few, and nothing in macOS ever suggests reviewing them, so the list only grows in one direction unless you intervene.

The monthly Screen Recording reconfirmation makes a convenient anchor. When that prompt appears, spend ten minutes on the rest instead of dismissing it and moving on. Check permissions again right after installing anything new, while you still remember what it asked for and why.

Here is the short list worth walking through each time:

• Full Disk Access - the shortest list should be the strictest one
• Screen & System Audio Recording - check who can watch, and revoke anything you no longer use for calls or capture
• Accessibility - every entry here can act as you
• Input Monitoring - background keystroke access, rarely needed by more than a tool or two
• Automation - expand each row and read the targets, especially Finder
• Local Network - the one nobody remembers to check
• Login Items & Extensions - both lists, including background activity
• Camera and Microphone - quick to scan, easy to leave stale

Ask one question per row: does this app need this access right now? An app you use weekly and trust keeps its grant. An app you have not opened in six months does not - and if you cannot remember installing it at all, that is a signal to remove it rather than merely to revoke.

The bottom line

Permissions on a Mac are a record of decisions made quickly, months or years ago, one dialog at a time. Reviewing them is the cheapest security work available: no software to configure, no risk of breaking anything, and every change reversible in a click.

Start with the categories that grant the most reach - Full Disk Access, Accessibility, Automation, Screen Recording, Input Monitoring - and work down. Revoke what you do not recognize; the app will ask again if it genuinely needs the access. Check Local Network too, since it fails silently and most guides skip it. And when you decide an app has no business on the Mac at all, revoke its grants first and then uninstall it with its service files, so it leaves nothing behind to come back to.