I am designing a bounded local diagnostic helper for macOS. It would run only purpose-built helpers supplied by the application, not third-party or untrusted code. The design question is how to stop exactly those helpers and their descendants on timeout, without affecting an unrelated process or incorrectly reporting that cleanup is complete. This is a public-API suitability question, not a report of a reproduced macOS bug. The intended diagnostic is not an antivirus or endpoint-detection product. The required properties are: Identify each owned process by its lifetime and association with this helper run, not a numeric PID or process-group ID alone. Account for descendants across fork/exec, parent exit or reparenting, and process-group/session changes. Observing that a descendant escaped is not equivalent to preventing an escape. Terminate only the still-owned processes without a stale-identity race between checking ownership and signaling. Report completion only when all owned descendants have stopped and no new owned descendants can appear. Leader exit, IPC disconnection, or an unauthenticated empty process list would not be sufficient. Lost events or uncertain membership must leave the outcome inconclusive. Which supported public API or service/containment architecture can provide these properties? If they cannot all be guaranteed, which constraint should be changed and what guarantee can the supported alternative actually provide? I have reviewed the documentation for es_new_descendants_client and es_sync_client. The remaining questions are: Is a descendant-scoped Endpoint Security client appropriate for this non-security-product diagnostic? If so, which documented entitlement and packaging route applies? I am asking about eligibility, not assuming it. Does any supported design combine lifetime-safe control with containment of the whole owned subtree, including concurrent descendant creation? Merely receiving events would not establish that property. What additional protocol, if any, makes a synchronization callback sufficient to establish complete termination when client destruction, event loss, and concurrent activity are possible? I am not treating that callback alone as proof that no owned process remains. I can redesign around a helper that cannot create descendants if that is the supported approach. In that case, what supported mechanism enforces that restriction and what termination guarantees remain? So far, a standalone C harness has passed eleven fabricated-input cases with assertions enabled. It exercised no Endpoint Security client, process-tree creation/enumeration/control, or application behavior. It is not a runtime reproducer for this API-design question and does not establish native lifecycle safety. Pointers to documented guarantees, limitations, or an Apple sample would help me choose the architecture before preparing a narrowly scoped native test. I am not seeking private APIs or a way to disable platform protections. No logs, source archive, or binary is attached.

We occasionally observe es_mute_process_events() called on an es_client_t while an AUTH event delivered by the same client is still outstanding. In the problematic state, es_mute_process_events() stops returning inside IOConnectCallStructMethod. Subsequent calls to es_respond_flags_result() and a fallback es_respond_auth_result() on the same es_client_t also block in IOConnectCallStructMethod, eventually causing the AUTH deadline to be missed. We would like to clarify the concurrency semantics of these APIs: Is it supported to call es_mute_process_events() before responding to an outstanding AUTH event delivered by the same es_client_t? Can es_mute_process_events() wait for in-flight/outstanding AUTH processing? Are mute operations and es_respond_*() calls serialized internally for a single es_client_t? Can an in-progress mute operation prevent a concurrent es_respond_*() call from completing? Is the recommended pattern to respond to the AUTH message first and update mute state asynchronously afterward?

I'm evaluating Endpoint Security for a supervised macOS worker and a separate evidence collector. This is a question about supported API guarantees; I don't have a reproduced macOS bug. Before collection starts, I need to identify the worker's successful initial executable image. That image must remain current until every collector read and its resulting copy or storage operation has finished, including operations that ultimately report failure. Here, "remain current" means preventing replacement by a later successful exec, not preventing ordinary memory changes within the running program. The proposed policy would authorize the initial exec, then deny subsequent ES_EVENT_TYPE_AUTH_EXEC requests for that worker while collection is active. This is a design under consideration, not an implemented or tested guard. The unresolved case is loss of the ES client while a collector operation is already in flight. If the client crashes, is deleted, or disconnects: What happens to an exec authorization request already pending at that point? What governs later exec attempts after the client is gone? Can a supported mechanism keep exec replacement blocked until the collector's in-flight operations finish, while allowing shutdown within a finite bound? A later health check would not cover an interval in which replacement was already allowed. I reviewed Apple's WWDC20 Endpoint Security session, but haven't established a documented client-loss guarantee for this requirement. I'm asking about client loss separately from an authorization-response deadline expiring. Please point me to the applicable public API contract, including macOS/SDK availability and entitlement requirements. If Endpoint Security cannot provide this guarantee, that limitation would help me reconsider the design. Any supported ordering requirement for establishing the initial successful exec before the first collector read would also be useful.

