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.

On Apple silicon with macOS 26.6.2 (25G83), I am preparing a small synthetic VM using Swift and public Virtualization.framework APIs. Before invoking VZMacOSInstaller, I need to establish a hard aggregate allocation bound covering its temporary extraction data and relevant helper caches, not just the supplied restore image, guest disk and auxiliary-storage URLs. The application-owned artifacts would be placed inside a fixed-size, capped filesystem. Unknown installer scratch remains part of the byte budget. Sampling free space or cancelling after a threshold is crossed is not a substitute for filesystem enforcement in this design. No installer has been started for this trial; this is an API-design question, not a reproduced installation failure. Is there a supported mechanism to select or constrain the filesystem for all VZMacOSInstaller and relevant helper temporary writes? In particular, is there a documented binding between a caller's temporary directory and independently managed installer-service storage, or another supported aggregate quota design? If the public API cannot provide this guarantee, an explicit statement of that limitation would help. I am not seeking private parameters, managed-container relocation, disabled system protections, or undocumented sandbox overrides.