PATTERN Cited by 1 source

Self-service block approval¶

When a default-deny enforcement layer (binary authorization, egress firewall, sensitive-data-access gate, device-admission control) blocks a legitimate request, the normal workflow is: file a ticket → human security-team triage → add a rule → wait for the sync interval. That loop is minutes-to-hours in the best case and productivity-frozen while the user waits. At fleet scale the ticket queue buries the team.

Self-service block approval short-circuits that loop. When the enforcer blocks a binary / domain / endpoint, an automated pipeline evaluates it against a battery of safety signals; if it passes, the user is offered an approve / do nothing / flag as malicious decision from within a trusted ops interface (typically a Slack app restricted to the user's corporate device). Approval issues a scoped-to-this-user-and-this-machine rule — the global policy stays untouched.

Flow¶

[enforcer blocks event] ─→ [sync server ingests block event]
       │                          │
       │                          ↓
       │                   [automated safety checks]
       │                   - malware DB lookup (e.g. ReversingLabs)
       │                   - known-bad signer list
       │                   - high-risk-role policy overlay
       │                          │
       ↓                          ↓
[local retry backoff]     [post to Slack app — trusted UI on
                                   corporate device only]
                                  │
                                  ↓
                    [user picks: approve / ignore / flag malware]
                                  │
                                  ↓ (if approve)
                [sync server issues machine-specific rule]
                                  │
                                  ↓
            [push-sync to device → enforcement latency ~seconds]
                                  │
                                  ↓
                    [user retries action → it works]

Load-bearing design choices¶

Approval creates a scoped rule, not a fleet rule. One user's approval affects only their device. Global rule changes stay gated behind the security team's normal review.
The UI runs on an already-trusted channel. A dedicated Slack app accessible only on the corporate MacBook — or equivalent, e.g., an MDM self-service portal — means the approval decision itself is authenticated by something the attacker doesn't have. Don't surface this UI on personal mobiles.
Automated checks gate the approval button. Known-malicious binaries never surface an approve option; users see a different dialog prompting them to contact security. Without this gate the approve button becomes a social-engineering magnet.
Higher-risk roles get stricter policy. Users whose job makes them attractive targets (execs, IT admins, finance) flow through a stricter variant — fewer self-approvable apps, more security-team review.
Downstream re-checks. Approving a binary doesn't bypass other controls. If the newly-approved app later requests sensitive OS permissions (macOS TCC — Accessibility, Full Disk Access), a separate control unsets them until reviewed. Approval is permission-to-run, not permission-to-do-anything.
Latency matters. If the sync interval is 60s, the user's retried launch gets blocked again three or four times before the rule lands. Direct-push or MDM-triggered immediate sync brings enforcement latency to seconds, so approve → retry → works feels instant.
Block-volume monitoring. Track per-user block rate; alert security on users crossing thresholds (e.g., >3 blocks/day). Helps the security team pre-emptively unblock users who are clearly having a bad day rather than finding out from a ticket.

When this is the right pattern¶

High-churn environment — many new binaries / domains / endpoints legitimately appear that the central team can't pre-vet.
Large fleet — the central team cannot personally triage every block.
Users have enough security context to make the ignore-vs-approve choice (developer / data-scientist population, or where training is in place).

When this is not the right pattern¶

Regulated environments where every rule change needs audited human review (regardless of scope).
Fleets where users demonstrably cannot make safe approve/ignore choices (random business users without training, guest devices).
Control points where the blast-radius of "one user approves malware on their laptop" is too high (credential stores, code signing infrastructure).

Seen in¶

sources/2026-04-21-figma-rolling-out-santa-without-freezing-productivity — Figma's Santa rollout wires Rudolph's block events into a custom Slack app on Figma-managed devices only. Automated malware check (ReversingLabs + internal risk signals); if pass → user can self-approve with one click creating a machine-specific rule; if fail → user sees a notify-security dialog. MDM-triggered santactl sync cuts post-approval enforcement latency from 60s to ~3s. >90% of steady-state blocks resolve via this flow with no security-team ticket at a P95 of 3–4 blocks per user per week. Canonical wiki instance.

concepts/binary-authorization — the canonical enforcement domain for this pattern (though the pattern generalises to any default-deny control).
systems/santa / systems/rudolph — the tool + sync server this pattern was layered on.
patterns/rollout-escape-hatch — complementary: during rollout, users can switch their machine back to monitoring mode entirely; in steady-state, self-service approval does the fine-grained work.
patterns/golden-path-with-escapes — sibling idea (opinionated defaults + explicit customization surfaces).
patterns/emergency-bypass — the bigger-hammer sibling (skip-the-gates-entirely for incident response); self-service approval is the smaller-hammer day-to-day version.