I have developed an Endpoint Security (ES) system extension using Xcode 16.4. This extension is embedded inside its host application SecureGuard. The host app is signed with a Developer ID Application certificate, and I have created a dedicated ES system extension profile for SecureGuard FileGuard Extension. The workflow works perfectly on macOS 15.3.2. However, on macOS 26, although theSecureGuard host app launches and successfully installs/activates the ES extension, the ES extension gets rejected by TCC due to missing Full Disk Access authorization. I have explicitly granted Full Disk Access permission to the host SecureGuard application in the macOS System Settings. What I have verified so far: SIP was disabled for debugging on macOS 15.3.2, while SIP remains enabled on macOS 26. The app bundle is signed with Developer ID Application and successfully notarized via Apple’s notary service; the ES extension profile is also correctly configured. I do not believe SIP is the root cause here. On macOS 26, output from systemextensionsctl list shows: com.secureguard.fileguard.extension (2026.8/7.2) Extension [activated enabled] This confirms the system extension is successfully installed and activated, with valid code‑signing. I collected system logs with this command: log show --last 30m --predicate 'process CONTAINS "fileGuard"' --info --debug Repeated error messages appear: 14:00:42.271778+0800 0x7d38 Error 0x0 2246 0 com.secureguard.fileguard.extension: (libEndpointSecurity.dylib) Failed to open service: 0xe00002d8: Caller lacks TCC authorization for Full Disk Access For backward‑compatibility with older Intel‑based Mac hardware, both the SecureGuard host app and its ES system extension run under Rosetta translation. My hypothesis: when launchd spawns the ES extension process, TCC denies Full Disk Access for the extension itself, even though the parent host app already holds Full Disk Access permissions. Rosetta translation may potentially be a contributing factor. Has anyone encountered this TCC permission divergence between host app and Endpoint Security system extension on macOS 26? Are there any extra entitlement/profile requirements I missed?

I submitted an Endpoint Security entitlement request today (request ID NWFPYC286F, Team type). The request shows up in my Request History with status "Submitted," but I never received an ACK email or follow-up number. I've checked spam/junk folders and the email associated with our team account. Nothing from Apple. Two questions: Is the request actually in the review queue if I have a request ID in the portal but no email confirmation? Is there any way to check status or get a timeline estimate? This entitlement is critical for our product development. We're building agent identity infrastructure that needs ES for process-level attestation on macOS. Appreciate any help, especially from anyone who's been through this recently.

We develop a third-party endpoint security agent (DLP / device control). It needs kTCCServiceBluetoothAlways to enumerate paired Bluetooth devices and disconnect them selectively based on policy — without user interaction, since this runs unattended on managed fleets. Until recently we granted this silently via a com.apple.TCC.configuration-profile-policy (PPPC) profile pushed by MDM, or by writing directly to the TCC database — the latter no longer possible starting with macOS 27 (Golden Gate). As of macOS 27, tccd also ignores the PPPC profile approach: Override: skipping kTCCServiceBluetoothAlways ... as it is defined in deprecated PPPC profile As a result, end users now hit the standard Bluetooth access consent popup, which we have no way to suppress or pre-answer with Allow. ** Questions: ** Is there any currently supported MDM mechanism — profile-based, DDM, or otherwise — to pre-approve kTCCServiceBluetoothAlways for a specific managed app, so the popup never appears? If direct pre-approval is gone for good, is there any supported way to auto-answer the popup on the user’s behalf via policy (as exists for some other TCC services)? Is this now permanently interactive by design, or is a replacement mechanism planned for MDM-managed Bluetooth access?

