That certainly sounds relevant, thanks! But ... the API is undocumented and appears to exist only for Xcode. There's exactly one hit for it on Google, which is this very helpful thread from someone who got a 1:1 tutorial in how to use it from Apple's security team! https://developer.apple.com/forums/thread/650695 I'm not sure how to interpret that. Are we allowed to use this API? Nobody seems to have objected to Jeff's thread on this forum, but nor does it seem like we're really meant to be using this. Some questions I'd have if it were to be documented: Is this usable for non-bundled binaries? If it's bundled, do you pass the URL of the bundle, or of the main binary? Does the target binary have to be fully signed, or is ad-hoc signed sufficient? Does it affect POSIX launches, like from a shell? Or does it only work for stuff launched via launch services? As kernel/notarization/syspolicyd is invoked by the kernel I'd hope that it does work for POSIX launches but Jeff's thread only talks about NSTask and other Mac specific APIs. Does it keep working if the file is moved or copied? Probably not, as the exception is URL based. How does it work for the non-IDE use case? Should the terminal app itself be added as a developer tool? That seems a bit loose... I'm not averse to having Apple check my parachute lines from time to time, especially as us developers like to do do disgustingly promiscuous things like curl|bash or brew install xyz without thinking. Or maybe if the compiler is signed it can invoke this API to exclude the output file automatically. Really, it feels like this should be done by the system ld. Xcode is already set up as a developer tool. There's nothing really special about this compiler and it lets the Apple toolchain finish off the binary. Hmm. Not for the first time I find myself wishing the sandboxing stuff was more user exposed so I could define "domains" to keep developer/CLI stuff separated and confined. Maybe a product idea is born :)