The following examples illustrate the different use cases for our Request Review scripts, and how you might implement it in your environment.
Auto-approve based on duration
Route based on resource type
Validate custom fields
Check prerequisite access
Complex multi-condition logic
Deny based on device posture with FleetDM
Deny an access request when the requester’s device is failing any FleetDM policy, and approve otherwise. It shows the full pattern for the http and secrets utility modules: secret composition for auth, a fail-closed helper, and terminal actions.deny / actions.approve.
Prerequisites (Settings → Advanced, or the “Manage” drawer in the editor):
- Egress allowlist: add your Fleet host, for example
fleet.example.com with scheme https. It must be a public host. The SSRF-safe client blocks private and loopback addresses even when allowlisted.
- Secret: add
FLEET_API_TOKEN holding the raw token (no Bearer prefix). The script prepends Bearer with secret composition, so the combined value stays opaque.
Fleet’s host search matches hostname, serial, uuid, or ipv4, not email. The email-to-host link lives in Fleet’s device mapping, so this matches the requester’s email against each host’s mapping, making one call per host until it finds a match. The per-execution budget is 50 HTTP calls, so this suits small fleets and demos. For larger fleets, page through /hosts (page / per_page), narrow by team or status, or maintain an email-to-host index outside the script. Otherwise, a requester whose host is not on the first page is denied as unmapped.
Last modified on July 9, 2026