[integrity] DIFC Integrity-Filtered Events Report — 2026-03-23

[github-actions[bot]]

Executive Summary

In the last 7 days (data observed: 2026-03-21 through 2026-03-23), 1,403 DIFC integrity-filtered events were detected across 102 workflow runs and 19 distinct workflows. The most frequently filtered tool was issue_read (556 events, 40%), followed by list_issues (475 events, 34%). The dominant filter reason was integrity (1,402 of 1,403 events, 99.9%), with only 1 secrecy-triggered filter.

The filtering volume is heavily concentrated on 2026-03-22 (943 events — 67% of all events), largely driven by the Issue Monster and Auto-Triage Issues workflows. Issue Monster alone accounts for 533 events (38% of total), reflecting its high-frequency schedule (~30 min interval) repeatedly attempting to read the same set of integrity-blocked issues. The integrity system is functioning correctly: it is protecting agentic workflows from reading untrusted contributor content (tagged none:all) and content from unapproved contributors (unapproved:all). However, the repeated-retry pattern in Issue Monster represents an optimization opportunity.

Key Metrics

Metric	Value
Total filtered events	1,403
Workflow runs analyzed	102
Unique workflows affected	19
Unique MCP servers filtered	1 (github)
Unique tools filtered	9
Most common filter reason	integrity (1,402 / 99.9%)
Busiest day	2026-03-22 (943 events)
Busiest hour	2026-03-22T09:00 UTC (180 events)
Events with none:all integrity tag	1,403 (100%)
Events with unapproved:all integrity tag	130 (9.3%)

📈 Events Over Time

The analysis window contains 3 days of data. Activity was minimal on 2026-03-21 (171 events), spiked sharply on 2026-03-22 (943 events — a 5.5× increase), then fell back to 289 events on 2026-03-23. The 2026-03-22 spike coincides with multiple large runs of Auto-Triage Issues (56–62 events each), the Org Health Report (175 events in a single run), and a high density of Issue Monster runs. The pattern suggests a normal operational burst rather than a systemic regression.

🔧 Top Filtered Tools

The five most-filtered tools are all GitHub read operations targeting issues and PRs:

Tool	Events	% of Total
issue_read	556	39.6%
list_issues	475	33.9%
search_issues	241	17.2%
search_pull_requests	103	7.3%
pull_request_read	16	1.1%
Others (get_discussion, list_discussions, list_commits, get_job_logs)	12	0.9%

This distribution is expected: agentic workflows routinely scan issue/PR feeds that contain untrusted external contributions. All filtered calls hit the github MCP server — no other MCP server was affected.

🏷️ Filter Reasons and Tags

99.9% integrity, 0.1% secrecy. Every event carries the none:all integrity tag, meaning the content being read came from contributors with no established trust level (external contributors without explicit trust grants). 130 events (9.3%) additionally carry unapproved:all, indicating they originated from contributors classified as CONTRIBUTOR but not yet approved — dsyme is the primary example.

The single secrecy-filtered event involved a resource tagged private/secret, correctly blocked to prevent leaking sensitive content to agent context.

📋 Per-Workflow Breakdown

Workflow	Filtered Events	% of Total
Issue Monster	533	38.0%
Auto-Triage Issues	346	24.7%
Organization Health Report	175	12.5%
Dev	134	9.6%
Sub-Issue Closer	108	7.7%
Daily Team Evolution Insights	31	2.2%
Workflow Health Manager - Meta-Orchestrator	16	1.1%
PR Triage Agent	12	0.9%
Daily Documentation Updater	11	0.8%
AI Moderator	10	0.7%
Daily Documentation Healer	9	0.6%
Code Simplifier	6	0.4%
Daily Regulatory Report Generator	5	0.4%
Daily Secrets Analysis Agent	2	0.1%
Others (5 workflows)	5	0.4%

📋 Per-Server Breakdown

MCP Server	Filtered Events
github	1,403 (100%)

