Attached the sysdiagnose report to https://feedbackassistant.apple.com/feedback/24619068 feedback assistance ticket.

Created https://feedbackassistant.apple.com/feedback/24619068 feedback assistance ticket and attached the sample project.

Validated the issue again with the latest 26A5421a beta version and issue did not resolve. We collected the system logs and noticed that com.apple.configuration.app.settings grants Accessibility but not PostEvent access on macOS 27 Golden Gate. The Blueprint and declarations are successfully deployed to the device. macOS displays an “Allow / Not Allow” managed-access prompt for each application. After selecting Allow, both applications immediately receive the older Accessibility dialog stating that the application would like to control the Mac, with Open System Settings / Deny options. The system log indicates that the managed declaration is successfully authorizing kTCCServiceAccessibility. Example: Using managed_overrides value: service=kTCCServiceAccessibility, client=..., auth_value=2, flags=0x20 Handling access request to kTCCServiceAccessibility ... However, when either application attempts to create a CGEventTap, TCC evaluates kTCCServicePostEvent separately: com.apple.accessibility.universalAccessAuthWarn The resulting PostEvent records are ultimately set to denied: Update Access Record: kTCCServicePostEvent for ... to Denied (System Set) Update Access Record: kTCCServicePostEvent for com.verdasys.DgSessionSvc to Denied (System Set) Questions Is com.apple.configuration.app.settings intended to authorize only kTCCServiceAccessibility, without authorizing kTCCServicePostEvent? Is a separate DDM setting required for PostEvent access? Is the additional legacy Accessibility prompt expected after the user has already selected Allow in the managed-access prompt?

Already validated on latest Mac OS 27 beta version 26A5416b. All the above observations are from that OS version. Noticed that as soon as we click on Allow in that above mentioned prompt, it enables the accessibility toggle for a second in System Preferences and then disables it and puts up that that old prompt with Open System Settings/Deny dialog.

We are testing the documented replacement: the Privacy key in the Declarative Device Management(DDM) configuration com.apple.configuration.app.settings. We tried creating the Jamf BluePrint profile with custom declaration with com.apple.configuration.app.settings type for Accessibility permission but that did not work. When we contacted Jamf support team they updated that, the com.apple.configuration.app.settings is not a valid declaration type, and will not work on any version of macOS. There is no native DDM declaration equivalent for PPPC in Apple's Published DDM specs, meaning there is not a DDM type that replaces the legacy PPPC payload via custom declarations. Could you please guide us on creating the DDM for granting the Accessibility permission for an app in Golden Gate which we could achieve earlier using Privacy Preferences Policy Control (PPPC) payload via MDM profiles.

Thanks for the update but this creates a lot of friction for our users, and have them support the previous options. They can't just go around removing previously supported options without any warnings or heads-up.

Created https://feedbackassistant.apple.com/feedback/24067672 ticket.

Thanks for the update. However, this change creates significant friction for our users. Could you please restore support for the previously available options? Removing supported functionality without advance notice or a clear deprecation period will be highly disruptive.

This issue is still not fixed. Even in Golden Gate Beta 4 we are seeing this issue.

Link for apple feedback ticket: https://feedbackassistant.apple.com/feedback/21810618

Attached the files to https://feedbackassistant.apple.com/feedback/21464147 ticket.

Yes, the issue is reproducible only in Mac OS Tahoe. We noticed that this leads to a crash issue when we stop and start the transparent proxy extension. The RC for the crash is, startProxy completionHandler being called multiple times for the same PID. We tried adding the flag check and NSLock/Dispatch Queue to not to call the startProxy completionHandler for second time, but this leads to some unpredictable behaviour like entire network functionality is broken until restarting of the machine. If we call the completionHandler for startProxy all the time, it leads to an over-resume of an object crash when startProxy is being called more than once. Collected the crash report, sysdiagnose for further investigation. (Unable to attach the files, attachments is not enabled for these files) How can I send the crash report and sysdiagnose zip files?

Finally we could resolve the VPN connectivity issue when we insert the order key to VPN/TransparentProxy payload in MDM. Noticed that for some of the distribution profile, if we provide other than network extension identifier in ProviderDesignatedRequirement field, then it fails to establish the VPN connection without logging any error. ProviderDesignatedRequirement identifier "com.digitalguardian.webproxy" and anchor apple generic

Whenever it does not establishes the VPN connection, in the system log we could see below errors: 25-09-11 14:08:00.750332+0530 0x4e84 Default 0x239eb 144 0 nesessionmanager: (NetworkExtension) [com.apple.networkextension:] Signature check failed: code failed to satisfy specified code requirement(s) 2025-09-11 14:08:00.750427+0530 0x4d6b Activity 0x23e36 122 0 mds: (CoreDuetContext) Duet: ClientContext objectForContextualKeyPath: 2025-09-11 14:08:00.750452+0530 0x4a64 Info 0x23f85 134 0 opendirectoryd: [com.apple.opendirectoryd:session] ODNodeCreateWithNameAndOptions completed 2025-09-11 14:08:00.750452+0530 0x4e84 Error 0x239eb 144 0 nesessionmanager: [com.apple.networkextension:] Rejecting agent com.digitalguardian.networkextensionmanager because it does not satisfy the code signature requirements 2025-09-11 14:08:00.750454+0530 0x4e84 Error 0x239eb 144 0 nesessionmanager: [com.apple.networkextension:] Failed to launch com.digitalguardian.networkextensionmanager 2025-09-11 14:08:00.750510+0530 0x4bab Activity 0x23f86 143 0 locationd: (CFOpenDirectory) Querying records from directories 2025-09-11 14:08:00.750577+0530 0x4e84 Default 0x239eb 144 0 nesessionmanager: [com.apple.networkextension:] NESMTransparentProxySession[Primary Tunnel:DGWebProxy:CEF7FD7D-3106-4F46-A8CF-4DEDB64CF7D9:(null)] in state NESMVPNSessionStateStarting: plugin NEFlowDivertPlugin(com.digitalguardian.networkextensionmanager[inactive]) started with PID 0 error Error Domain=NEAgentErrorDomain Code=2 "(null)" 2025-09-11 14:08:00.750580+0530 0x4e84 Info 0x239eb 144 0 nesessionmanager: [com.apple.networkextension:] Setting last stop reason to 6 One of the other team in our company is also having transparent proxy extension. With their binary it establishes the VPN connection when they deploy the product with MDM profile having Transparent Proxy payload with order, with distribution profile which was created using one of their old developer ID. When they deploy the agent with their new distribution profile created using new developer ID it fails to establish the VPN connection. When we compared both the distribution profiles, we could see two additional entries (‘url-filter-provider’ and ‘hotspot-provider’) for entitlement ‘com.apple.developer.networking.networkextension. Will this extra attributes under com.apple.developer.networking.networkextension entitlement can cause this issue? Attached the screenshots for reference.

Yes, with the same binary and distribution provisioning profile, if I just remove the order key attribute from com.apple.vpn.managed payload, it establishes the VPN tunnel. As the order field is not there its not retaining the order when it receives the network traffic.