--- title: "Execution Rules | Workshop" description: "Santa execution rules decide what runs on every Mac in your fleet. Five identifier types, six policies including CEL and TouchID, managed fleet-wide from Workshop." doc_version: "1" last_updated: "2026-05-22" canonical: "https://northpole.security/features/execution-rules" --- ![](https://northpole.security/images/workshop/figma/hero-bg.png) # Every binary, decided before it runs. Execution rules are the heart of Santa. Five identifier types resolve in a strict precedence order, five policies cover every situation, and Workshop turns them into a fleet-wide control plane with tags, approvals, risk gating, and a complete audit trail. [Book a demo](https://northpole.typeform.com/to/SG9jCi0v) [View documentation](https://northpole.security/docs/workshop) ![Workshop execution rules dashboard](https://northpole.security/images/workshop/figma/hero-rules.png) ![](https://northpole.security/images/workshop/figma/snow-corner-tr.png) ![](https://northpole.security/images/workshop/figma/snow-floor.png) Rule precedence ## Five rule types, one strict order Santa evaluates rules in a strict precedence order and the first match wins. Layer a broad Team ID allow with a narrow Signing ID block and the narrower rule applies, with no flag-juggling required. 1 ### CDHash The most specific way to identify a binary. Pins one exact signed build of an app. 2 ### Binary Matches a specific build of a file by its hash. Useful for blocking known-bad binaries. 3 ### Signing ID Identifies a specific app from a specific developer. Covers an app across versions. 4 ### Certificate Matches every binary signed with a developer's signing certificate. 5 ### Team ID Matches every app from a developer organization. The broadest option. Pair any identifier with a policy below. [Read the binary authorization docs](https://northpole.security/docs/santa/features/binary-authorization) Policies ## Five policies for every kind of decision Allow and Block are only the start. Compiler policies trust the binaries that build tools produce, silent denials avoid tipping off attackers, and CEL expressions let you express decisions that depend on more than the binary's identity. ### Allow Permit execution. Santa caches the decision so repeated runs are essentially free. ### Allow Compiler Allow execution, and when transitive allowlisting is on, automatically trust binaries the process writes. Built for compilers and build tools. ### Block Refuse execution and show the user a notification explaining the block. The default for policy violations. ### Silent Block Refuse execution without notifying the user. Useful for known-malicious binaries where any feedback might tip off an attacker. ### CEL Custom decisions evaluated at execution time. CEL can also gate a binary behind a TouchID prompt for high-sensitivity tools. Operating modes ## Roll out at the pace your team can absorb Execution rules behave differently depending on the host's mode. Observe before you enforce, then move from Monitor to Lockdown department by department with Workshop's tag system. SANTA / OPERATING MODE OBSERVE ### MONITOR ↳ observe --- See everything, block nothing. Deploy Santa and watch what actually runs across the fleet. Build your allowlist from real data before flipping the switch. --- FILE NO. SC-0001 01/03 SANTA / OPERATING MODE ENFORCE ### LOCKDOWN ↳ enforce --- Only approved software runs. Unknown binaries are blocked at execution time. The prevention-first end state, made livable by Workshop's approval workflows. --- FILE NO. SC-0002 02/03 SANTA / OPERATING MODE DELEGATE ### STANDALONE ↳ delegate --- Unknown binaries prompt the user, who approves with TouchID or password on the device. A good fit for a single developer machine or a small, trusted team. --- FILE NO. SC-0003 03/03 CEL ## Policy that reads the *execution*, not just the binary CEL (Common Expression Language) rules evaluate at execution time. Inspect signing metadata, arguments, environment variables, working directory, process ancestry, and entitlements. A few lines of expression replace whole classes of bespoke detection rules. [Read the CEL cookbook](https://northpole.security/docs/santa/cookbook/cel) - ### Block stale software Refuse binaries signed before your compliance cutoff. Force upgrades across the fleet without listing every version by hand. - ### Protect Gatekeeper Block attempts to disable macOS Gatekeeper while leaving normal usage alone. A short rule replaces a whole class of incident response. - ### Catch persistence tricks Spot known persistence techniques like timestomping system files, and deny them at execution time before they take hold. - ### TouchID on sensitive tools Require biometric confirmation before running admin utilities or remote-access tools. Even compromised credentials cannot run protected software without the user being physically present. Cookbook ## Patterns from the field A few of the rules our customers and the Santa community lean on most. Each is a few lines of configuration that closes off a meaningful piece of macOS attack surface. ### Allow a publisher, block one app Trust everything from a developer, then block one app from that same developer. The narrower rule wins without unwinding the broad allow. ### Block known-bad installers Detect when a built-in macOS tool is being used to download or run software from a known-malicious source, and deny it without breaking everyday usage. ### Quarantine staging directories Block execution from places attackers stage malware, like temp folders and downloads. Routine defense against stage-and-execute attacks. ### Restrict virtualization Block unauthorized VM and hypervisor software without enumerating every product. Approved vendors stay on the allow list. [Read the CEL docs](https://northpole.security/docs/santa/cookbook/cel) At fleet scale ## Workshop turns rules into a *control plane* Managing rules on one Mac is configuration. Managing them across thousands of Macs is governance. Workshop covers the gap with tags, approval workflows, risk gating, fast rollout, and a complete audit trail. ![A workshop control panel governing a fleet of Macs](https://northpole.security/_astro/control-plane.DpNlqxN8_Z2vOVnM.jpg) [Explore Workshop](https://northpole.security/workshop) - ### Tag-based scoping Scope rules to your org. A global baseline, department overrides, and per-host exceptions resolve in a strict precedence order so policy follows your structure. - ### Approval workflows When Lockdown blocks something a user needs, Workshop routes the request to self-service approval, a designated approver, or peer voting. Rules get created automatically when the request resolves. - ### Risk engine gating Every approval is pre-checked by VirusTotal, ReversingLabs, and any custom plugins you wire in. Approvers see results inline. Known-bad binaries can never be promoted to an allow rule. - ### Fast rollout Background sync defaults to every 10 minutes and can be pushed as often as every 60 seconds. For emergencies, trigger a manual push to a specific host from the Workshop console. - ### Full audit trail Every rule creation, edit, deletion, and approval is logged with actor, identifier, policy, and reason. Reconstruct any decision later with full context. - ### GitOps and bulk operations A complete API for managing rules in bulk, including conflict detection. Integrate with your existing change-management process and review pipelines. Developer experience ## Lockdown without breaking the build The same patterns that kept tens of thousands of engineers shipping at Google. Execution rules adapt to the way developers actually work. ### Transitive allowlisting Mark trusted compilers with the Allow Compiler policy and Santa automatically trusts the binaries they produce for six months. Apple's linker, lipo, codesign, and your own toolchain all work out of the box. ### TouchID, not tickets Standalone mode and TouchID-gated CEL rules let developers approve their own runs locally with biometrics. The audit trail still captures the decision. ### On-Demand Monitor Mode When a developer hits an unexpected block, they can request a short, audited exit from Lockdown right from their Mac. The host snaps back to enforcing automatically when the timer expires. [Read about On-Demand Monitor Mode in the docs →](https://northpole.security/docs/workshop/settings#on-demand-monitor-mode) ## Execution rules are part of Workshop Pair them with the rest of Workshop to cover the full software lifecycle. [Book a demo](https://northpole.typeform.com/to/SG9jCi0v) [ ### Package rules Automate execution rules for Homebrew, npm, GitHub, and more developer ecosystems. ](https://northpole.security/features/package-rules)[ ### Approval workflows Self-service, designated approvers, and social voting that turn into rules. ](https://northpole.security/features/approval-workflows)[ ### Risk engine Pre-screens every binary against VirusTotal, ReversingLabs, and your own plugins. ](https://northpole.security/features/risk-engine) ## Frequently asked questions What is an execution rule? An execution rule tells Santa what to do when a particular piece of software tries to run on a Mac. It identifies the software (by hash, signing identity, or developer team) and pairs that with a decision: allow, block, or evaluate a custom rule. Santa applies the rule before any code executes, so unwanted software never gets the chance to run. Which rule type should I use? Most policies are best written against signing identities (Team ID and Signing ID) rather than exact file hashes. Signing-identity rules survive new versions of an app, so you set them once and don't have to update them every release. Hash-based rules are useful for pinning a single known-good build or blocking a specific known-bad binary. How does rule precedence work? Santa evaluates rule types in a strict order from most specific to broadest. The first matching rule wins. That lets you layer policy: allow everything from a trusted developer, then block one specific app from that same developer with a narrower rule. The narrower rule always overrides the broader one, with no manual juggling required. What happens when no rule matches? The fallback depends on the operating mode. Monitor lets the software run and logs it. Lockdown blocks it. Standalone prompts the user to approve with TouchID. Workshop also supports custom fallback rules so you can write a default-deny that explains itself and points users to your help page. What are CEL rules? CEL rules let you express decisions that depend on more than just the identity of a binary. Examples: block software signed before a compliance cutoff, require TouchID for admin utilities, or refuse known persistence techniques. See the CEL cookbook for examples and patterns. Will execution rules break my developers? Not if you set them up right. Transitive Allowlisting trusts the binaries that approved compilers produce, so day-to-day builds keep working. Workshop's Package Rules auto-allowlist tools from Homebrew, npm, GitHub, and other developer ecosystems. Approval workflows resolve unexpected blocks in minutes, and On-Demand Monitor Mode lets a developer take a short, audited exit from Lockdown to unblock an install. How fast do new rules reach endpoints? Santa syncs in the background on a configurable interval (10 minutes by default, as tight as 60 seconds). For emergencies, you can trigger a manual push against a specific host from the Workshop console and the new rules apply on the next sync, which usually completes within seconds. Are execution rules part of Santa or Workshop? Rule enforcement lives in Santa, the open source agent that runs on each Mac. Workshop is the management plane: where you create and edit rules, the approval workflows that produce them, the risk engine that gates them, the tag system that scopes them across your fleet, and the audit log that records every change. Workshop is built and maintained by the same team that maintains Santa. Is every change to a rule logged? Yes. Every rule creation, update, and deletion is recorded in the Workshop audit log alongside the approval decisions and risk engine results that produced it. Audit data can be exported to S3 or GCS for long-term retention and SIEM ingestion. ## Sitemap - [Home](https://northpole.security/index.md) - [Workshop](https://northpole.security/workshop.md) - [Santa](https://northpole.security/santa.md) - [Features](https://northpole.security/features.md) - [Cookbook](https://northpole.security/cookbook.md) - [Docs](https://northpole.security/docs.md) - [Blog](https://northpole.security/blog.md) - [Glossary](https://northpole.security/glossary.md) - [About](https://northpole.security/about.md) - [Contact](https://northpole.security/contact.md)