Hello, I am working on an audit of file operations for a DLP agent. I am trying to implement this mechanism using Endpoint Security. One of the customer's requirements is that write event reports must provide information about the file size both before and after the write operation. The challenge is that the ES_EVENT_TYPE_NOTIFY_WRITE event does not provide information about the changes, and in the stat structure, I see the file's stat prior to the write event. I tried to implement a mechanism based on tracking the sequence of events (open -> write -> close), but it seems macOS does not guarantee such a sequence, as the agent receives ES_EVENT_TYPE_NOTIFY_CLOSE earlier than ES_EVENT_TYPE_NOTIFY_OPEN. Unfortunately, Auth events cannot be used due to no guarantee the DLP agent is the only ES client. Is there any way within the Endpoint Security Framework to guarantee the sequence of NOTIFY events? Are there any other supported (public) APIs or methods besides Endpoint Security to track file system changes? As far as I know, ktrace (which powers fs_usage) is a private framework. Thank you in advance!

I am evaluating a hypothetical file collector that uses fixed approved directory roots. Its requirement includes rename-after-open: if another process moves an opened file or an ancestor outside the approved namespace, the collector must not continue accessing it there. This concerns input reads, directory enumeration, preview reacquisition, and writes to exclusively created output files. Retaining a previously approved descriptor or detecting a move after access does not meet the requirement. I am considering whether Endpoint Security can prevent the relevant namespace mutations before they occur for the complete access interval. No Endpoint Security client has been created or exercised for this candidate. This is a request for a documented, versioned contract, not permission to deploy a client, obtain an entitlement, or change the system. The deadline-mode documentation describes the response to an unanswered authorization within its deadline. The mode values describe deny without killing the client, allow without killing the client, and killing the client as the default. The setter documentation also describes denial of a queue-full AUTH drop under FAIL_CLOSED. I have not found, in the specific pages listed below, an explicit contract for the separate case of client loss. I am not assuming that deadline policy covers disappearance of a client. Could you clarify the following? Pending authorization at client loss For a relevant authorization such as ES_EVENT_TYPE_AUTH_RENAME or ES_EVENT_TYPE_AUTH_UNLINK that is already pending, what exact verdict applies if the matching client crashes, disconnects, is deleted with es_delete_client, or unsubscribes before responding? Please distinguish each case, including when it was the last matching client and when other matching clients remain. Does a configured FAIL_CLOSED deadline policy remain attached to that pending request after client loss? Operations after the last matching client is gone What controls a later rename, reparenting, exchange, unlink, or other relevant namespace mutation after the last matching client has disappeared or unsubscribed? Is there a supported policy that remains effective independently of that client's lifetime? Please distinguish new operations from an authorization that was already pending, including cached decisions and any interval before a replacement client is ready. A supported complete protection interval Is there a supported way, through Endpoint Security or another supported kernel-enforced mechanism, to keep the necessary namespace mutations denied from before the collector's first access until its final read/write ends, despite authorization-client loss, partial setup, or owner death? The mutating actor may be outside the collector's process subtree. A later watchdog termination, restart, or notification of a completed operation would not establish denial during the intervening interval. If protection must end before that interval is complete, please identify the exact limitation. Client types and failure cases Which guarantees differ between es_new_client and es_new_descendants_client? Beyond the unanswered-deadline and full-queue cases, does any deadline mode affect the cases in questions 1 and 2? Please identify any self-process, muting, caching, scope, or actor limitations that prevent the proposed all-relevant-mutator coverage. I am not assuming a descendant-scoped client can authorize operations by unrelated processes. Versioned support and prerequisites For any supported contract, please cite the public documentation or other authoritative reference, applicable released macOS versions, exact API and deployment configuration, and required entitlements, privilege, consent, or system-extension conditions. API introduction metadata alone is not being treated as evidence about an installed target, and an upgrade or privilege change is not assumed. If no public supported mechanism provides the requested interval, an explicit statement of the missing guarantee or required independent enforcement boundary would be useful. Public references reviewed https://developer.apple.com/documentation/endpointsecurity/es_set_deadline_miss_mode(::) https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_t https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_fail_closed https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_fail_open https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_kill https://developer.apple.com/documentation/endpointsecurity/client https://developer.apple.com/documentation/endpointsecurity/es_client_t https://developer.apple.com/documentation/endpointsecurity/es_new_client(::) https://developer.apple.com/documentation/endpointsecurity/es_new_descendants_client(::) https://developer.apple.com/documentation/endpointsecurity/es_delete_client(:) https://developer.apple.com/documentation/endpointsecurity/es_unsubscribe_all(:) The scoped document reviews did not establish the two client-loss cases above; this is not a claim that every relevant Apple document or mechanism has been exhausted. No real data, credentials, private artifacts, logs, or host identifiers are needed for this clarification.

