Summary
When a workflow source file sets:
network:
allowed:
- defaults
- telemetry.business.githubcopilot.com
gh aw compile --strict propagates that domain into the main agent execution path, but the compiled detection_agentic_execution step still omits it from its inline awf --allow-domains list.
Reproduction
In a workflow using safe outputs / threat detection:
- Add this top-level frontmatter to the
.md source workflow:
network:
allowed:
- defaults
- telemetry.business.githubcopilot.com
- Run:
- Inspect the generated
.lock.yml.
Observed behavior
The generated lockfile includes the domain in workflow metadata and the main agent execution path:
GH_AW_INFO_ALLOWED_DOMAINS: '["defaults","telemetry.business.githubcopilot.com"]'
GH_AW_ALLOWED_DOMAINS includes telemetry.business.githubcopilot.com
- main step
id: agentic_execution includes telemetry.business.githubcopilot.com in its inline sudo -E awf ... --allow-domains ...
But the generated threat-detection step still omits it:
id: detection_agentic_execution
- inline
sudo -E awf ... --allow-domains ... contains telemetry.enterprise.githubcopilot.com but not telemetry.business.githubcopilot.com
Upstream code evidence
This appears to come from pkg/workflow/threat_detection.go, where the detection job is built from a synthetic workflow context that intentionally discards user-specified allowed domains:
threatDetectionData := &WorkflowData{
...
IsDetectionRun: true,
NetworkPermissions: &NetworkPermissions{
Allowed: []string{}, // no user-specified additional domains; engine provides its own minimal set
},
...
}
The comment suggests this is intentional, but it means workflow-level network.allowed domains do not propagate into the detection AWF invocation even when they are required for the same Copilot engine family.
Why this matters
This creates internally inconsistent compiled output:
- main agent execution can succeed with the extra domain
- detection execution can still fail later if it needs the same domain
That makes workflow source changes look durable for the main path while still leaving a residual failure path in the detection job.
Expected behavior
One of these should happen consistently:
- workflow-level
network.allowed domains should also propagate into detection_agentic_execution, or
- docs/compiler output should clearly state that threat detection uses a separate fixed allowlist and ignores workflow
network.allowed, or
- threat detection should expose a separate supported configuration knob for additional domains.
Notes
I confirmed this in a local repo using current gh aw compile --strict, where the main generated execution path picked up telemetry.business.githubcopilot.com but the detection path did not.
Summary
When a workflow source file sets:
gh aw compile --strictpropagates that domain into the main agent execution path, but the compileddetection_agentic_executionstep still omits it from its inlineawf --allow-domainslist.Reproduction
In a workflow using safe outputs / threat detection:
.mdsource workflow:.lock.yml.Observed behavior
The generated lockfile includes the domain in workflow metadata and the main agent execution path:
GH_AW_INFO_ALLOWED_DOMAINS: '["defaults","telemetry.business.githubcopilot.com"]'GH_AW_ALLOWED_DOMAINSincludestelemetry.business.githubcopilot.comid: agentic_executionincludestelemetry.business.githubcopilot.comin its inlinesudo -E awf ... --allow-domains ...But the generated threat-detection step still omits it:
id: detection_agentic_executionsudo -E awf ... --allow-domains ...containstelemetry.enterprise.githubcopilot.combut nottelemetry.business.githubcopilot.comUpstream code evidence
This appears to come from
pkg/workflow/threat_detection.go, where the detection job is built from a synthetic workflow context that intentionally discards user-specified allowed domains:The comment suggests this is intentional, but it means workflow-level
network.alloweddomains do not propagate into the detection AWF invocation even when they are required for the same Copilot engine family.Why this matters
This creates internally inconsistent compiled output:
That makes workflow source changes look durable for the main path while still leaving a residual failure path in the detection job.
Expected behavior
One of these should happen consistently:
network.alloweddomains should also propagate intodetection_agentic_execution, ornetwork.allowed, orNotes
I confirmed this in a local repo using current
gh aw compile --strict, where the main generated execution path picked uptelemetry.business.githubcopilot.combut the detection path did not.