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
This report combines two complementary security signals across the last 7 days for the github/gh-aw repository. Note on data window: the audit tooling returns the 100 most recent firewall-enabled runs and 12 most recent DIFC-filtered runs available; in practice these spanned a much shorter recent window (roughly a few hours to ~2 days) rather than the full 7 days, since the repository runs a very high volume of agentic workflows. The analysis below reflects that available data faithfully.
Firewall telemetry across 92 analyzed workflow runs shows a low overall block rate (1.56%) with 90 blocked requests out of 5,752 total. Blocking activity concentrates on a small set of domains — most notably ab.chatgpt.com:443 (40 blocks, likely a Copilot/OpenAI telemetry or analytics endpoint not currently allowlisted) and github.com:443 (30 blocks, unusual since GitHub API access is normally expected — worth investigating whether these are non-API paths or rate-limited calls). No large-scale exfiltration or clearly malicious domains were observed.
On the DIFC side, 410 integrity-filtered tool-call events were recorded across 8 distinct workflows, overwhelmingly on list_issues (260) and search_issues (133) calls against the github MCP server. All filtering was attributed to the integrity category (no secrecy-tag filtering observed), driven by none:public (410) and unapproved:public (287) integrity tags — indicating the DIFC policy is consistently blocking access to public GitHub issues/PRs that haven't been explicitly approved for agent consumption. Workflow Normalizer (179 events) and the Smoke Agent: public/approved test workflow (130 events) account for the majority of filtered activity, with the latter being expected smoke-test behavior validating the DIFC boundary itself.
🔥 Firewall Analysis
Key Firewall Metrics
Metric
Value
Workflows analyzed (firewall-enabled)
92 (of 100 collected; 8 runs had no firewall_analysis data)
Total network requests monitored
5,752
✅ Allowed requests
5,662
🚫 Blocked requests
90
Block rate
1.56%
Total unique blocked domains
7
📈 Firewall Request Trends
The available data window spans roughly 4 hours (11:00–15:00 UTC on 2026-09-02), reflecting the volume of the 100 most recent firewall-enabled runs rather than a full calendar week. Blocked request volume tracks proportionally with allowed volume (peaking together around 13:00–14:00 UTC), suggesting blocks are a steady background rate tied to overall workflow throughput rather than a sudden spike or attack pattern.
Top Blocked Domains
ab.chatgpt.com:443 and github.com:443 dominate blocked traffic. The former appears repeatedly across many unrelated workflows (AI Moderator, Issue Monster, PureLock, Workflow Normalizer, etc.), suggesting it's likely a common OpenAI/ChatGPT client-side analytics or update-check endpoint triggered by an underlying tool/library rather than a targeted security concern. github.com:443 blocks across PR-focused workflows (PR Code Quality Reviewer, PR Sous Chef, Test Quality Sentinel) warrant a closer look — these may be legitimate GitHub API/web calls being blocked due to path or method restrictions in the firewall policy.
Most Frequently Blocked Domains
Domain
Times Blocked
Workflows
Category
ab.chatgpt.com:443
40
AI Moderator, Daily Credit Limit Test, Daily Go Test Parallelizer, Issue Monster, Issue Triage Agent, Ponytail Reviewer, PureLock, Workflow Normalizer
Telemetry/Analytics
github.com:443
30
PR Code Quality Reviewer, PR Sous Chef, Test Quality Sentinel
Rule-level hit/deny attribution (policy_analysis.rule_hits) was not populated in the audit data for these runs — the policy summary confirms an 11-rule egress policy is active, but per-rule counters were empty across all 92 audited runs. This is worth flagging to the audit tooling maintainers as a potential gap in policy_analysis reporting.
View Detailed Request Patterns by Workflow
Blocking is concentrated in a long tail of individual runs rather than any single workflow dominating overall traffic. Workflows with multiple firewall-enabled runs in this window (e.g., PR Sous Chef, Issue Monster, PR Code Quality Reviewer) show occasional single-digit blocks per run, consistent with incidental blocked calls (e.g., telemetry beacons) rather than systematic policy violations. No workflow showed blocked requests exceeding ~10% of its total request volume.
View Complete Blocked Domains List
and (likely a log-parsing artifact, not a real domain)
ab.chatgpt.com:443
api.anthropic.com:443
github.com:443
proxy.golang.org:443
registry.npmjs.org:443
storage.googleapis.com:443
(unknown) — domain could not be resolved from the log entry
🔒 Firewall Security Recommendations
Allowlist ab.chatgpt.com:443 if it is confirmed to be a benign OpenAI/ChatGPT client telemetry endpoint used by the Copilot/AI engine runtime — this would eliminate the largest source of blocked-request noise (40 of 90 blocks).
Investigate github.com:443 blocks in PR-review workflows (PR Code Quality Reviewer, PR Sous Chef, Test Quality Sentinel) — confirm whether these are legitimate github.com web-page fetches (as opposed to api.github.com) that should be added to the network allowlist, or whether they represent an unexpected/undesired access pattern.
Fix the (unknown)/and domain-logging artifacts — 9 blocks resolve to (unknown) and 1 to the literal string and, indicating a log-parsing or domain-extraction bug in the firewall log pipeline that should be reported upstream.
No action needed for api.anthropic.com:443, registry.npmjs.org:443, storage.googleapis.com:443, proxy.golang.org:443 — low-frequency, workflow-appropriate (AI provider, npm, GCS, Go proxy) blocks that are expected under a default-deny egress policy; add to allowlists only if a specific workflow requires ongoing access.
Request policy_analysis.rule_hits population from the audit tooling team — rule-level attribution was empty across all 92 runs, limiting the ability to tie specific blocks back to specific firewall policy rules.
🔒 DIFC Integrity Analysis
Key DIFC Metrics
Metric
Value
Total filtered events
410
Unique tools filtered
6
Unique workflows affected
8
Most common filter reason
integrity (100%)
Busiest day
2026-09-01 (354 events)
📈 DIFC Events Over Time
Filtering activity is heavily front-loaded on 2026-09-01 (354 of 410 events, 86%), dropping to 56 events on 2026-09-02. The 2026-09-01 spike aligns with the Smoke Agent test suite and Workflow Normalizer runs, both of which intentionally exercise the DIFC boundary (smoke tests) or process large volumes of public issues (Workflow Normalizer), rather than indicating a security incident.
🔧 Top Filtered Tools
list_issues (260) and search_issues (133) together account for 96% of all filtered calls. Both tools return bulk collections of GitHub issues, and the DIFC integrity boundary is correctly blocking access to unapproved public issue content within those result sets — this is the expected behavior for an integrity-below-threshold read pattern, not a misconfiguration.
🏷️ Filter Reasons and Tags
100% of filtered events were categorized as integrity filtering; no secrecy-tag filtering occurred in this window. Within integrity tags, none:public (410, i.e. every filtered event) and unapproved:public (287) dominate, with only 7 events tagged approved:public (likely borderline cases where partial approval existed but another integrity constraint still triggered filtering).
📋 Per-Workflow DIFC Breakdown
Workflow
Filtered Events
Workflow Normalizer
179
Smoke Agent: public/approved
130
Smoke Temporary ID
47
Issue Triage Agent
23
Smoke Agent: all/merged
13
GitHub Remote MCP Authentication Test
10
Smoke Agent: scoped/approved
6
GitHub MCP Structural Analysis
2
📋 Per-Server DIFC Breakdown
MCP Server
Filtered Events
github
410
👤 Per-User DIFC Breakdown
Author Login
Filtered Events
unknown
387
v1v
5
ilja
4
kkruel8100
4
mouorad86-crypto
2
loganrosen
2
lpcox
2
massirr
2
MattSkala
1
GregoireW
1
💡 DIFC Tuning Recommendations
Workflow Normalizer's high filter count (179 events) is expected but worth periodic review — this workflow iterates over public GitHub issues in bulk, so a steady stream of none:public/unapproved:public filtering is inherent to its design. If false-positive filtering is suspected (i.e., issues that should be approved but aren't), review the approval-tagging pipeline that feeds integrity labels.
Investigate the author_login: unknown majority (387 of 410 events, 94%) — most filtered events lack an attributable author, which limits per-contributor auditability. Confirm whether this is expected (e.g., events triggered by scheduled/system runs rather than a specific human actor) or a gap in how author_login is populated by the gateway.
Smoke Agent test workflows (public/approved, all/merged, scoped/approved) account for ~35% of filtering (149 events) — this is expected smoke-test behavior validating the DIFC integrity boundary itself; no tuning action needed, but confirm these are excluded from any alerting thresholds to avoid noise.
No secrecy-tag filtering observed in this window — if secrecy-based DIFC controls are configured, verify they are still active and simply had no matching events, rather than being silently disabled.
list_issues/search_issues dominance suggests bulk-read tools are the primary integrity-filtering surface — consider whether these tools could pre-filter at the API/query level (e.g., only fetching approved-label issues) to reduce downstream filtering overhead, if performance becomes a concern.
Generated by the Daily Security Observability workflow (consolidated from Daily Firewall Reporter + Daily DIFC Analyzer) Analysis window: Last 7 days (data availability limited to most recent ~100 firewall-enabled and ~12 DIFC-filtered runs, spanning approximately 1–2 days due to high workflow volume) | Repository: github/gh-aw Run: https://github.com/github/gh-aw/actions/runs/33651426352
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
This report combines two complementary security signals across the last 7 days for the
github/gh-awrepository. Note on data window: the audit tooling returns the 100 most recent firewall-enabled runs and 12 most recent DIFC-filtered runs available; in practice these spanned a much shorter recent window (roughly a few hours to ~2 days) rather than the full 7 days, since the repository runs a very high volume of agentic workflows. The analysis below reflects that available data faithfully.Firewall telemetry across 92 analyzed workflow runs shows a low overall block rate (1.56%) with 90 blocked requests out of 5,752 total. Blocking activity concentrates on a small set of domains — most notably
ab.chatgpt.com:443(40 blocks, likely a Copilot/OpenAI telemetry or analytics endpoint not currently allowlisted) andgithub.com:443(30 blocks, unusual since GitHub API access is normally expected — worth investigating whether these are non-API paths or rate-limited calls). No large-scale exfiltration or clearly malicious domains were observed.On the DIFC side, 410 integrity-filtered tool-call events were recorded across 8 distinct workflows, overwhelmingly on
list_issues(260) andsearch_issues(133) calls against thegithubMCP server. All filtering was attributed to theintegritycategory (no secrecy-tag filtering observed), driven bynone:public(410) andunapproved:public(287) integrity tags — indicating the DIFC policy is consistently blocking access to public GitHub issues/PRs that haven't been explicitly approved for agent consumption.Workflow Normalizer(179 events) and theSmoke Agent: public/approvedtest workflow (130 events) account for the majority of filtered activity, with the latter being expected smoke-test behavior validating the DIFC boundary itself.🔥 Firewall Analysis
Key Firewall Metrics
📈 Firewall Request Trends
The available data window spans roughly 4 hours (11:00–15:00 UTC on 2026-09-02), reflecting the volume of the 100 most recent firewall-enabled runs rather than a full calendar week. Blocked request volume tracks proportionally with allowed volume (peaking together around 13:00–14:00 UTC), suggesting blocks are a steady background rate tied to overall workflow throughput rather than a sudden spike or attack pattern.
Top Blocked Domains
ab.chatgpt.com:443andgithub.com:443dominate blocked traffic. The former appears repeatedly across many unrelated workflows (AI Moderator, Issue Monster, PureLock, Workflow Normalizer, etc.), suggesting it's likely a common OpenAI/ChatGPT client-side analytics or update-check endpoint triggered by an underlying tool/library rather than a targeted security concern.github.com:443blocks across PR-focused workflows (PR Code Quality Reviewer, PR Sous Chef, Test Quality Sentinel) warrant a closer look — these may be legitimate GitHub API/web calls being blocked due to path or method restrictions in the firewall policy.Most Frequently Blocked Domains
ab.chatgpt.com:443github.com:443(unknown)api.anthropic.com:443registry.npmjs.org:443storage.googleapis.com:443proxy.golang.org:443andPolicy Rule Attribution
📋 Policy: 11 rules, SSL Bump disabled, DLP disabled
Rule-level hit/deny attribution (
policy_analysis.rule_hits) was not populated in the audit data for these runs — the policy summary confirms an 11-rule egress policy is active, but per-rule counters were empty across all 92 audited runs. This is worth flagging to the audit tooling maintainers as a potential gap inpolicy_analysisreporting.View Detailed Request Patterns by Workflow
Blocking is concentrated in a long tail of individual runs rather than any single workflow dominating overall traffic. Workflows with multiple firewall-enabled runs in this window (e.g., PR Sous Chef, Issue Monster, PR Code Quality Reviewer) show occasional single-digit blocks per run, consistent with incidental blocked calls (e.g., telemetry beacons) rather than systematic policy violations. No workflow showed blocked requests exceeding ~10% of its total request volume.
View Complete Blocked Domains List
and(likely a log-parsing artifact, not a real domain)ab.chatgpt.com:443api.anthropic.com:443github.com:443proxy.golang.org:443registry.npmjs.org:443storage.googleapis.com:443(unknown)— domain could not be resolved from the log entry🔒 Firewall Security Recommendations
ab.chatgpt.com:443if it is confirmed to be a benign OpenAI/ChatGPT client telemetry endpoint used by the Copilot/AI engine runtime — this would eliminate the largest source of blocked-request noise (40 of 90 blocks).github.com:443blocks in PR-review workflows (PR Code Quality Reviewer, PR Sous Chef, Test Quality Sentinel) — confirm whether these are legitimategithub.comweb-page fetches (as opposed toapi.github.com) that should be added to the network allowlist, or whether they represent an unexpected/undesired access pattern.(unknown)/anddomain-logging artifacts — 9 blocks resolve to(unknown)and 1 to the literal stringand, indicating a log-parsing or domain-extraction bug in the firewall log pipeline that should be reported upstream.api.anthropic.com:443,registry.npmjs.org:443,storage.googleapis.com:443,proxy.golang.org:443— low-frequency, workflow-appropriate (AI provider, npm, GCS, Go proxy) blocks that are expected under a default-deny egress policy; add to allowlists only if a specific workflow requires ongoing access.policy_analysis.rule_hitspopulation from the audit tooling team — rule-level attribution was empty across all 92 runs, limiting the ability to tie specific blocks back to specific firewall policy rules.🔒 DIFC Integrity Analysis
Key DIFC Metrics
📈 DIFC Events Over Time
Filtering activity is heavily front-loaded on 2026-09-01 (354 of 410 events, 86%), dropping to 56 events on 2026-09-02. The 2026-09-01 spike aligns with the
Smoke Agenttest suite andWorkflow Normalizerruns, both of which intentionally exercise the DIFC boundary (smoke tests) or process large volumes of public issues (Workflow Normalizer), rather than indicating a security incident.🔧 Top Filtered Tools
list_issues(260) andsearch_issues(133) together account for 96% of all filtered calls. Both tools return bulk collections of GitHub issues, and the DIFC integrity boundary is correctly blocking access to unapproved public issue content within those result sets — this is the expected behavior for an integrity-below-threshold read pattern, not a misconfiguration.🏷️ Filter Reasons and Tags
100% of filtered events were categorized as
integrityfiltering; nosecrecy-tag filtering occurred in this window. Within integrity tags,none:public(410, i.e. every filtered event) andunapproved:public(287) dominate, with only 7 events taggedapproved:public(likely borderline cases where partial approval existed but another integrity constraint still triggered filtering).📋 Per-Workflow DIFC Breakdown
📋 Per-Server DIFC Breakdown
👤 Per-User DIFC Breakdown
💡 DIFC Tuning Recommendations
none:public/unapproved:publicfiltering is inherent to its design. If false-positive filtering is suspected (i.e., issues that should be approved but aren't), review the approval-tagging pipeline that feeds integrity labels.author_login: unknownmajority (387 of 410 events, 94%) — most filtered events lack an attributable author, which limits per-contributor auditability. Confirm whether this is expected (e.g., events triggered by scheduled/system runs rather than a specific human actor) or a gap in howauthor_loginis populated by the gateway.Smoke Agenttest workflows (public/approved, all/merged, scoped/approved) account for ~35% of filtering (149 events) — this is expected smoke-test behavior validating the DIFC integrity boundary itself; no tuning action needed, but confirm these are excluded from any alerting thresholds to avoid noise.list_issues/search_issuesdominance suggests bulk-read tools are the primary integrity-filtering surface — consider whether these tools could pre-filter at the API/query level (e.g., only fetching approved-label issues) to reduce downstream filtering overhead, if performance becomes a concern.Generated by the Daily Security Observability workflow (consolidated from Daily Firewall Reporter + Daily DIFC Analyzer)
Analysis window: Last 7 days (data availability limited to most recent ~100 firewall-enabled and ~12 DIFC-filtered runs, spanning approximately 1–2 days due to high workflow volume) | Repository: github/gh-aw
Run: https://github.com/github/gh-aw/actions/runs/33651426352
All reactions