Executive Summary

In the last 7 days, 666 DIFC integrity-filtered events were detected across 19 workflow runs spanning 9 distinct workflows. The most frequently filtered tool was list_issues (538 events, 81%), and every single filtered event was caused by the integrity reason — content below the "approved" integrity threshold. April 2nd saw a major spike with 585 events vs. 81 on April 1st, driven by an intense burst of Auto-Triage Issues schedule runs processing many low-integrity issues in bulk.

The github MCP server was the sole MCP server involved in all 666 filtered events, and the filtering is entirely by integrity (no secrecy-tag filtering observed). The dominant pattern is triage and issue-listing workflows encountering externally-submitted issues that have not yet received the approved integrity label. The unapproved:all integrity tag appears on 123 of the 666 events, indicating approximately 18% of filtered issues were also explicitly tagged as unapproved. All remaining 666 events carry the none:all tag, meaning the triggering content had no integrity classification at all.

Key Metrics

📈 Events Over Time

April 2nd dominates with 585 events — more than 7× the April 1st count of 81. This spike aligns with a large burst of Auto-Triage Issues scheduled runs on April 2nd processing a backlog of unclassified external issues, particularly those from contributor szabta89. The trend appears to reflect a surge in external issue submissions rather than a misconfiguration.

🔧 Top Filtered Tools

list_issues (538 events, 81%) and search_issues (119 events, 18%) together account for 99% of all filtered events. These are bulk-listing tools used by triage workflows that encounter mixed batches of trusted and untrusted issues. issue_read (8 events) and list_pull_requests (1 event) are negligible by comparison. The dominance of bulk-listing tools suggests filtering is working as designed — agents can fetch trusted issues but filtered content is excluded per-resource.

🏷️ Filter Reasons and Tags

All 666 events have the integrity filter reason — no secrecy filtering was observed. The none:all tag is universal (all 666 events), indicating that the filtered resources carry no integrity classification. 123 events additionally carry unapproved:all, meaning those issues were explicitly tagged as not yet approved. There are no secrecy tags in this dataset.

🔍 Per-User Analysis

All 48 filtered users are human contributors (no github-actions[bot] or automated accounts detected). szabta89 leads with 53 events, followed by mnkiefer (36), danielmeppiel (35), microsasa (34), and strawgate (33). The distribution is relatively broad — 48 unique contributors — indicating that the filtering system is correctly intercepting a diverse set of external contributors who have submitted issues without integrity approval, rather than being dominated by a single automated source. The CONTRIBUTOR association (users who have made prior commits) appears on a subset of high-volume entries (e.g., szabta89, mnkiefer), suggesting these are established contributors whose new issues haven't yet received the approved label.

💡 Tuning Recommendations

1. Accelerate integrity approval for active contributors: Users like szabta89 (53 filtered events) and mnkiefer (36 events) are CONTRIBUTOR-associated, meaning they have prior commit history. Consider a workflow that automatically elevates issues from known contributors to approved integrity to reduce unnecessary filtering and improve triage latency.

2. Review list_issues / search_issues filtering behaviour in triage workflows: 99% of filtered events come from these bulk-listing tools. This is likely expected — the DIFC system filters individual resources within a list response — but confirm that triage workflows gracefully handle partial results (i.e., they don't fail or produce misleading output when some issues are excluded from a list).

3. April 2nd spike warrants investigation: 585 events in a single day is a 7× increase over April 1st. Review whether a new batch of external issues arrived on April 2nd or whether a change in triage scheduling increased run frequency. If the Auto-Triage Issues workflow was running more aggressively (e.g., new schedule or event trigger), that could explain the spike without indicating a problem.

4. Dev workflow contributed 59 events: This non-production workflow generated a significant share of filtering. Ensure that the Dev workflow's integrity policy is intentional and that it isn't running against production issue data unnecessarily.

5. Sub-Issue Closer generated 41 events: A workflow that closes sub-issues should not normally need to read unclassified external issues. Review its scope — it may be scanning too broadly and encountering issues it doesn't need access to.

6. No secrecy filtering observed: The absence of secrecy-tagged filtering is a positive signal. No workflow is leaking secrets-tagged data to tools that don't need it.

Generated by the Daily Integrity Analysis workflow
Analysis window: Last 7 days | Repository: github/gh-aw
Run: §23919509092

AI generated by Daily DIFC Integrity-Filtered Events Analyzer · history

• expires on Apr 5, 2026, 8:30 PM UTC