[integrity] DIFC Integrity-Filtered Events Report — 2026-03-31 #23772
Closed
Replies: 1 comment
-
|
This discussion has been marked as outdated by Daily DIFC Integrity-Filtered Events Analyzer. A newer discussion is available at Discussion #23945. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Executive Summary
In the last 7 days, 631 DIFC integrity-filtered events were detected across 17 distinct workflows and 40 workflow runs. All events were filtered by the
githubMCP server due to integrity violations — resources authored by contributors withnone:allorunapproved:allintegrity tags being passed to agent tools that require a higher integrity level.The most frequently filtered tools were
list_issues(274 events, 43%) andsearch_issues(234 events, 37%), together accounting for 80% of all filtered events. The Organization Health Report workflow was the largest single contributor with 247 events (39%), driven by its broad sweeps of repository issues and pull requests opened by external contributors. The overall volume is concentrated in a 2-day window (2026-03-30 and 2026-03-31), suggesting these are scheduled/triggered batch workflows rather than a sustained spike.Key Metrics
none:all(631 events)📈 Events Over Time
Events are clustered in a 2-day window — 410 events on 2026-03-30 and 221 on 2026-03-31. This is consistent with scheduled batch workflows (Organization Health Report, Auto-Triage Issues, Weekly Issue Summary) that run once per day and scan large backlogs of issues. There is no indication of a sustained escalating trend; this appears to be normal volume for the workflows currently deployed.
🔧 Top Filtered Tools
list_issues(274) andsearch_issues(234) dominate — both are read-heavy tools that retrieve bulk lists of issues, inevitably surfacing content from external/unapproved contributors.search_pull_requests(96) follows the same pattern for PR-scanning workflows. These tools are being correctly blocked: the resources they return carrynone:allintegrity labels, and the agents requesting them require a higher integrity level before acting on their content.🏷️ Workflow Distribution & Integrity Tags
All 631 events carry the
none:allintegrity tag (resource author has no approved association), and 127 of those also carryunapproved:all(explicitly flagged as unapproved). The Organization Health Report (39%) and Auto-Triage Issues (24%) together account for nearly two-thirds of all filtered events. This distribution reflects intentional workflow design — these workflows need to broadly scan issues submitted by the public, which will always include unapproved contributors.📋 Per-Workflow Breakdown
📋 Per-Server Breakdown
All events originate from the
githubMCP server — no other MCP servers triggered integrity filtering during this window.👤 Per-User Breakdown (top 30)
162 unique users in total.
🔍 Per-User Analysis
The per-user distribution is broad: 162 unique contributors whose issues/PRs were blocked, with no single account dominating disproportionately. The top user
szabta89triggered 65 events (10% of total), followed byj-srodka(38) anddanielmeppiel(36). Notably, all top accounts appear to be human contributors (external collaborators or first-time contributors) rather than bots — confirming this is expected behaviour of the integrity system correctly isolating unapproved external content. No automated bot accounts appear in the top users list.💡 Tuning Recommendations
Organization Health Report — consider batched integrity labelling. This single workflow produces 39% of all filtered events. The workflow performs broad issue/PR sweeps and is legitimately blocked when encountering
none:allcontent. If this workflow needs to summarize activity from all contributors (including unapproved ones), consider running the summary logic at reduced integrity and applying explicit integrity downgrade annotations so the agent can still process the data for read-only reporting purposes.Auto-Triage Issues — expected, no action needed. This workflow's 153 events across 12 runs (avg ~13/run) represent its normal scanning of new issues from external contributors. The integrity system is working as designed. No tuning required.
Weekly Issue Summary — monitor volume growth. 61 events in a single run suggests this workflow scans a large backlog. As the repository grows and more external issues accumulate, this count will rise. Consider adding a date-range filter to the issue queries so it only processes issues opened in the last 7 days rather than all open issues.
list_issues/search_issues— candidate for integrity-aware pre-filtering. These two tools account for 80% of all filtered events. If workflows need to scan issues without integrity filtering, consider introducing a dedicated "discovery" step that runs atintegrity: lowto enumerate issue numbers, followed by a higher-integrity processing step for acting on approved content.Integrity tag adoption. The
unapproved:alltag appears on 127 events (20%), indicating some contributors have been explicitly flagged. Review whether workflows should handleunapproved:alldifferently fromnone:all— the former may warrant stricter handling (e.g., auto-close or route to human review) while the latter is simply a new/unknown contributor.No secrecy filtering detected. Zero events were filtered for secrecy reasons — all filtering is integrity-based. This is a healthy signal that the secrecy labelling system is not over-triggering.
References:
Beta Was this translation helpful? Give feedback.
All reactions