I’m reviewing a hypothetical macOS worker controlled through Endpoint Security authorization events. The design uses synthetic fixtures only; no Endpoint Security client has been created for this candidate. The worker’s prohibited operations must be denied before access occurs and remain denied throughout its lifetime. The documentation for es_set_deadline_miss_mode describes missed authorization deadlines and queue overflow. I need clarification on the separate case where the authorization client disappears. For both es_new_client and es_new_descendants_client: What verdict applies to an outstanding AUTH request if the client crashes, disconnects or is deleted before responding? What governs subsequent operations after the last matching client disappears or unsubscribes? Does ES_DEADLINE_MISS_MODE_FAIL_CLOSED cover any of those situations, or only missed deadlines and queue overflow? Is there a supported mechanism that preserves the required denials for an already-running worker throughout client loss and recovery? Which guarantees differ between the two client types or across released macOS versions? Please distinguish pending requests from later requests. A watchdog that eventually terminates the worker would not establish denial during the intervening period. I’m seeking a public, versioned contract or clarification of the specific limitation requiring another independent enforcement mechanism. Relevant references: Deadline miss policy Client deletion Descendant-scoped client No real credentials, backups or customer data are involved. This request does not seek entitlement grants, permission changes or access to private APIs.

I am building Ouroboros (ouro-jail), a contained developer workload runner. Before advertising native macOS support, I need a supported lifetime boundary that covers ordinary fork/spawn/exec descendants, including detached sessions and double-fork daemons. Execution must stay contained when every userspace custodian dies, rather than relying on a surviving process to enumerate and kill descendants. Does macOS provide a supported facility that can: Establish an immutable workload scope before its first instruction and atomically inherit membership through fork/spawn/exec, without modifying the workload or preventing ordinary Node, shell and Git subprocess behavior? Stop or terminate every member after loss of the final control owner, with enforcement retained in the kernel and no userspace callback required? Handle concurrent creation during teardown and expose a verifiable final drain, using stable process identities rather than PID-only scans? Development evidence on macOS 27.0 build 26A428, XNU 13432.1.9 (isolated VM, SIP already disabled in the guest; this is development evidence, not normal-SIP qualification): Descendant-scoped Endpoint Security clients observe the tested subtree. Reciprocal custodians handle either client's loss, but killing both leaves all known members running. Uncached fail-closed AUTH_EXEC lets a survivor execute a new command after both clients disappear (200 reciprocal-custody trials). PT_ATTACHEXC gives kernel-enforced debugger-death cleanup for attached targets, but later fork/spawn children survive (80 debugger-lifetime trials). A locally installed, identity-protected Mach exception handler is inherited through the tested fork/spawn/exec paths. Owner death changes it to a dead handler without stopping normal execution; a child can clear it. Breakpoint controls confirm real kernel exception delivery (24 Mach-lifetime trials). Published XNU contains per-task fatal-port no-senders cleanup, but machdep.task_get_fatal_port is absent on this tested release kernel. I have not treated it as a supported application API. LaunchServices creates a real application coalition, and XPC service lifetime follows app death. However, all seven workload descendants survive, retain coalition membership and can execute a new command. Shared and private audit sessions both fail; eight-second follow-ups also retain all seven survivors. A temporary root launchd service restarts and reaps seven recorded processes after a crash, but does not restart a stopped custodian (native-service trials). I understand Endpoint Security entitlement is separate from a lifetime guarantee. Please clarify whether an approved descendant-scoped ES deployment can provide that owner-loss guarantee through a documented API, whether another supported facility is appropriate, or whether meeting this contract requires a VM boundary. Below are the relevant parts of a focused C command-line reproduction (192 lines total, Xcode 27.0, SDK 27.0, -Wall -Wextra -Werror, no signing or third-party libraries). The code ran in the isolated VM; the packaged Xcode project has only been build-checked. 1. The owner installs a protected exception handler on itself, then forks the workload. No cleanup callback follows. static const exception_mask_t masks = EXC_MASK_SYSCALL | EXC_MASK_MACH_SYSCALL | EXC_MASK_BREAKPOINT; static const exception_behavior_t behavior = EXCEPTION_IDENTITY_PROTECTED | MACH_EXCEPTION_CODES; mach_port_t channel = MACH_PORT_NULL; mach_port_options_t options = {.flags = MPO_EXCEPTION_PORT | MPO_INSERT_SEND_RIGHT}; kern_return_t rc = mach_port_construct(mach_task_self(), &options, 0, &channel); if (rc != KERN_SUCCESS) return 4; rc = task_set_exception_ports(mach_task_self(), masks, channel, behavior, THREAD_STATE_NONE); if (rc != KERN_SUCCESS) return 4; pid_t child = fork(); if (!child) { /* Ordinary receive rights are not inherited. Only the kernel's task * exception-handler state provides supervision of this child. */ _exit(payload(directory, mode, exe)); } 2. The workload detaches (double-fork shown; fork, setsid and posix_spawn SETPGROUP/SETSID also tested; a child can also clear the handler with task_set_exception_ports(..., MACH_PORT_NULL, ...)). child = fork(); if (!child) { if (strcmp(mode, "fork") && setsid() < 0) _exit(4); if (!strcmp(mode, "double-fork")) { pid_t second = fork(); if (second < 0) _exit(4); if (second) _exit(0); } child_work(directory, mode); } 3. Each member reads its inherited handler state and keeps running ordinary BSD syscalls and a Mach trap. kern_return_t rc = task_get_exception_ports(mach_task_self(), masks, observed, &count, ports, behaviors, flavors); /* port == MACH_PORT_DEAD -> dead_mask, valid send right -> live_mask */ for (;;) { if (write(fd, ".", 1) != 1) _exit(3); /* heartbeat file */ (void)getpid(); mach_port_t thread = mach_thread_self(); mach_port_deallocate(mach_task_self(), thread); usleep(10000); } Observed output (double-fork case, original VM run). Workload, before and after SIGKILL of the owner (pid 1472): {"kind":"exception_state","role":"root","phase":"before_owner_loss","rc":0,"live_mask":448,"dead_mask":0} {"kind":"exception_state","role":"late-child","phase":"before_owner_loss","rc":0,"live_mask":448,"dead_mask":0} {"kind":"exception_state","role":"root","phase":"after_owner_loss","rc":0,"live_mask":0,"dead_mask":448} {"kind":"exception_state","role":"late-child","phase":"after_owner_loss","rc":0,"live_mask":0,"dead_mask":448} After owner loss, both root (pid 1473) and the detached late-child (pid 1475, own session) were still alive under the same uniqueid/pidversion, reparented to launchd, with heartbeat files still growing. Across 21 owner-death trials in 7 modes, 39 known fixture processes survived and no case left the fixture empty. The 3 breakpoint controls (owner alive) confirmed real exception delivery. Expected contract: a documented kernel-owned boundary prevents continued execution by every inherited member after all control owners disappear, without enumerating descendants after the fact or requiring workload cooperation. I am asking which supported macOS API meets that contract, not asserting that exception ports promise it. Apple DTS asked me to start this thread (Case-ID: 22799543) and will review once I reply with the link. The full reproduction steps and environment details are in the attached text. forum-attachment-reproduction.txt