I'm developing a macOS product that generates verifiable audit records of media-asset movement on endpoints, for professional media-production companies. It is not an antivirus or Data Loss Prevention product; it collects operating-system file-system events and converts them into tamper-evident audit evidence and audit reports. Target users need comprehensive endpoint audit trails for compliance with industry security standards, including Motion Picture Association Trusted Partner Network assessments. The product must reliably distinguish these operations: file copy, move, rename, and volume mount and unmount — including on external volumes. I've reviewed existing forum guidance, including Quinn's explanation that FSEvents only signals that "something changed" rather than the exact operation, and that it is designed around Spotlight and Time Machine semantics. In my own testing I've also seen inconsistent flags across cp, Finder copy, and application saves, and frequent kFSEventStreamEventFlagMustScanSubDirs events on external drives even when nothing along the path changed. Questions: Given the above, for an audit product that must reliably distinguish copy vs. move vs. rename, should FSEvents be treated as structurally unsuitable, with the Endpoint Security Framework adopted instead as the primary source? For capturing volume mount and unmount operations, is the Endpoint Security Framework the recommended source, or should this be combined with Disk Arbitration? Are there long-term supported APIs recommended for this type of endpoint audit product, to ensure compatibility with future macOS releases? Any recommended documentation, WWDC sessions, or sample code for this use case would be appreciated. For context, I'm building toward a System Extension using the Endpoint Security Framework and will file the entitlement request separately; this post is to confirm the architectural direction before committing. Thank you.

Hello. When testing with the Endpoint Security Framework for the AUTH_OPEN event, I found that the deadline was 15 seconds, but the actual process termination occurred at 5 or 6 seconds. Is this intended?

Hello, My application monitors ES_EVENT_TYPE_NOTIFY_CLOSE. If a file is dragged to another location in Finder, the Endpoint Security reports the event ES_EVENT_TYPE_NOTIFY_CLOSE was performed by '/usr/libexec/xpcproxy'. So, xpcproxy is the process that performed ES_EVENT_TYPE_NOTIFY_CLOSE. Looks like the dragged file is copied by some XPC service. I have found the audit user id is equal to user who dragged a file. Can audit user id be used to identify a user who triggers copy file action in this case? If no, are there any way to define such info? Thank you in advance!

We're working on an Endpoint Security extension and using Swift 6 with Concurrency. I've heard there are some subtleties to getting the threading right across those two domains and am hoping that someone can help shed light on it. In particular, ES events can be delivered on a high priority thread and I'd like to be sure that any work done in the Concurrency domain retains that priority to minimize latency between event delivery and response.

Hi all, I've run into a kernel deadlock issue involving content filter + VPN system/network extension on macOS 26, and would really appreciate any insights. A user reported that their mac is occasionally assigened a 169.254.0.0/16 address and can't reach any website after connecting Wi-Fi. Disabling our content filter restores network connectivity immediately. They're running the following software on the mac: macOS 26 (issue reproduced on 25C56 and 25F71) NEFilterDataProvider-based content filter (our extension) VPN network extension A spindump taken while the system had lost network connectivity shows the content filter's process stuck while delivering an "allow" verdict to the kernel. All subsequent flow decisions for the extensions are blocked behind it, which would explain why new DHCP request can't complete and the interface stays on a self-assigned address. Based on the "last ran" and timestamp in the spindump, the underlying deadlock appears to have occurred while the computer wasn't connected to any Wi-Fi network, so there was no visible symptom at the time. The user only noticed something was wrong once they tried to reconnect and saw the bad IP address; they did not realize the content filter was already stuck. This issue may be identified by searching for keyword "sofreelastref" in the spindump (see comment below). Has anyone else seen a content filter + VPN hang like this on macOS 26? Any guidance or pointers would be greatly appreciated. Thanks in advance! For Developer Technical Support staffs: FB23720745 Shay

