You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Metric
Value
Total filtered events
1,189
Unique tools filtered
5
Unique workflows affected
14
Most common filter reason
integrity_below_threshold (100%)
Busiest day
2026-04-06 (940 events)
Only MCP server involved
github
Secrecy-filtered events
0
📈 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-Workflow Breakdown
Workflow
Filtered Events
Organization Health Report
539
Auto-Triage Issues
295
Sub-Issue Closer
148
Weekly Issue Summary
63
Issue Triage Agent
63
Dev
49
Daily Team Evolution Insights
17
Agent Performance Analyzer - Meta-Orchestrator
2
Daily Documentation Healer
2
AI Moderator
2
Weekly Blog Post Writer
1
Smoke Copilot
1
Smoke Claude
1
The Daily Repository Chronicle
6
📋 Per-Server Breakdown
MCP Server
Filtered Events
github
1,189
All filtering originates from a single server: the github MCP server. No filtering was observed from safeoutputs, agenticworkflows, playwright, or mcpscripts servers.
👤 Per-User Breakdown (Top 30)
Author Login
Filtered Events
samuelkahessay
55
szabta89
47
danielmeppiel
44
mnkiefer
40
camposbrunocampos
32
MarkLee131
23
veverkap
22
Corb3nik
22
strawgate
22
TiggySravan
21
kbreit-insight
20
jaroslawgajewski
18
seangibeault
18
gidson
17
Emeka-E
17
jreyesr
15
mrunalmehta004
15
RJTLM
15
stijnvdv
14
vmanot
14
unknown
13
Esomoire-consultancy-Company
13
bbonafed
11
chrisfregly
9
SirBraneDamuj
9
ahamedjobayer081-spec
8
deependujha
8
tannerj-uci
7
TanveerAhmad1
6
FancyJoy
6
🔍 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
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.
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.
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.
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.
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.
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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
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 Reportworkflow alone contributed 539 events (45% of all filtering), followed byAuto-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
github📈 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 Reportrunning 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) andsearch_issues(431) dominate the filtered events, followed bysearch_pull_requests(220). These are broad-enumeration tools that return lists of items including those from external contributors. Thelist_pull_requestsandissue_readtools appear rarely (6 and 2 events respectively), suggesting targeted reads are less affected than broad queries. All filtering happened exclusively against thegithubMCP 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 isnone:all(1,188 events), meaning resources authored by accounts with no verified integrity across all contexts.unapproved:alltags 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-Workflow Breakdown
📋 Per-Server Breakdown
All filtering originates from a single server: the
githubMCP server. No filtering was observed fromsafeoutputs,agenticworkflows,playwright, ormcpscriptsservers.👤 Per-User Breakdown (Top 30)
🔍 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
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-onlyparameter when querying issues/PRs across the organization. Broad health-scan workflows are inherently designed to see all data, so relaxing their threshold is appropriate.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.
list_issuesandsearch_issuesare 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., addingauthor:or label filters) to reduce the volume of filtered items encountered.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.
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_integrityweekly will help identify whether this is a plateau or continued growth.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
Beta Was this translation helpful? Give feedback.
All reactions