SANITISED SUPPORTED MACOS CAPTURE API INQUIRY REVIEW CORRECTIONS APPLIED — DRAFT, NOT SENT Question ID: MACOS-PROTECTED-CAPTURE-PROVIDER-20261004-02 Purpose: identify supported public capabilities; no project acceptance or native-execution approval is requested. Is there a supported public API combination on Apple silicon for capturing unchanged Apple-signed clang, ld and codesign inside a macOS guest after authenticated loader bootstrap but before any initializer, resolver or other target code? Only individually authenticated and explicitly enumerated loader-bootstrap operations may execute before capture; no blanket system-library exemption is assumed. The required observer/enforcer must remain outside tested guest-root authority. Include compromise of the submitting host's administrator. Observation, enforcement, state, custody, revocation and expected admission pins must not rely solely on controls that administrator can forge, replace or recover; remote signing or storage of its assertions is insufficient. The barrier must bind the exact process and guest generation, stop all target threads and byte/mapping writers, and capture complete actual loaded images, shared-cache membership, mappings, segment/private relocated bytes and backing identities coherently. Absent, crashed or disconnected observers, failed captures and missing verified release must keep execution blocked or terminate it before forbidden instructions. Release must be evidence-verified, same-incarnation and one-use. Guest termination must integrate with closed admission and generation fencing against saved-state resume, clone and replay. Our previously supplied context is macOS 26.6.2/SDK 26.5, observed but unattested. We have not run native qualification. Please state required host/guest versions explicitly; an upgrade is not assumed. Current public component documentation establishes: ES_EVENT_TYPE_AUTH_EXEC is an image-execution authorization event. es_set_deadline_miss_mode with ES_DEADLINE_MISS_MODE_FAIL_CLOSED (setter introduced in macOS 27) covers missed authorization deadlines and full-queue drops. Does this also cover client crash, deletion, disconnect or unsubscription, and could any such combination enforce the required post-loader barrier? VZVirtualMachine.pause provides VM lifecycle pausing; stop provides destructive stop with completion/error reporting. VZGuestMemoryMapping (macOS 27) exposes DRAM ranges through custom Virtio devices; the overview describes Linux guests. Is supported macOS guest use available for this purpose, and what coherent-capture/other-writer guarantees exist? Please identify the exact supported symbols and deployment configuration, documented pre-entry ordering and failure guarantees, supported macOS guest applicability, and required entitlements/signing policy. Also state whether protection weakening, target re-signing or changed system components would be required. Such requirements are compatibility limitations, not permission to perform those changes. If the full capability is unsupported, identify the specific missing public interface or guarantee rather than proposing an unsupported workaround. Public references: https://developer.apple.com/documentation/endpointsecurity/es_event_type_auth_exec https://developer.apple.com/documentation/endpointsecurity/es_set_deadline_miss_mode(::) https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_fail_closed https://developer.apple.com/documentation/virtualization/vzvirtualmachine/pause() https://developer.apple.com/documentation/virtualization/vzvirtualmachine/stop(completionhandler:) https://developer.apple.com/documentation/virtualization/vzguestmemorymapping https://developer.apple.com/videos/play/wwdc2026/224/ Only this sanitised text and its public references are intended for relay. No private artifacts, personal/host identifiers, credentials or logs are needed. A provider reply is capability evidence; implementation, actual bindings, independent qualification, Founder acceptance and activation remain separate.