Subject: Supported macOS containment for a sandboxed worker after controller failure I'm investigating an Apple Silicon/macOS architecture in which an untrusted, signed, sandboxed worker must be independently containable by a separate trusted supervisor. The worker needs only a narrow authenticated communication channel. It requires no direct network access, external operational credentials, privileged file access or authority to launch helpers. I understand that App Sandbox does not inherently prevent child-process creation, and that RLIMIT_NPROC alone does not prevent every form of execution delegation. Could you clarify: Is there a public, supported macOS mechanism to deny all worker-originated subprocess creation and execution delegation at launch, while retaining one restricted communication channel? Alternatively, is there a supported mechanism for a surviving supervisor to identify, terminate and positively verify the complete execution domain of a worker, including any descendants, after its controller crashes or is suspended? What guarantees and limitations apply to stable identity, process exit, automatic relaunch and loss of the supervisor? I'm specifically seeking supported operating-system guarantees, not private sandbox profiles, polling, heartbeat inference or best-effort process-tree enumeration. The goal is to determine whether a bounded synthetic containment experiment is technically justified. No production implementation has been attempted.

Apple DTS case 22893354: forum post and reply Apple asked for the question as a Developer Forums post, then a reply to the case email with the post URL. Nothing below has been posted or sent. 1. Forum post Post at https://developer.apple.com/forums/ (signed in, "Ask a question"). Suggested tags: XPC, App Sandbox, Endpoint Security Attach: fixtures/egress_guard/hp04/apple-descendant-sample/main.c, renamed to main.txt if the forum refuses .c. Title Keeping every descendant of a sandboxed XPC service's worker inside its lifetime (fork, double-fork, setsid) Body We are designing a macOS app that runs an unmodified third-party command-line tool for one task at a time. The plan is an app-bundled, sandboxed XPC service that launches the tool as a child process. The tool is not ours, so we have to assume it may fork without exec, double-fork, and call setsid(). For each run we need one guarantee: after the run ends, every process the tool created has stopped. "Ends" includes the XPC service crashing and the host app crashing, not only a clean cancel. If we cannot prove that, we cannot report the run as finished. What we have looked at so far: Killing the process group. A child that calls setsid() is no longer in the group. launchd's process-group cleanup for the job. As we read launchd.plist(5), that also covers the process group only. Tracking pids from fork and exit notifications, including Endpoint Security. Notifications can be dropped, and pids can be reused, so a list rebuilt from events is not proof that nothing is left. The attached sample shows the process shape without any sandbox or XPC. It starts a worker, the worker double-forks, and the grandchild calls setsid() and keeps writing to a log after the original process has exited. On macOS 15.6.1 the descendant shows parent pid 1 and its own session, and it keeps writing until it finishes on its own: // worker: fork twice, let the intermediate processes exit if (fork() > 0) _exit(0); if (fork() > 0) _exit(0); setsid(); // leaves the original process group and session for (int i = 0; i < 8; i++) { // append "tick i pid ppid" to the log, ppid is now 1 usleep(200000); }Build with cc -Wall -Wextra -Werror -o DescendantOutlivesParent main.c and run ./DescendantOutlivesParent /tmp/descendant-log /tmp/descendant-ready. Questions: Is there a supported mechanism that ties every descendant of a process started by an XPC service, including ones that called setsid(), to the lifetime of that service, so that they are terminated when the service exits or crashes? If the service is sandboxed, does sandbox inheritance (children inherit the parent's sandbox) also give us a way to find or terminate those descendants, or does it only restrict what they can do? If neither, what does Apple recommend for running an untrusted command-line tool where leftover descendants must be ruled out? For example, is a separate launchd job per run, a different process-management API, or Endpoint Security authorization the intended route? Can that mechanism be combined with per-run file access (one input folder and one scratch folder per run), without giving the tool a shared container or network access? We would rather learn that a guarantee is not available than build on an assumption, so a "this is not supported" answer is also useful to us. 2. Reply to the DTS email Reply to Apple's case email (keep the subject) after the post is live: Case-ID: 22893354 Hello, Thank you. I posted the question on the Developer Forums here: <FORUM POST URL> The sample project is attached to the post. There is nothing private in it. Best regards, <NAME>

We are assessing a native macOS worker supervised by an independently protected background service. Our current Mac's system-version file reports macOS 27.0.1 (26A434), and the installed SDK declares es_new_descendants_client for macOS 27. No Endpoint Security client or experimental confinement has been activated. We need a supported public way to stop a job and verify that its controlled execution has ceased, even if workers fork, exec, call setsid/setpgid, are reparented, or their immediate supervisor crashes. Admission must remain closed until reconciliation after a failure. Delegation to outside services must either be denied or have its own enforceable ownership and stop contract. Does Apple provide a public API/configuration that establishes this hereditary ownership and complete termination boundary? In particular, does a descendants ES client's scope retain processes across parent exit/reparenting, and what supported operation can quiesce/terminate that entire owned population without a fork-versus-enumeration race? What remains enforced if that client dies or is deleted? We understand that fail-closed AUTH deadlines and es_sync_client alone do not establish this property. Please identify the supported interface, OS versions, entitlement/privilege requirements, relevant failure semantics and independently observable completion condition, or confirm the limits of this proposed combination. We are asking about the public contract, not private implementation details or a guarantee during kernel failure.

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?