[integrity] DIFC Integrity-Filtered Events Report — 2026-04-02

[github-actions[bot]]

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

Metric	Value
Total filtered events	666
Unique tools filtered	4
Unique workflows affected	9
MCP servers involved	1 (github)
Most common filter reason	integrity (100%)
Dominant integrity tag	none:all (666 events)
Busiest day	2026-04-02 (585 events)
Top user triggering filtering	szabta89 (53 events)

📈 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-Workflow Breakdown

Workflow	Filtered Events
Auto-Triage Issues	472
Issue Triage Agent	79
Dev	59
Sub-Issue Closer	41
The Daily Repository Chronicle	9
Daily Team Evolution Insights	2
AI Moderator	2
Workflow Health Manager - Meta-Orchestrator	1
Daily Documentation Updater	1

📋 Per-Server Breakdown

MCP Server	Filtered Events
github	666

👤 Per-User Breakdown (all 48 users)

Author Login	Filtered Events
szabta89	53
mnkiefer	36
danielmeppiel	35
microsasa	34
strawgate	33
samuelkahessay	29
johnwilliams-12	28
bbonafed	26
virenpepper	26
camposbrunocampos	23
grahame-white	23
arezero	23
Corb3nik	22
TiggySravan	18
veverkap	17
chrisfregly	16
MH0386	16
shea-parkes	14
kbreit-insight	13
mlinksva	13
PureWeen	12
bindsi	12
thi-feonir	11
doughgle	10
dbudym-cs	10
Esomoire-consultancy-Company	9
benissimo	9
mvdbos	9
jaroslawgajewski	8
benvillalobos	8
corygehr	6
Yoyokrazy	6
corymhall	6
tomasmed	6
Rubyj	6
ferryhinardi	5
straub	5
justinhuangcode	5
abillingsley	5
tore-unumed	5
salekseev	4
lfgcampos	4
ajfeldman6	2
yaananth	1
DogeAmazed	1
stacktick	1
yskopets	1
kdehl16-web	1

🔍 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