We are building a native macOS client for an isolated numerical research runtime. Can the public launch/spawn and library-constraint mechanisms support the following combined admission requirement, or is their documented guarantee narrower? An independent verifier must establish that a hardware-bound, nonexportable TLS client identity is currently usable only by the exact approved native client build on the intended device and under the complete approved principal. Before that client's first execution, an independent enforcement point must also authenticate its complete executable dependency set, including the loader, shared-cache dependencies, weak dependencies and dynamically loaded code. The launch-constraint documentation describes kernel checks, launchd SpawnConstraint and cdhash facts. Library constraints restrict individual loads, including dlopen. We have not established whether this gives the required whole-closure guarantee before first execution, how the independently trusted verifier can prove enforcement is active, or how it binds to current key-use confinement rather than key origin or application-group membership. Endpoint Security exec authorization is another possible enforcement substrate, but the SDK states that exec target code-signing fields precede on-demand code-page validation. We have not treated that event as a complete closure proof. For this combined admission question, please identify the supported evidence producer, public evidence representation, independently trusted root, verifier and pre-execution enforcement point, with freshness/revocation limits. If the public APIs only establish narrower guarantees, please identify those limits. We seek public API guidance, not internal Apple settings or completion of our development work. References: https://developer.apple.com/documentation/security/defining-launch-environment-and-library-constraints https://developer.apple.com/documentation/security/applying-launch-environment-and-library-constraints https://developer.apple.com/documentation/endpointsecurity/monitoring-system-events-with-endpoint-security

