Enable or disable a deliberate, auditable ONE-OFF bypass of the SYSTEMIC_DROP guardrail in the popularity-estimates pipeline. Background: UpdatePopularityEstimatesFromBigqueryJob holds large downward popularity corrections when more than ~10% of servers would drop at once (a possible systemic ups...
AI agents invoke set_popularity_drop_bypass to trigger actions in Pointsyeah. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call — builds kicked off, notifications sent, workflows started.
This tool triggers a behavioral change in an external pipeline job (UpdatePopularityEstimatesFromBigqueryJob), overriding a safety guardrail that protects against mass popularity drops. It executes a configuration change that affects the next pipeline run, potentially causing large-scale visibility changes across many servers.
From the tool's definition Enable or disable a deliberate, auditable ONE-OFF bypass of the SYSTEMIC_DROP guardrail in the popularity-estimates pipeline
Attacks that exploit this kind of access
Enable or disable a deliberate, auditable ONE-OFF bypass of the SYSTEMIC_DROP guardrail in the popularity-estimates pipeline. Background: UpdatePopularityEstimatesFromBigqueryJob holds large downward popularity corrections when more than ~10% of servers would drop at once (a possible systemic upstream event), keeping each flagged server at its stale value for ~3 days. During a known-legitimate remediation wave (e.g. correcting servers mis-linked to famous registry packages), that guardrail keeps genuinely-corrected servers visible at inflated values. Enabling this bypass tells the NEXT job run to skip the SYSTEMIC_DROP hold for that single run only: it applies the corrected (dropped) BigQuery values, clears popularity_drop_held_since for the affected servers, then CONSUMES the flag (auto-resets enabled→false). The independent impossible-RISE guardrail is unaffected. Returns the resulting bypass status (enabled / enabled_at / enabled_by). Use cases: - Enable the bypass before the next scheduled run to flush a known-legitimate correction wave caught in a systemic hold - Disable the bypass if it was enabled in error and the next run has not yet consumed it. It is categorised as a Execute tool in the Pointsyeah MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
Register the Pointsyeah MCP server in PolicyLayer and add a rule for set_popularity_drop_bypass: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Pointsyeah. Nothing to install.
set_popularity_drop_bypass is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the set_popularity_drop_bypass rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for set_popularity_drop_bypass. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
set_popularity_drop_bypass is provided by the Pointsyeah MCP server (slack-workspace-mcp-server). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Every MCP server has a record like this.
Type a name, get the same breakdown: verified identity, auth posture, risk grade, capabilities, recommended policy.
Teams ship this data inside their own products. See what a licence covers →