BTW, noticed a kind of feature (which actually seems like a macOS bug); If the same permissions are set within a profile for a command-line executable (non-standard app) then it seems the permission is locked in place and the user cannot toggle it OFF, e.g. see in the attached screenshot the two blanked out entries: The first is a standard-up where the toggle is active and the one below it is a command-line executable where the toggle is locked:

Update on my last post. I was able to overcome the triggering of the popup by adding a 'PostEvent' permission for our agent within the PPPC payload within our agent's configuration profile. At this stage the agent's entry under 'Device Control and Data Access' appears with the 'This setting has been configured by a profile' note next to it. Just to clarify, Accessibility permissions enforced within the profile does seem to work as expected, once the user toggles it OFF the process loses trust and toggling it ON again restores the trust.

Hi, Following yoaval's latest post, I have encountered a similar issue where the legacy PPPC profile does seem to be enforced as before only thing is that once our agent is installed and launched on the system the toggle appears OFF even though 'AXIsProcessTrusted()' return true and AX calls succeed. But when it calls 'CGEventTapCreate()' a new popup is triggered (Accessibility was replaced with 'Device Control and Data Access' in beta 6): I assume this is due to the change with Golden Gate where the Accessibility permission was moved to user channel rather than the system? and that creating an event tap which monitors system-wide events requires additional consent and privileges ? In any case this is a breaking change from our side. Is this the expected behaviour? WDYT?

Seems that this is resolved in 26.3 beta 1

Hi, Unfortunately the above suggestion doesn't seem to work as the binary is not a real bundled app, e.g. see for 'codesign' That is to say it's identified by path within TCC.db rather that its bundle id. Thanks, Doron.