Hello, I am working on a DLP solution for macOS using the Endpoint Security framework. I have faced unexpected behavior regarding process identities. Upon receiving an ES_EVENT_TYPE_NOTIFY_EXEC event, my aplication caches the process details for future use by other internal components. This structure stores user identity tokens, including auid, euid, and ruid. However, I noticed that in subsequent ES_EVENT_TYPE_NOTIFY_CLOSE events for the exact same PID, the audit token arrives with a different audit uid, even though no ES_EVENT_TYPE_NOTIFY_EXIT event was triggered for this process. Could you please help me clarify the following questions: In my case the initial value of audit uid is equal to AU_DEFAUDITID. What does it mean? (ES_EVENT_TYPE_NOTIFY_EXEC and ES_EVENT_TYPE_NOTIFY_CLOSE are triggered by a file copy operation in Finder) How is audit uid changing possible? Is there any way to catch it via Endpoint Security? Thank you in advance!

Hello Apple Developer Community, We are developing a macOS application with a minimum deployment target of macOS 14.0. We are investigating a process-supervision safety problem involving the following topology: Root → Worker → Child The Worker creates the Child using native process APIs and is responsible for supervising its lifecycle. The critical failure scenario Worker successfully creates Child. Child exists, but its verified process identity has not yet been communicated to Root. Worker unexpectedly terminates before completing the identity handoff. Root must avoid signaling an unrelated process while ensuring that an untracked Child cannot continue executing without authorization. Our safety requirements Independently establish Child's exact process-lifetime identity. Prevent unsafe process signaling caused by PID reuse. Handle Worker failure before identity handoff. Verify process termination and disposition. Avoid relying on private APIs or restricted entitlements. Maintain compatibility with macOS 14 and later. What we have investigated We have reviewed posix_spawn, waitpid, process observation APIs, audit-token-based process identification and signaling, Endpoint Security, and launchd-based supervision. We understand that Endpoint Security FORK events are notifications rather than authorization events, and that dropped notifications may prevent complete birth tracking. We also found es_new_descendants_client in the macOS 27 SDK, but it requires an Endpoint Security entitlement and does not meet our current macOS 14 deployment requirements. We understand that a process cannot automatically use waitpid to reap a grandchild merely because the intermediate parent has terminated. Our questions Is there a publicly supported macOS 14+ API or process-supervision mechanism that can reliably establish the identity of a Worker-created Child even if Worker terminates before communicating that identity? Is there a supported approach for safely containing such a Child when its identity is not yet known to Root? Can audit-token-based signaling provide sufficient process-lifetime identity guarantees for this scenario, and what minimum macOS version supports the relevant APIs? Is there a supported mechanism for independently verifying Child termination when Root is not its direct parent? If this cannot be guaranteed using public APIs, would Apple recommend changing the architecture so that Root directly creates and supervises Child? We are not requesting private API access or Endpoint Security entitlements. We would appreciate guidance on the supported macOS process-lifecycle contracts before proceeding with implementation. Thank you for your assistance.

I am reviewing an isolated synthetic worker design using public macOS 27 Endpoint Security APIs. The SDK declares es_set_deadline_miss_mode and es_new_descendants_client. The documentation describes ES_DEADLINE_MISS_MODE_FAIL_CLOSED for unanswered AUTH messages and queue overflow. I have not found a contract covering client loss. If the authorisation client crashes, disconnects or is deleted while AUTH_EXEC is pending, what verdict does the kernel apply? After the last matching client has disappeared, what happens to a subsequent exec by an already-running worker previously covered by that client? Is there a supported kernel-enforced mechanism that preserves replacement-exec denial for that worker until its original lifetime ends, despite authorisation-client failure? If not, please confirm that limitation. Are these client-loss semantics different for es_new_client and es_new_descendants_client, and which released macOS versions support the relevant contract? This is a documentation/design question; these APIs have not been exercised in this candidate. A post-exec watchdog or later termination would not establish pre-exec denial. References: https://developer.apple.com/documentation/endpointsecurity/es_set_deadline_miss_mode(::) https://developer.apple.com/documentation/endpointsecurity/es_new_descendants_client(::) https://developer.apple.com/documentation/endpointsecurity/es_delete_client(_:)

