Executive Summary

In the last 7 days, 1,732 DIFC integrity-filtered events were detected across 61 workflow runs. The most frequently filtered tool was list_issues (1,303 events, 75% of all events), and 100% of events were filtered for integrity reasons — specifically because resources had lower integrity than the agent required (none:all tag). The dominant workflows were AI Moderator (717 events) and Auto-Triage Issues (689 events), both of which read GitHub issues and PRs created by external contributors or bots. The data concentrates heavily on a single day (2026-03-19: 1,486 events), with activity continuing into 2026-03-20 (246 events).

The high filtering rate in AI Moderator and Auto-Triage Issues is expected behavior: these workflows read issues and PRs authored by contributors (none:all integrity), which triggers integrity filtering as a security boundary. The system is operating correctly — it's detecting and filtering untrusted content. The absence of secrecy filtering (only 6 events) indicates secrets are not leaking into tool calls.

Key Metrics

📈 Events Over Time

The vast majority of events (86%) occurred on 2026-03-19, with a continuation into 2026-03-20 at the time of data collection. The pattern reflects normal scheduled workflow activity — AI Moderator and Auto-Triage Issues run continuously throughout the day, each triggering dozens of filtered events per run as they encounter contributor-authored content.

🔧 Top Filtered Tools

list_issues dominates with 1,303 events (75%), driven primarily by AI Moderator which calls it to scan large lists of issues authored by external contributors. search_issues (248, 14%) and search_pull_requests (87, 5%) follow — these appear in both Auto-Triage Issues and Smoke Codex workflows respectively. issue_read (59) and pull_request_read (23) represent direct item reads that also get filtered. All filtering occurs through the github MCP server exclusively.

🏷️ Filter Reasons and Tags

Every single event carries none:all integrity — the resource had no established integrity tag and was therefore filtered. A subset of 190 events (11%) also carry unapproved:all, meaning those resources were explicitly marked as unapproved. Only 6 events had secrecy_tags: ["private"], indicating near-zero exposure of private data to tools that don't need it — a positive signal.

💡 Tuning Recommendations

1. list_issues is the primary filtering hotspot (75% of events) — This is driven by AI Moderator reading lists of issues authored by external contributors. Since the workflow is explicitly designed to process untrusted contributor content, consider whether the integrity drop should be explicitly permitted with a scoped trust-level: contributor configuration for this workflow to reduce noise while maintaining security.

2. AI Moderator and Auto-Triage Issues account for 83% of all events — Both workflows are operating as designed: they read contributor issues and PRs that carry none:all integrity. The high event counts are a sign of active use, not misconfiguration. No remediation needed, but monitor for unexpected growth.

3. unapproved:all tag on 190 events (11%) — These resources were explicitly marked as unapproved (likely Copilot-authored PRs). Smoke Codex triggers most of these when scanning PRs from the Copilot bot. This is expected for a smoke-testing workflow. If Smoke Codex should trust Copilot-authored PRs, consider adding approval logic to promote them.

4. 6 secrecy-filtered events (private tag) — These appear in search results returning private issue data. The filtering is working correctly. No action needed, but track this metric — an increase could indicate a workflow is inadvertently exposing private data to tools that shouldn't see it.

5. Sub-Issue Closer triggered 100 filter events in a single run — A burst pattern in a single scheduled run. Verify that the workflow correctly handles none:all filtered events gracefully (graceful degradation) rather than retrying in a loop, which could amplify filtering noise.

6. All filtering is through github MCP only — No third-party MCP servers are involved in filtered events. This is a clean boundary. If new MCP servers are added in future workflows, ensure they are also covered by integrity policy.

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

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

• expires on Mar 23, 2026, 9:07 AM UTC