macOS Accessibility Permission Scope: What AI Tools Can Actually Access

1. How macOS Accessibility Permission Works

macOS uses a permission system called Transparency, Consent, and Control (TCC) to gate access to sensitive system capabilities. Accessibility is one of the most powerful TCC-protected capabilities. When an application requests accessibility access, macOS shows a system dialog asking the user to grant permission via System Settings.

The permission is stored in a TCC database at/Library/Application Support/com.apple.TCC/TCC.db (system-level) and ~/Library/Application Support/com.apple.TCC/TCC.db (user-level). Once granted, the application can use the AXUIElementCreateApplicationAPI to get a reference to any running application's UI element tree. From there, it can read element attributes, perform actions (click, type, select), and observe changes.

The permission persists until explicitly revoked. Unlike camera or microphone access, which some applications request per-session, accessibility permission is typically granted once and remains active until the user goes to System Settings, navigates to Privacy and Security, then Accessibility, and unchecks the application. Most users grant the permission and never revisit it.

Programmatically, an application checks whether it has accessibility access by calling AXIsProcessTrusted(). If the function returns false, the application typically prompts the user to grant access. Some applications useAXIsProcessTrustedWithOptions to open the System Settings pane directly, reducing friction in the grant flow.

2. The Scope Problem: All or Nothing

The fundamental issue with macOS accessibility permission is its granularity. It is a single binary permission: either an application can access the accessibility API for all applications, or it cannot access it for any. There is no way to say "grant this tool access to Safari and Finder but not to my banking app."

This made sense when accessibility permissions were designed primarily for screen readers and assistive technologies. A screen reader needs access to every application to be useful. A person using VoiceOver needs it to work in Mail, Safari, Finder, and every other app without granting separate permissions for each one.

For AI automation tools, the all-or-nothing model is a poor fit. A user might want an AI agent to automate their email workflow but not have access to their password manager or banking application. Currently, there is no way to express this preference at the OS level. The tool either has full access or no access.

iOS takes a different approach with its automation permissions, asking for per-app consent when a Shortcut wants to control a specific application. macOS does not have an equivalent mechanism for accessibility access. This is one of the most commonly requested improvements in Apple's developer feedback system, though Apple has not publicly committed to per-app accessibility scoping.

3. What Accessibility Tools Can Actually Do

With accessibility permission granted, an application can perform a wide range of actions. Reading capabilities include: listing all UI elements in any application, reading text content from any text field or label, reading the value of any form control (checkboxes, sliders, dropdowns), reading the title and position of any window, and observing UI changes through accessibility notifications.

Action capabilities include: clicking any button or UI element, typing text into any text field, selecting items in lists and menus, resizing and moving windows, and performing custom actions that applications expose through the accessibility API (like expand/collapse in tree views).

The important nuance is what accessibility APIs cannot do. They cannot read the contents of secure text fields (password fields show as masked). They cannot capture screen pixels (that requires separate screen recording permission). They cannot access data that is not exposed through the UI (like in-memory variables or network traffic). And they cannot modify files on disk directly (that requires separate file access).

This means the accessibility API grants broad but bounded access. It is essentially the ability to see and interact with the same UI that a human user sees and interacts with, but in a structured, programmatic way. It cannot do anything that a person sitting at the keyboard could not also do by clicking and typing.

4. Practical Mitigation Strategies

Given the coarse permission model, users and organizations can take several practical steps to manage the security implications.

Use Open Source Tools

For tools that receive accessibility permission (which grants broad system access), open source provides meaningful security assurance. You can audit the code to verify that the tool only accesses what it claims to access. Closed-source tools with accessibility permission are essentially black boxes with full UI access. Fazm, for example, is fully open source, allowing anyone to inspect exactly how it uses accessibility APIs.

Close Sensitive Applications

Before running an AI automation agent, close applications containing sensitive data that the agent does not need to access. If the agent is automating your email, close your banking app and password manager first. This is a blunt instrument, but it is effective within the current permission model.

Use Separate macOS User Accounts

Create a dedicated macOS user account for automation tasks. Grant accessibility permission to the automation tool in that account only. Run sensitive applications under your primary account. This provides process-level isolation, as the automation tool cannot access applications running under a different user account.

Monitor Accessibility API Usage

Use tools like eslogger (built into macOS) to monitor which processes are making accessibility API calls and which applications they are targeting. This provides an audit trail of accessibility access that can reveal unexpected behavior. For enterprise deployments, feed these logs into your SIEM system for centralized monitoring.

5. Where macOS Permissions Are Heading

Apple has been gradually tightening macOS security with each release. Screen recording permission (introduced in Catalina), input monitoring, and app management permissions all follow the TCC model. It is reasonable to expect that accessibility permissions will become more granular over time.

A likely future direction is per-application accessibility scoping, similar to how iOS Shortcuts request per-app automation permission. This would let users say "this tool can interact with Mail and Safari but nothing else." Another possibility is tiered access levels: read-only accessibility (can read UI elements but not perform actions) versus full accessibility (can both read and act).

For AI tool developers, the practical implication is to build tools that work within the tightest permission scope possible. If your tool only needs to interact with one application, document that clearly and design the tool to not access other applications even though it technically could. When Apple does introduce per-app scoping, tools that already practice minimal access will transition smoothly.

For users, the advice is straightforward: be selective about which tools you grant accessibility access. Understand that the permission is broad. Prefer open source tools where you can verify behavior. Use the mitigation strategies described above. And stay aware of macOS updates that may introduce more granular permission controls. The current model is imperfect, but with informed usage, the risks are manageable.