Entitlements requested: com.apple.developer.driverkit.userclient-access com.apple.developer.driverkit.transport.usb com.apple.developer.driverkit.transport.hid com.apple.developer.driverkit.family.hid.eventservice com.apple.developer.driverkit.family.serial com.apple.developer.driverkit.family.scsicontroller com.apple.developer.driverkit.family.networking com.apple.developer.driverkit.family.hid.device , and the base com.apple.developer.driverkit entitlement Hi all, We recently received a decline on the DriverKit entitlement set listed above. The response noted: "Technical details within DriverKit mean that it is not a viable solution for security block or broad-scale system modifications." I'd like to get some clarity on how to bring our request in line with what's approvable, and I'm hoping the forum (or a Code-Level Support engineer) can point us in the right direction. Context on what we're building: We develop a Data Loss Prevention (DLP) product for macOS. We already hold the Endpoint Security entitlement (com.apple.developer.endpoint-security.client) and use it in production today for our core monitoring and policy-enforcement functionality. Why we're requesting DriverKit specifically: ESF gives us visibility and the ability to authorize/deny many file and process events, but it does not give us the control we need over removable/peripheral hardware. Two concrete gaps in our DLP policy enforcement that we're trying to close: Blocking data exfiltration via USB-connected Android devices — when an Android phone is plugged in, it mounts as a USB mass-storage/MTP-style device, and our policy needs to be able to prevent it from mounting or being written to, on a per-policy basis (e.g., disable an endpoint's ability to copy files to a connected Android device). Camera blocking — disabling the built-in/USB camera device at the hardware transport level as part of a DLP policy, rather than a userspace toggle that a privileged process could bypass. Our understanding was that "com.apple.developer.driverkit.transport.usb" combined with the HID/USB family entitlements would let us implement a DriverKit-based USB filtering driver to enforce this. Given the decline language about "security block or broad-scale system modifications," it sounds like Apple's position is that DriverKit is not intended to be used to build a general device-blocking layer this way. What I'm hoping to learn: Is per-policy USB mass-storage/MTP mounting control (blocking a specific class of device, e.g., Android phones, from mounting or transferring files) something DriverKit is intended to support at all for third-party DLP vendors, or is this fundamentally out of scope regardless of how the request is written up? If it is in scope, what should we change in the entitlement request write-up (use case description, scoping of which entitlements we actually need vs. what we requested) to make it approvable? We may have over-requested — for example, do we need family.networking and family.serial at all for USB mass-storage/camera blocking, or should we narrow the request to just the USB transport + HID/SCSI entitlements? Is there a preferred way to demonstrate that our use case is a scoped, policy-driven enterprise DLP control (with IT/MDM deployment, not a consumer app) rather than "broad-scale system modification," or does the entitlement review not distinguish on that basis? Any pointers — either on scoping this request correctly, or on whether this is simply not achievable via DriverKit and we should be looking at a different API — would be much appreciated. Happy to provide more detail on our exact enforcement flow if that's useful for a Code-Level Support ticket. Thanks in advance