Hello Apple Developer Technical Support, I am evaluating es_new_descendants_client for a local command runner that must report success only after its workload and every process descended from that workload have exited. If observation is incomplete or ambiguous, the runner must report failure. This is a design inquiry, not a report of a reproduced operating-system defect; no entitled prototype has been tested. The proposed observer would create its client and subscribe to lifecycle notifications before launching any workload. It would maintain a registry using process-lifetime identities, add processes on creation and remove them on exit. An unmatched event, missing required field, detected loss or observer failure would invalidate the run. It would consider closure only after all registered workload processes had exited. We have not established that these rules are sufficient. Could you clarify which of the following properties are supported API guarantees, and identify any that applications must not rely on? A documented reference or an explicit statement that a guarantee is unavailable would both help. Please identify applicable macOS/SDK versions and any known version-dependent limitations. 1. Membership and creation-event coverage Does the observed subtree retain a process and all of its future descendants after its original parent exits, it is reparented, it double-forks, or it changes process group/session with setpgid or setsid? Could a process remain observable for exit while creation events for its children become invisible? For a workload launched after successful subscription, does every successful process-creation path—including fork, vfork and posix_spawn—produce a lifecycle event sufficient to register the new process before closure can be declared? Which event and identity fields should be used for each path, including a child that exits without a successful exec? Does the calling observer receive the necessary event for its own initial workload launch? 2. Ordering and the meaning of exit Is there a supported per-client ordering guarantee that every child-creation event from a process is delivered before that process's exit notification, including concurrent creation and exit? Can the child's events arrive before the event that introduces that child? Please distinguish kernel enqueue order, handler delivery order and any processing order the application must impose. At what lifecycle boundary is ES_EVENT_TYPE_NOTIFY_EXIT generated? Does it establish that the identified process can no longer execute or initiate writes, or can relevant activity continue after the notification? We would not equate process exit with filesystem durability or completion of work already delegated to other processes. 3. Muting and other visibility filters Does a newly created descendants client have default process, path or target-path mutes that can suppress fork/exit notifications? What supported sequence of configuration and inspection calls establishes complete lifecycle visibility before launch, including mute inversion and executable-path changes? Apart from subscription and muting, are there policy, security, rate-limit or client-type exclusions that can suppress those events? Which suppressed events, if any, are intentionally absent from the sequence counter rather than reported as drops? 4. Sequence numbers and loss detection The global_seq_num documentation requires message version greater than 4. Is that field guaranteed for descendants-client lifecycle messages? Do notifications concerning the calling observer and its descendants use the same per-client sequence? How can a client establish a valid initial baseline and detect loss before its first received message? Is every dropped subscribed, unmuted lifecycle event reflected in the next delivered sequence number? What counter reset, wraparound or client-recreation rules must be handled? Would the proposed registry rule make terminal loss fail safely—for example, a lost final exit leaves a process registered—under the supported ordering and visibility semantics? Or is there a counterexample in which the registry can become empty while an unobserved descendant survives? 5. Synchronization, observer failure and delegated work Does es_sync_client provide any loss/completeness information beyond draining preceding queued messages? Its documented callbacks also run for a destroyed or null client, so we would not interpret callback arrival alone as successful completion. Is there a supported mechanism to distinguish a healthy drain from invalidation? What does “instigates” cover for this client? In particular, can it observe or attribute work executed by existing launchd/XPC services, or by unrelated processes receiving file descriptors? We would treat such work as outside a lineage-only closure claim unless it is explicitly covered or independently excluded. Does this client provide any supported protection against a same-UID workload stopping, killing or otherwise interfering with its observer, or must that isolation be supplied separately? Observer failure would invalidate the run; we are not assuming ES supplies a write barrier for evidence files. 6. Supported cleanup and deployment Is there a supported public mechanism to signal a non-child descendant by process-lifetime identity, without a PID-reuse race between observing it and sending a signal? Is there a recommended approach if the observer cannot wait on that process? We do not want to depend on private libproc functions as an application contract. Finally, is this use case eligible for com.apple.developer.endpoint-security.client in a standalone signed command-line observer, and what supported signing/provisioning or packaging requirements apply? This is a request for guidance, not an entitlement application. Our central question is whether supported APIs can establish complete descendant-process closure under these constraints. If they cannot, we would appreciate a clear statement of that limitation or a supported alternative. Thank you. Documentation consulted: es_new_descendants_client es_sync_client global_seq_num es_process_t

Hello, Submitted a request for endpoint protection and I can see the status is "Submitted" and I am curious how long users are seeing the process take? Luke

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