Executive Summary

In the last 7 days, 1,189 DIFC integrity-filtered events were detected across 25 workflow runs. The most frequently filtered tool was list_issues (529 events), and 100% of filtering was due to a single reason: resources with integrity below the agent's required threshold (integrity_below_threshold). The filtering rate shows a strongly increasing trend, jumping from 67 events on April 3 to 940 events on April 6 alone — a 14× spike driven primarily by the Organization Health Report workflow.

The Organization Health Report workflow alone contributed 539 events (45% of all filtering), followed by Auto-Triage Issues (295 events, 25%). The high event counts suggest these workflows are regularly encountering issues and PRs authored by external contributors whose integrity has not yet been approved. This is expected behavior but indicates opportunities to configure per-workflow integrity thresholds more precisely.

Key Metrics

📈 Events Over Time

The timeline reveals a sharp escalation: April 3 was relatively quiet (67 events), April 5 saw moderate activity (182), and April 6 spiked to 940. The April 6 surge is attributable to the Organization Health Report running and encountering a large batch of unapproved external issues/PRs. No events were recorded on April 4, suggesting some workflows did not run or encountered no unapproved content that day.

🔧 Top Filtered Tools

list_issues (529) and search_issues (431) dominate the filtered events, followed by search_pull_requests (220). These are broad-enumeration tools that return lists of items including those from external contributors. The list_pull_requests and issue_read tools appear rarely (6 and 2 events respectively), suggesting targeted reads are less affected than broad queries. All filtering happened exclusively against the github MCP server.

🏷️ Filter Reasons and Tags

100% of events were filtered for integrity_below_threshold — no secrecy-related filtering occurred at all. The dominant integrity tag is none:all (1,188 events), meaning resources authored by accounts with no verified integrity across all contexts. unapproved:all tags appear in 208 events, indicating resources that are explicitly in an unapproved state. This confirms the system is correctly protecting agents from consuming untrusted external-contributor data.

🔍 Per-User Analysis

All filtering is driven by human external contributors — no bot accounts (e.g., github-actions[bot], Dependabot, or Copilot) appear in the filtered user list. The top users (samuelkahessay, szabta89, danielmeppiel, mnkiefer) each trigger 40–55 events, representing issues or PRs they've opened that haven't yet been approved into the repository's integrity trust chain. The high per-user counts in the Organization Health Report are likely due to that workflow performing broad cross-repository scans that enumerate many open issues. No single user account appears to represent adversarial activity — the distribution is broadly spread across many external contributors.

💡 Tuning Recommendations

1. Organization Health Report needs targeted integrity scoping: This single workflow generated 539 events (45% of all filtering). Consider adding a lower integrity threshold to this workflow's frontmatter, or explicitly using the --approved-only parameter when querying issues/PRs across the organization. Broad health-scan workflows are inherently designed to see all data, so relaxing their threshold is appropriate.

2. Auto-Triage Issues is the second largest source (295 events): The triage workflow may intentionally need to see unapproved issues to route them — verify whether it actually needs full access, or whether it only needs to read the title/type (not body content) to make triage decisions. If so, narrow the MCP toolset permissions.

3. list_issues and search_issues are the primary vectors: These broad enumeration tools return many items at once, causing batched filtering events. Consider whether workflows can use more targeted queries (e.g., adding author: or label filters) to reduce the volume of filtered items encountered.

4. No secrecy filtering detected — system is clean: 100% of events are integrity-based, meaning no secrets or sensitive internal data is leaking to untrusted tools. The secrecy enforcement layer is operating cleanly.

5. Increasing trend — monitor going forward: The 14× spike from April 3 to April 6 warrants continued monitoring. If the volume continues increasing, it may reflect a growing backlog of unapproved external contributor PRs/issues. Running gh aw logs --filtered_integrity weekly will help identify whether this is a plateau or continued growth.

6. Consider onboarding review: The top 5 filtered users have each had 40–55 of their contributions blocked from agent processing. If these are genuine contributors whose issues/PRs deserve attention, they should be moved through the integrity approval process to allow agents to fully assist them.

Generated by the Daily Integrity Analysis workflow
Analysis window: Last 7 days | Repository: github/gh-aw
Run: https://github.com/github/gh-aw/actions/runs/24048761762

Generated by Daily DIFC Integrity-Filtered Events Analyzer · ● 1.9M · ◷

• expires on Apr 9, 2026, 9:02 PM UTC