Hi! We're developing a security product that uses both EndpointSecurity.framework to intercept and authorize process and file events; and NetworkExtension.framework o intercept and inspect network connections. We're occasionally seeing crashes caused by Endpoint Security timeouts. After investigating several crash reports, we believe we've identified a deadlock involving code signature verification: our Network Extension intercepts connections initiated by nsurlsessiond to retrieve OCSP/CRL data (we believe these requests are made on behalf of trustd during code signature validation). To determine which policy should be applied to an intercepted connection, our Network Extension verifies the code signature of the originating process. However, that code signature verification itself blocks while waiting for the OCSP/CRL requests to complete. Since those requests are being intercepted by our Network Extension, we end up with a circular dependency: A process requires code signature verification. Signature verification triggers OCSP/CRL network requests. Those requests are intercepted by our Network Extension. Our Network Extension attempts to verify the initiator's code signature before allowing the connection. That verification waits for the same OCSP/CRL requests to complete. As a result, code signature verification becomes blocked process-wide, including verification performed while handling Endpoint Security events. Eventually, our Endpoint Security client exceeds the allowed response timeout and is terminated. We're considering bypassing interception for OCSP/CRL traffic to avoid this deadlock, but we'd like to understand whether this is the recommended or most robust approach. Questions Is there a reliable way to identify network connections that are fetching OCSP or CRL data for code signature validation? What is the relationship between trustd and nsurlsessiond for these requests? Is there a dedicated nsurlsessiond instance serving trustd, or are these requests performed by the shared system/session-wide nsurlsessiond? Would it be a reasonable and future-proof approach to identify these requests by checking NEAppProxyFlow.remoteHostname (for example, ocsp.apple.com and crl.apple.com) and bypassing interception for those connections? Is there another recommended approach to avoid this deadlock when combining Endpoint Security and Network Extension in this way? Any guidance or best practices would be greatly appreciated. Thank you!

I work for a company which develops as part of our product suite a System Extension implementing an Endpoint Security client. Our local developer workflow for testing and validating changes is to build locally with Developer certificates (not a legitimate/production Developer ID certificate) and deploy local builds in to a VM, where to get the System Extension to load and be accepted we need to disable SIP & AMFI. macOS 27 VM is refusing to allow me to disable SIP. Is there an alternate approach we can use for this workflow to allow macOS VMs to accept our software when signing with a (same teamID, but different certificate to the provisioningprofile) developer certificate for local validation?

Quinn, you've often suggested that to validate the other side of an XPC connection, we should use the audit token. But that's not available from the XPC object, whereas the PID is. So everyone uses the PID. While looking for something completely unrelated, I found this in the SecCode.h file OSStatus SecCodeCreateWithXPCMessage(xpc_object_t message, SecCSFlags flags, SecCodeRef * __nonnull CF_RETURNS_RETAINED target); Would this be the preferred way to do this now? At least from 11.0 and up. Like I said, I was looking for something completely unrelated and found this and don't have the cycles right now to try it. But it looks promising from the description and I wanted to check in with you about it in case you can say yes or no before I get a chance to test it. Thanks

Hello, What are the restrictions on submitting apps to the mac App Store that use an NETransparentProxy alongside a locally installed and trusted Root-CA to intercept, decrypt and manipulate TLS traffic? To be more specific, I'm not talking about a Safari extension. I'm talking about system-wide traffic. So that the app can detect and block ads and trackers from all apps, not just Safari. I'm aware that such an app can be distributed using an unsandboxed Developer-ID signed app. But I wonder if such an app also breaks Sandbox requirements for AppStore distributed apps? Also, is there a way for a sandboxed app to install and trust a root CA? SecTrustSettingsSetTrustSettings does not work in Sandboxed apps from what I found. Finally, I want to ask about EndpointSecurity. Can this entitlement be used in AppStore-ditributed apps? Is doing any of these things possible on AppStore-distributed apps? Thanks in advance for your reply.

I saw there is a new es_new_descendants_client() function in Endpoint Security, with very interesting details: no TCC approval required no root privileges required which makes it very different from how we've known Endpoint Security so far. What is the real life use of this client? First, I thought it would be good to monitor processes I launch from my central application - but I won't fork() or exec() other apps - I will ask launchd to open them (NSWorkspace...), so they won't be descendants of my Endpoint Security client containing process. Not to mention, I don't understand how this aligns with the entitlement being attachable only to system(?) extensions. Or, can I now add this entitlement to an application? The dropping of root privilege as a requirement seems like this entitlement could be attached to regular apps. Or it can only be attached to a launchd agent, rather than a daemon? I haven't seen any pointers in Endpoint Security documentation other than this function's documentation. A tutorial would be very nice to have. Thanks in advance!

Is there any plan to deanonymize in the near future ES_EVENT_TYPE_RESERVED_X where the range of X is [1, 8] ?

