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 covers the last 7 days of security observability across all agentic workflow runs in the github/gh-aw repository (2026-06-20 through 2026-06-27). Firewall analysis reveals a period of high blocking activity on 2026-06-22 (8,345 blocked requests, 65.2% block rate), driven predominantly by Google/GCP domain access attempts and localhost connections, consistent with browser-automation tooling reaching out-of-policy endpoints. Activity returned to lower levels on 2026-06-24 (776 blocked, 16.0% block rate), and today's fully analyzed runs show 0 blocked requests — today's bulk of 103 firewall-enabled runs are still under analysis. DIFC integrity filtering recorded zero events in this window, indicating no tool calls were flagged for integrity or secrecy violations — a healthy baseline.
Key themes: browser-based workflow sandbox escape attempts via Google APIs; Playwright CDN access blocked as expected; two unexpected blocks of api.github.com and github.com from a run that should have those allowlisted. No cross-cutting issues observed between the two signals.
Note on methodology: The audit tool returns firewall_analysis only for runs whose sandbox analysis has been fully processed. Today's 103 firewall-enabled runs returned null (still processing). Figures for 2026-06-22 and 2026-06-24 are sourced from the security-observability cache (last updated 2026-06-24).
Firewall Request Trends
Firewall activity shows a pronounced spike on 2026-06-22 (8,345 blocked out of 12,792 requests) followed by significant reduction on 2026-06-24 (776 blocked out of 4,844 requests). Today (2026-06-27), the 4 fully analyzed runs show 0 blocked requests — the bulk of today's runs are still being processed. The spike pattern on June 22 corresponds to a high volume of browser-automation or Playwright-based workflow runs that attempted Google API access, which is blocked by default in the sandbox firewall policy.
Top Blocked Domains
Google/GCP domains dominate the blocked list (61% of all blocks), followed by localhost:8080 and unknown endpoints. The presence of playwright-akamai.azureedge.net, playwright-verizon.azureedge.net, and playwright.azureedge.net confirms Playwright browser automation was active in some runs. Critically, proxy.golang.org and docs.astro.build blocks suggest development/build tool activity that may benefit from allowlisting if legitimate.
The current policy uses 9 firewall rules. No per-rule hit attribution was available from the fresh audited runs (all returned 0 blocks). Historical blocks align with the deny-raw-ipv4 and domain-based deny rules.
Investigate api.github.com and github.com blocks: These domains appear in the allowlist of the sandbox firewall policy, yet 2 block events were recorded. Verify the policy version applied to those specific runs and ensure the allow rules are being applied before the deny rules.
Evaluate proxy.golang.org allowlisting: Go module proxy access suggests workflows that build or test Go code. If these are legitimate build operations, consider adding proxy.golang.org to the firewall allowlist for build workflows.
Review antigravity-unleash.goog: Two blocks of the Unleash feature flag service suggest a workflow that relies on this service at runtime. If legitimate, allowlist antigravity-unleash.goog:443.
Document Google/Chrome API access: The high volume of Google domain blocks (>60% of all blocks) is consistent with Playwright/Chromium browser automation. Review whether these runs are expected to access Google APIs; if not, investigate for potential sandbox escape attempts.
Monitor localhost:8080 blocks: 14 blocks of localhost:8080 indicate a workflow is attempting to connect to a local service that isn't running in the sandbox. Review which workflows generate these blocks and whether local service startup ordering is the cause.
Audit docs.astro.build access: One block of the Astro documentation CDN suggests a workflow may be fetching external documentation at runtime — an unusual pattern worth investigating.
DIFC Integrity Analysis
Key DIFC Metrics
Metric
Value
Total filtered events
0
Analysis window
2026-06-20 to 2026-06-27
Status
No events
No DIFC integrity-filtered events found in the last 7 days.
Both the fresh filtered_integrity log query and the cached snapshot (last updated 2026-06-23) confirm zero DIFC gateway events across all workflow runs in this period. This indicates:
No tool calls were blocked by Data Integrity and Flow Control policies
No integrity or secrecy tag violations were detected
The DIFC system is operating cleanly with no false positives or legitimate blocks
DIFC charts (events timeline, top filtered tools, reason breakdown) are not generated as there are no events to visualize.
DIFC Tuning Recommendations
Baseline is healthy — Zero DIFC events across 168+ workflow runs is expected behavior if workflows are accessing only appropriately tagged resources. No immediate tuning required.
Maintain monitoring — Continue daily DIFC analysis. A sudden increase in filtered events would indicate either a new workflow accessing higher-sensitivity data, or a potential policy misconfiguration.
Review DIFC policy coverage — With new workflows being added regularly (103 runs today alone), periodically verify that the DIFC policy covers all new MCP servers and tool categories being deployed.
Generated by the Daily Security Observability workflow (consolidated from Daily Firewall Reporter + Daily DIFC Analyzer) Analysis window: Last 7 days | Repository: github/gh-aw Run: §28294661074
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 covers the last 7 days of security observability across all agentic workflow runs in the
github/gh-awrepository (2026-06-20 through 2026-06-27). Firewall analysis reveals a period of high blocking activity on 2026-06-22 (8,345 blocked requests, 65.2% block rate), driven predominantly by Google/GCP domain access attempts and localhost connections, consistent with browser-automation tooling reaching out-of-policy endpoints. Activity returned to lower levels on 2026-06-24 (776 blocked, 16.0% block rate), and today's fully analyzed runs show 0 blocked requests — today's bulk of 103 firewall-enabled runs are still under analysis. DIFC integrity filtering recorded zero events in this window, indicating no tool calls were flagged for integrity or secrecy violations — a healthy baseline.Key themes: browser-based workflow sandbox escape attempts via Google APIs; Playwright CDN access blocked as expected; two unexpected blocks of
api.github.comandgithub.comfrom a run that should have those allowlisted. No cross-cutting issues observed between the two signals.Firewall Analysis
Key Firewall Metrics
Firewall Request Trends
Firewall activity shows a pronounced spike on 2026-06-22 (8,345 blocked out of 12,792 requests) followed by significant reduction on 2026-06-24 (776 blocked out of 4,844 requests). Today (2026-06-27), the 4 fully analyzed runs show 0 blocked requests — the bulk of today's runs are still being processed. The spike pattern on June 22 corresponds to a high volume of browser-automation or Playwright-based workflow runs that attempted Google API access, which is blocked by default in the sandbox firewall policy.
Top Blocked Domains
Google/GCP domains dominate the blocked list (61% of all blocks), followed by
localhost:8080and unknown endpoints. The presence ofplaywright-akamai.azureedge.net,playwright-verizon.azureedge.net, andplaywright.azureedge.netconfirms Playwright browser automation was active in some runs. Critically,proxy.golang.organddocs.astro.buildblocks suggest development/build tool activity that may benefit from allowlisting if legitimate.Most Frequently Blocked Domains
Policy Rule Attribution
Policy: 9 rules, SSL Bump disabled, DLP disabled
The current policy uses 9 firewall rules. No per-rule hit attribution was available from the fresh audited runs (all returned 0 blocks). Historical blocks align with the
deny-raw-ipv4and domain-based deny rules.View Firewall Audited Runs Detail
Domains accessed by audited runs (all allowed):
api.githubcopilot.com:443— GitHub Copilot APIapi.anthropic.com:443— Anthropic Claude APIgithub.com:443— GitHubo205451.ingest.us.sentry.io:443— Sentry telemetryotlp-gateway-prod-eu-west-2.grafana.net:443— Grafana OTLPView Complete Blocked Domains List (Alphabetical)
Firewall Security Recommendations
Investigate
api.github.comandgithub.comblocks: These domains appear in the allowlist of the sandbox firewall policy, yet 2 block events were recorded. Verify the policy version applied to those specific runs and ensure the allow rules are being applied before the deny rules.Evaluate
proxy.golang.orgallowlisting: Go module proxy access suggests workflows that build or test Go code. If these are legitimate build operations, consider addingproxy.golang.orgto the firewall allowlist for build workflows.Review
antigravity-unleash.goog: Two blocks of the Unleash feature flag service suggest a workflow that relies on this service at runtime. If legitimate, allowlistantigravity-unleash.goog:443.Document Google/Chrome API access: The high volume of Google domain blocks (>60% of all blocks) is consistent with Playwright/Chromium browser automation. Review whether these runs are expected to access Google APIs; if not, investigate for potential sandbox escape attempts.
Monitor localhost:8080 blocks: 14 blocks of
localhost:8080indicate a workflow is attempting to connect to a local service that isn't running in the sandbox. Review which workflows generate these blocks and whether local service startup ordering is the cause.Audit
docs.astro.buildaccess: One block of the Astro documentation CDN suggests a workflow may be fetching external documentation at runtime — an unusual pattern worth investigating.DIFC Integrity Analysis
Key DIFC Metrics
No DIFC integrity-filtered events found in the last 7 days.
Both the fresh
filtered_integritylog query and the cached snapshot (last updated 2026-06-23) confirm zero DIFC gateway events across all workflow runs in this period. This indicates:DIFC charts (events timeline, top filtered tools, reason breakdown) are not generated as there are no events to visualize.
DIFC Tuning Recommendations
Baseline is healthy — Zero DIFC events across 168+ workflow runs is expected behavior if workflows are accessing only appropriately tagged resources. No immediate tuning required.
Maintain monitoring — Continue daily DIFC analysis. A sudden increase in filtered events would indicate either a new workflow accessing higher-sensitivity data, or a potential policy misconfiguration.
Review DIFC policy coverage — With new workflows being added regularly (103 runs today alone), periodically verify that the DIFC policy covers all new MCP servers and tool categories being deployed.
Generated by the Daily Security Observability workflow (consolidated from Daily Firewall Reporter + Daily DIFC Analyzer)
Analysis window: Last 7 days | Repository: github/gh-aw
Run: §28294661074
Beta Was this translation helpful? Give feedback.
All reactions