top of page
Search

macOS Privacy Controls for AI Apps: TCC, Full Disk Access, and What to Allow

Writer: MacSmithAI
MacSmithAI
5 days ago
6 min read

Updated: 4 days ago

Every AI app you put on a Mac eventually asks for something alarming. ChatGPT wants Accessibility so it can read the window you're looking at. Claude Code's computer-use mode wants Accessibility and Screen Recording. Somewhere in the chain one of them ends up wanting Full Disk Access, and a user clicks Allow because a dialog told them to.


On a personal Mac that's a judgment call. Across a fleet it's a policy — and right now it's a policy that is about to break, because Apple is removing the mechanism most of us have been using to grant one of those permissions. Here's the permission model underneath AI desktop apps, what those apps actually need, and what I'd approve.


TCC, in one paragraph

Transparency, Consent, and Control is the subsystem behind every "AppName would like to access…" dialog on macOS. Each protected capability — the camera, the microphone, your Documents folder, the whole disk, the ability to drive another app's interface, the ability to see the screen — is a named service, and TCC tracks which app has been granted which one. Admins touch it through a configuration profile payload called Privacy Preferences Policy Control (PPPC), payload type com.apple.TCC.configuration-profile-policy, which pre-approves or blocks a named, code-signed app so the user never sees the dialog. It's device-channel, macOS-only, and requires user-approved MDM.


The important thing about PPPC is that it is not a blank cheque. Apple decides, service by service, whether a profile may grant a permission or only take it away. That asymmetry is the whole story.


What the AI apps are actually asking for

Worth being specific, because "works with your apps" hides which knob gets turned.


ChatGPT's Work with Apps on macOS runs on the Accessibility API. OpenAI's documentation is direct about it: "Enabling ChatGPT to work with most compatible apps requires the macOS Accessibility API to query content." VS Code is the exception — that integration uses an extension instead. Content pulled out of your apps becomes part of chat history and may be used to improve models unless that setting is changed. There are admin controls worth knowing: workspace settings carry a Work with Apps toggle, and admin settings carry a separate "Allow code edits on macOS" toggle.


Claude Code's computer use is unusually candid about its blast radius and asks for two permissions: Accessibility, which "lets Claude click, type, and scroll," and Screen Recording, which "lets Claude see what's on your screen." Anthropic gates it hard — research preview, macOS only, Pro or Max plans only, and explicitly not available on Team or Enterprise plans. It also requires per-app approval inside each session, and flags apps whose approval is, in its own words, "equivalent to shell access."


Full Disk Access usually arrives sideways. No AI product page asks for it. It shows up when an agent needs files outside the folders it can already reach, or when a helper process can't get to a directory the parent app can.


What a profile can and can't hand out

Permission

Can a profile grant it?

What it gives an AI app

My default

Full Disk Access

Yes (SystemPolicyAllFiles)

Read access to nearly everything in the user's account, including other apps' data

Deny; exception process only

Accessibility

Yes on macOS 26 — deprecated in 26.2, removed in macOS 27

Read and control any other app's interface: click, type, scroll

Move to declarative consent now

Screen Recording

No — only "Allow Standard User To Set System Service"

Whatever is on screen, including other people's data in a call

User approves, per app

Input Monitoring

No — same standard-user route

Keystrokes outside the focused app

Deny

Camera / Microphone

No — deny only, never grant

Live audio and video capture

Deny unless the tool's core function needs it


Two rows deserve elaboration. Camera and Microphone have never been grantable by profile — a profile can deny them, never grant them. And Screen Recording can't be pre-approved either. The closest thing is the AllowStandardUserToSetSystemService authorization, which doesn't grant anything; it lets a standard, non-admin user approve the app themselves without an admin unlock. Input Monitoring works the same way.


The change that breaks this in a few weeks

This is the part to pay attention to if you manage Macs rather than one Mac.