My app needs both Accessibility and Input Monitoring permissions. Accessibility works as expected — calling AXIsProcessTrusted() automatically adds the app to System Settings > Privacy & Security > Accessibility, and the user just needs to toggle it on. Input Monitoring doesn't behave the same way. I'm calling CGRequestListenEventAccess() and creating a CGEvent.tapCreate(.listenOnly), but the app doesn't reliably appear in the Input Monitoring list. The user opens the pane and sees nothing to enable. What I've tried: CGRequestListenEventAccess() — shows the system prompt once per install, but doesn't always add the app to the list CGEvent.tapCreate(tap: .cgSessionEventTap, place: .headInsertEventTap, options: .listenOnly, ...) — returns nil before Accessibility is granted; after Accessibility is granted, the tap succeeds but the app still may not appear in the Input Monitoring list 3. Calling both after Accessibility is confirmed, with a delay before opening the Settings pane The flow: User grants Accessibility (app appears automatically via AXIsProcessTrusted()) App creates a listen-only CGEventTap (succeeds) App opens x-apple.systempreferences:com.apple.preference.security?Privacy_ListenEvent User sees the Input Monitoring pane but the app is not listed Environment: macOS 15 (Sequoia), signed and notarized app, correct bundle ID, Hardened Runtime with com.apple.security.device.audio-input-monitoring entitlement not set (not applicable — this is for audio, not HID). Question: Is there an API equivalent to AXIsProcessTrusted() that reliably registers an app in the Input Monitoring list? Or is there a specific entitlement, Info.plist key, or sequence of calls required on macOS 14+/15 to ensure the app appears?

My app needs both Accessibility and Input Monitoring permissions. Accessibility works as expected - calling AXIsProcesstrusted() automatically adds the app to System Settings > Privacy & Security > Accessibility, and the user just needs to toggle it on. Input Monitoring doesn't behave the same way. I'm calling CGRequestListenEventAccess() and creating a CGEvent.tapCreate(.listenOnly), but the app doesn't reliably appear in the Input Monitoring list. The user opens the pane and sees nothing to enable. What I've tried: CGRequestListenEventAccess() — shows the system prompt once per install, but doesn't always add the app to the list CGEvet.tapCreate(tsp: .cgSessionEventTap, place: .headInsertEventTap, options: listenOnly, ...) — returns nil before Accessibility is granted; after Accessibility is granted, the tap succeeds but the app still may not appear in the Input Monitoring list Calling both after Accessibility is confirmed, with a delay before opening the Settings pane The flow: User grants Accessibility (app appears automatically via AXIsProcessTrusted()) App creates a listen-only CGEventTap (succeeds) App opens x-apple.systempreferences:com.apple.preferences.security?Privacy_ListenEvent User sees the Input Monitoring pane but the app is not listed Environment: macOS 15, signed and notarized app, correct bundle ID, Hardened Runtime with com.apple.security.device.audio-input-monitoring entitlement not set (not applicable). Is there an API equivalent to AXIsProcessTrusted() that reliably registers an app in the Input Monitoring list? Or is there a specific entitlement, Info.plist key, or sequence of calls required on macOS 14+/15 to ensure the app appears?

Hello Everyone, Like probably several other Enterprise customers and more, we have been bitten by a bug with regards to VPN and Endpoint Security and the new M5 / M5 Pro SoCs shipping in the latest MacBook devices. I have raised the following feedback IDFB22753954 (which itself references an internal issue I believe, if we need to mark it as a dupe: 172793638 ). The technical sequence leading to the crash is as follows I believe: The macOS system process neagent successfully initializes the GlobalProtect network extension. The GP Network extension transitions from an 'inactive' state to a 'running' state. As network traffic begins flowing through the extension, a critical flaw in the macOS kernel's memory allocation (specifically related to the Apple Network Extension framework) is triggered. This memory management failure at the kernel level results in a kernel panic at an unpredictable point during packet processing. Because this is a core operating system vulnerability, any third-party application or security solution that leverages Apple's Network Extension framework is susceptible to these crashes. This has been confirmed across multiple vendors within the cybersecurity industry from what I understand. Crashes_M5Pro_1.txt Thank you in advance for your help! Kind Regards, Goffredo