What do the Hardened Runtime flag and its exception entitlements change, and what can you inspect about a signature without a Developer ID?

Signing with -o runtime sets the Hardened Runtime flag, which codesign -dvv shows as flags=0x10002(adhoc,runtime) (0x2 is “adhoc”, 0x10000 is “runtime”). With it on, the process loses permission for things injection attacks use: unsigned executable memory, loading libraries signed by someone else, DYLD_* environment variables, attaching a debugger. The check makes it concrete with an executable mapping created with MAP_JIT: the plain ad hoc build succeeds, the hardened build is denied, and the same hardened build with com.apple.security.cs.allow-jit succeeds. The other exceptions are allow-unsigned-executable-memory, disable-library-validation (for plug-in hosts), and allow-dyld-environment-variables; each widens the attack surface, so ask for the minimum.

What you can check locally: codesign --verify --strict and codesign -d --entitlements - (what the binary claims), spctl -a -t exec -vv, which rejects an ad hoc app (Gatekeeper needs a Developer ID signature plus a notarization ticket), and stapler validate, which reports that no ticket is stapled. What you cannot check without a paid account is the notary service itself: upload with xcrun notarytool submit, wait for “Accepted”, then stapler staple so the ticket travels with the app and Gatekeeper works offline. Not run here: the notarization round trip and Developer ID signing. In CI keep entitlements in a file reviewed like code, because a missing runtime flag or a leftover debugging entitlement is only noticed at notarization.