Apple is moving privacy configuration out of PPPC and into declarative device management, via a Privacy dictionary in com.apple.configuration.app.settings. It covers Accessibility, Bluetooth, Camera, Dictation, Local Network, Location and Microphone, and it works by presenting the user a single consolidated consent prompt on first launch. Consent-based — meaning the user can decline.


The PPPC route for Accessibility goes away with it: deprecated in macOS 26.2, removed in macOS 27. On the macOS 27 betas, legacy PPPC profiles carrying an Accessibility payload are reported to be silently ignored or to leave split states where the permission looks granted but the API calls quietly fail. Admins on Apple's developer forums asking for a non-consent path — for supervised devices, for headless daemons with no UI to prompt from — have not been given one. Apple's DTS answer amounts to: we really want the user to be in control here.


macOS 27, Golden Gate, was at developer beta 8 on 31 August 2026, and Apple's usual pattern puts general release within weeks of that. The current shipping release is macOS Tahoe 26.6.2, out 17 August 2026. So this is not a next-year problem.


Note what stays behind: Full Disk Access and Screen Recording are not in the declarative Privacy model. The two permissions admins fight with most remain PPPC-only, while the one agentic AI tools want most moves to a prompt your user can say no to.


One more thing that already changed under everyone's feet. As of macOS Tahoe 26.2, permissions configured by a management profile are visible in System Settings > Privacy & Security and labelled as configured by a profile. Whatever you pre-approve, your users can now see you pre-approved it. Plan your comms accordingly.


Doing it in Intune

Settings catalog, not a custom .mobileconfig: Devices > macOS > Configuration > Create > New Policy > Settings catalog, then search for Privacy Preferences Policy Control. You add one instance per service, and each one needs the same core fields — Identifier (the bundle ID), Identifier Type, Code Requirement, and Authorization.


The code requirement is the field people fumble and the field doing the actual security work: it's what stops a look-alike binary carrying the same bundle ID from inheriting your grant. Pull it from a real copy of the app:


codesign -dr - /Applications/Some.app

Everything after designated => in the output is your code requirement string. Paste it verbatim — don't retype it, don't let an AI assistant "clean it up."


Two Intune-specific traps. Screen Recording shows up in the picker as Screen Capture, and its Authorization should be set to Allow Standard User To Set System Service rather than Allow. And don't populate both the deprecated Allow key and Authorization on the same instance — that combination errors out.


What I'd actually allow

Full Disk Access to an AI app is a no by default. It is not a permission to grant to a general-purpose assistant; it's a permission to grant to a specific tool with a specific job, after someone has written down what that job is. If a vendor tells you their chat client needs FDA, ask which directory and why — half the time the honest answer is a helper process that could have been signed and scoped properly.


Accessibility is the harder one, because it's the permission that makes agentic tools work at all, and it's the one that lets an app read and drive every other app on the machine. Whatever you decide, stop building policy on the assumption you can push it silently. Between now and your macOS 27 rollout, move to the declarative Privacy configuration, accept that it's a prompt, and put effort into the user-facing part: name the app, say what it does, tell people what happens if they decline. A consent prompt your users don't understand is a support ticket at ten thousand times scale.


Screen Recording and Input Monitoring I'd leave with the user, deliberately, and use the standard-user authorization so approving doesn't require an admin. Camera and microphone: deny for anything that doesn't need them, since deny is all you get.


The practical takeaway

Inventory before you legislate. Query your fleet for which apps currently hold Full Disk Access, Accessibility and Screen Recording, and you'll almost certainly find AI tools you didn't provision, granted by users who were following an onboarding wizard. That inventory is the argument you take to your security team, not a hypothetical.


Then pick the ground you'll defend. Mine: Full Disk Access is an exception process with a named owner; Accessibility moves to declarative consent with real user comms before macOS 27 lands; Screen Recording stays a user decision. And I'd rather deploy the sanctioned AI tool with a scoped, code-requirement-verified profile than watch people grant a random menu-bar app everything it asks for because IT never gave them an approved option.



Comments

bottom of page