Post

Replies

Boosts

Views

Activity

Reply to Supported mechanism to provision Accessibility for an MDM-managed security agent on supervised macOS 27, after PPPC removal
Hi Quinn, and sa_i — we've now tested against 27.0b5 (26A5406e), and our results start out looking different to sa_i's but end up in the same place. Posting the full sequence, since the order turns out to matter. Setup: factory-reset machine, our existing macOS 26 PPPC profile applied unchanged — same payload, same code requirement, nothing re-signed or reformatted. On the clean machine, it works. Accessibility is granted to our agent and AX calls succeed. The payload is not silently discarded. The toggle is effectively one-way - The Accessibility switch for our agent is now user-visible and user-changeable in System Settings, which is itself a change, the user can turn it off. Turning it back on does not restore function: After re-enabling, the in-process permission check passes. The AX element calls themselves silently fail, as though no permission had been granted. So the trust API and the effective permission have diverged. From inside the process there is no signal that anything is wrong: the app believes it is trusted and simply gets nothing back.
Aug ’26
Reply to Supported mechanism to provision Accessibility for an MDM-managed security agent on supervised macOS 27, after PPPC removal
I tested this in my environment and observed the same behavior. Thanks for sharing!
Replies
Boosts
Views
Activity
Sep ’26
Reply to Supported mechanism to provision Accessibility for an MDM-managed security agent on supervised macOS 27, after PPPC removal
Hi Quinn, and sa_i — we've now tested against 27.0b5 (26A5406e), and our results start out looking different to sa_i's but end up in the same place. Posting the full sequence, since the order turns out to matter. Setup: factory-reset machine, our existing macOS 26 PPPC profile applied unchanged — same payload, same code requirement, nothing re-signed or reformatted. On the clean machine, it works. Accessibility is granted to our agent and AX calls succeed. The payload is not silently discarded. The toggle is effectively one-way - The Accessibility switch for our agent is now user-visible and user-changeable in System Settings, which is itself a change, the user can turn it off. Turning it back on does not restore function: After re-enabling, the in-process permission check passes. The AX element calls themselves silently fail, as though no permission had been granted. So the trust API and the effective permission have diverged. From inside the process there is no signal that anything is wrong: the app believes it is trusted and simply gets nothing back.
Replies
Boosts
Views
Activity
Aug ’26