--- title: "Social Voting | Workshop" description: "Workshop" doc_version: "1" last_updated: "2026-05-22" canonical: "https://northpole.security/features/social-voting" --- ![](https://northpole.security/images/workshop/figma/hero-bg.png) Social voting # Peer consensus, not a ticket queue Workshop's social voting turns fleet-wide allow rules into a peer-driven decision. The Risk Engine gates every vote, so moving fast never costs safety. [Book a demo](https://northpole.typeform.com/to/SG9jCi0v) [View documentation](https://northpole.security/docs/workshop) ![Workshop social voting on a blocked binary, with Risk Engine verdicts and live vote progress](https://northpole.security/_astro/hero.CCx-onLM_Z1jkQkR.png) ![](https://northpole.security/images/workshop/figma/snow-corner-tr.png) ![](https://northpole.security/images/workshop/figma/snow-floor.png) The shift ## A ticket queue does not scale Allowlisting works. The part that breaks is the approval queue behind it. Social voting flips the problem: your coworkers, not a queue, do the initial vetting, and Workshop promotes safe software automatically once enough trusted peers have run it without issue. ### Without social voting Every new binary becomes a ticket. Security triages, approves, and moves on. The next developer who hits the same binary files another ticket. - One ticket per application, and another ticket per new version - One team becomes the bottleneck for every approval - Minutes, hours, or days of latency before the app can be run - Users learn to work around the block instead of through it ### With social voting The first user hits the block, the Risk Engine screens the binary, and peers cast votes in the browser or in Slack. Once the group threshold is met, voters get an allow rule. Once the tag-wide threshold is met, everyone in the tag gets the rule. - Peer-driven validation, not a central queue - Seconds to minutes of latency, most of it self-service - One vetting conversation becomes a rule for everyone - Security keeps policy control without handling every request How it works ## How voting works Voting is a workflow on top of Workshop's approval workflows, with the Risk Engine gating every vote that gets cast. 1 A user hits a block Santa blocks an unknown binary. Workshop opens an approval request and routes a prompt to the user in Slack or the browser. 2 The Risk Engine screens the binary Workshop fans the binary out to every enabled Risk Engine plugin: VirusTotal, ReversingLabs, Blockable Rules, and any remote plugins. Any deny verdict kills the vote. 3 Votes accumulate against thresholds Workshop tracks votes against per-tag and global thresholds. When met, the allow rule is promoted to the matching scope. 4 Thresholds met, rule promoted The allow rule is keyed on the binary's most specific identifier. Once the everyone threshold is met, the next user in the tag never sees a prompt. ![](https://northpole.security/images/home/divider-band-top.svg) Safety floor ## Malware is never voteable Known malware is never eligible for voting. The Risk Engine blocks it before any votes are counted. ![](https://northpole.security/images/home/divider-band-bottom.svg) Scale ## Why voting scales Social voting is the approval pattern Santa was built for. It was used at Google for over a decade to keep 100,000+ Macs on lockdown without blocking legitimate work, and Workshop ships the same design, productized. ### No central bottleneck Security sets the rules for who can vote and what thresholds apply. Everything between block and fleet rule happens without a security engineer in the loop. ### Distributed trust Your teammates already know which tools are load-bearing for their work. A handful of independent peers running the same binary without issue is a stronger signal than one reviewer skimming metadata. ### Auto-promotion Once enough votes are in, Workshop writes the rule. The same binary never produces another approval request, and the same user never votes twice on the same software. ![Rows of vintage Macintosh classic computers in a large room](https://northpole.security/_astro/macintosh-classics.Bjlb68P-_2asmiL.jpg) Safeguards ## Fast votes. Upstream guardrails. Voting is fast because the safety checks are upstream, not in the vote itself. Six things that hold even when peers move quickly. ![An automated security checkpoint inspecting binaries upstream of voting](https://northpole.security/images/social-voting-safety-checks.jpg) 1. 01 ### Risk Engine gating Every vote is checked against the full Risk Engine stack before it's counted. VirusTotal, ReversingLabs, CEL rules, and your custom webhook plugins all have a say. If any plugin denies, the vote is refused. 2. 02 ### Malware is uncountable A malware verdict overrides any amount of votes. The vote buttons are disabled and the attempt is logged with the user and host. This is a hard invariant, not a configurable setting. 3. 03 ### Tag-scoped thresholds Different parts of your fleet can vote at different thresholds. Production admins might need 20 global votes; a developer population might promote at 3. 4. 04 ### Full audit trail Every vote is logged with user, host, binary, timestamp, and the Risk Engine verdicts that were current at the time. Replay the decision from the Audit view whenever a compliance auditor asks. 5. 05 ### Admin override Security keeps the final word. Any promoted rule can be revoked, any binary can be force-blocked, and any user's vote can be reset. Admins can disable voting entirely for specific tags. 6. 06 ### Revote on re-evaluation If a Risk Engine plugin updates and flips a previously-passed verdict, Workshop re-evaluates the rule and surfaces it for review. Votes cast on stale intelligence don't survive fresh intelligence. Channels ## Vote where you already work Voting meets people in the tools they already have open. Nobody has to remember another dashboard to log into. ### Slack Interactive message with app name, publisher, signing identity, Risk Engine verdicts, and vote buttons. Voting progress updates live. Approvers never leave the channel. ### Workshop web UI Full approval queue with filters for tag, risk verdict, vote count, and requester. Useful for high-volume approvers who want to batch through the pending list. Audit ## See the full vote history Every vote, promotion, and override is recorded with the Risk Engine verdicts that were current when the vote was cast. Replay any approval later from Workshop's Audit view. - ### Per-vote audit Who voted, on what binary, from which host, and at what time, alongside the live Risk Engine verdicts at the moment of the vote. - ### Rule promotion logged Every threshold crossing is logged as its own audit entry, so you can trace exactly when and why a rule went tag-wide. - ### Replayable from audit page Reconstruct any approval from the Audit view, with all overrides, vote resets, and threshold changes captured in one searchable trail. ## Social voting is part of Workshop Pair social voting with the rest of the platform to cover the full software lifecycle. [Book a demo](https://northpole.typeform.com/to/SG9jCi0v) [ ### Approval workflows Self-service, manager, tag-based, and Slack-native approvals that keep lockdown usable. ](https://northpole.security/features/approval-workflows)[ ### Risk engine Automated risk assessment for every binary, gating every vote that gets cast. ](https://northpole.security/features/risk-engine)[ ### AI Chat Query events, manage rules, and investigate issues in plain English. ](https://northpole.security/features/ai-chat) ## 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)