All filtered events came from the GitHub MCP server. No other MCP servers (playwright, filesystem, etc.) triggered integrity filtering during this window.

👤 Per-User Breakdown

Author Login	Events	Notes
(no author_login / automated)	601	Scheduler-triggered runs — content read by agents without a human author context
github-actions	348	GitHub Actions bot — automated scheduled triggers
dsyme	81	CONTRIBUTOR, unapproved:all tag — not yet approved
samuelkahessay	38	External contributor
mnkiefer	26	External contributor
Carlson-JLQ	26	External contributor
veverkap	17	External contributor
mhavelock	12	External contributor
Fmarzochi	12	External contributor
TiggySravan	11	External contributor
Esomoire-consultancy-Company	10	External contributor
Others (~100 users)	221	Each with 1–8 events

Note: "no author_login" events originate from scheduled workflow runs where the triggering event context does not carry an issue/PR author (e.g., cron-scheduled scans that read many issues). These are expected and benign.

🔍 Per-User Analysis

The majority of filtered events (949 / 67.6%) are attributable to automated actors: 601 events from scheduler-triggered runs with no human author context and 348 events from github-actions[bot]. This is the expected pattern for a system that runs scheduled issue-scanning workflows — the automation reads many issues from untrusted external contributors, all of which are correctly blocked.

Among human contributors, dsyme (81 events, 5.8%) is the largest individual driver. This user is classified as a CONTRIBUTOR (has prior merged PRs) but carries unapproved:all tags, indicating their content is not yet approved for agent consumption. Granting dsyme explicit trust or moving them to an approved tier would eliminate these 81 recurring filters.

The remaining ~100 individual contributors each trigger 1–8 events, consistent with normal external issue/PR activity.

💡 Tuning Recommendations

1. Cache integrity-blocked issue IDs in Issue Monster (High impact)
   Issue Monster accounts for 38% of all filtered events by repeatedly attempting to read the same ~10 integrity-blocked issues (e.g., 🔍 Multi-Device Docs Testing Report - 2026-03-22 #22226, [refactor] Semantic Function Clustering Analysis: Refactoring Opportunities in pkg/ #22167, [deps] Update safe patch dependencies (1 update) #21935) on every ~30-minute run. The workflow should maintain a cache of known-blocked issue IDs and skip them on subsequent runs. This alone could reduce total filtered events by ~38%.

2. Review and approve dsyme as a trusted contributor (Medium impact)
   dsyme is a CONTRIBUTOR with 81 filtered events (5.8% of total) due to unapproved:all classification. If this contributor's content is safe to process, granting explicit approval or adding them to the trusted tier would eliminate these blocks. Review their recent contributions and proceed accordingly.

3. Add per-run filtering caps to Auto-Triage Issues (Medium impact)
   Auto-Triage Issues generates 56–62 filtered events per large run (346 total across the window). Consider limiting the number of issues scanned per run to those created/updated since the last run, rather than scanning the full open issue list. This would reduce event volume without sacrificing coverage.

4. Investigate the Org Health Report single-run spike (175 events) (Low-Medium impact)
   One Org Health Report run generated 175 events — the most of any single run. This suggests it scanned a broad cross-section of issues and PRs in a single pass. Consider scoping its queries to trusted-content-only sources or filtering to recently-active items.

5. No action needed on secrecy filtering (Informational)
   The single secrecy-filtered event is an isolated occurrence and does not warrant a tuning change at this time. Monitor for recurring patterns.

6. Consider a DIFC "trust warming" mechanism for high-volume external contributors (Long-term)
   The ~100 individual external contributors each appearing in the filtered-user list suggests a long tail of new participants. A lightweight approval flow (e.g., auto-approve contributors after N merged PRs or after manual review) could proactively reduce future filtering volume.

References:

• §23428373244 — This analysis workflow run

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

• expires on Mar 26, 2026, 9:04 AM UTC

[github-actions[bot]]

This discussion has been marked as outdated by Daily DIFC Integrity-Filtered Events Analyzer.

A newer discussion is available at Discussion #22751.