Threat detection compile path ignores workflow network.allowed domains

[ferryhinardi]

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:

1. Add this top-level frontmatter to the .md source workflow:

network:
  allowed:
    - defaults
    - telemetry.business.githubcopilot.com

2. Run:

gh aw compile --strict

3. 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:

1. workflow-level network.allowed domains should also propagate into detection_agentic_execution, or
2. docs/compiler output should clearly state that threat detection uses a separate fixed allowlist and ignores workflow network.allowed, or
3. 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.

[pelikhan]

@davidslater detection should not need any access outside the firewall.

[davidslater]

@ferryhinardi do you have an example workflow where the detection job was failing for this reason?

We have it specifically locked down beyond that of the main agent to minimize the threat surface and keep it efficiently focused on the actual change input, but if the engine is failing, that is something we need to account for.