Screen Recording permission & native-capture lockdown
What MDM can and cannot do about macOS Screen Recording (TCC), and the two profiles that make Screenproof the sole sanctioned capture path on managed devices.
You cannot pre-grant Screen Recording. Nobody can.
Be accurate about the limit: the com.apple.TCC service ScreenCapture is user-approved only. A PPPC (Privacy Preferences Policy Control) payload cannot pre-grant Screen Recording to Screenproof or any app â Apple requires an explicit user click on the system prompt, full stop. Any vendor claiming otherwise is wrong.
What PPPC can do here: deny the ScreenCapture service to other named apps, so only Screenproof remains a viable capture path once native capture is also disabled (below). It cannot allow-list Screenproof to skip the prompt.
The one-time onboarding step (plan for it)
- First launch: Screenproof requests Screen Recording via the standard TCC API â macOS shows the system permission prompt.
- The user clicks Open System Settings (macOS routes the in-app prompt there) â Privacy & Security â Screen Recording â toggle Screenproof on.
- Screenproof detects the grant and the menu-bar icon flips from "Awaiting permission" to ready.
Document this as a one-time, ~30-second onboarding step in your fleet-wide rollout communication â it is not optional and MDM does not remove it.
Profile 1 â Restrictions: allowScreenShot=false
Use examples/restrictions-allowscreenshot.mobileconfig as-is (payload identifier app.screenproof.restrictions, a com.apple.applicationaccess payload with allowScreenShot=false).
What it does: blocks Cmd+Shift+3 / Cmd+Shift+4 and the screencapture CLI system-wide. What it does not block: Screenproof's own ScreenCaptureKit-based capture â once the user has approved the Screen Recording prompt, Screenproof keeps working normally.
| Path | Result |
|---|---|
| Cmd+Shift+3 | Blocked â OS dialog "Your screenshot can't be saved. Screenshots are not allowed." |
screencapture -x CLI | Blocked â no file written |
| ScreenCaptureKit capture (TCC-approved Screenproof) | Works â full capture succeeds |
allowScreenShot=false delivered by MDM, the native hotkey shows the OS dialog "Your screenshot can't be saved. Screenshots are not allowed." while a Screenproof capture on the same enrolled device succeeds.Profile 2 â PPPC denylist for other capture apps
Start from examples/pppc-deny-screencapture.mobileconfig. It denies the ScreenCapture TCC service to a starter list of capture tools (QuickTime Player's screen recording, OBS Studio, CleanShot X, Shottr, Snagit) â denied apps get no TCC prompt and no capture. One entry per app:
<key>Services</key>
<dict>
<key>ScreenCapture</key>
<array>
<dict>
<key>Identifier</key>
<string>com.example.legacycapturetool</string>
<key>IdentifierType</key>
<string>bundleID</string>
<key>Authorization</key>
<string>Deny</string>
</dict>
</array>
</dict>
Know the constraints:
- No wildcard deny. PPPC cannot deny "everything except Screenproof" â you must name each app explicitly. Extend the list from your fleet's software inventory.
- Screenproof is deliberately absent from the denylist. "Allowed" = not on the denylist + user-approved once.
- MDM delivery only. PPPC payloads apply only when delivered by a (user-approved) MDM â a manual double-click install will not enforce them.
- Meeting tools caveat: Zoom (
us.zoom.xos), Teams, and Slack also holdScreenCapturefor screen sharing â denying them breaks that. Decide per policy.
Deploy via each MDM's native PPPC editor (Jamf: Configuration Profiles â Privacy Preferences Policy Control; Kandji: Library â Privacy Preferences Policy Control; Intune: the PPPC template, or a Custom payload if the built-in UI doesn't expose Deny) â or upload the example .mobileconfig raw, same as the other profiles.
What this posture does and does not achieve
- Restrictions profile closes the native paths (hotkeys,
screencaptureCLI). PPPC closes the named-app paths. Together, Screenproof is the only sanctioned capture path on the managed device. - This does not make screenshots of any app impossible on macOS. Another TCC-approved capture-capable app you didn't deny, a second Mac, a phone camera, or an unmanaged device can still capture the screen. Don't over-claim in your internal security documentation.