Expose network.allowed as a workflow_call input for reusable workflows

[norrietaylor]

Use case

Agentic workflows distributed as reusable workflow_call locks: one repo hosts compiled .lock.yml workers, many consumer repos invoke them through thin wrappers (uses: owner/repo/.github/workflows/x.lock.yml@ref). Consumers span language ecosystems — Rust, Python, Go, Node.

Limitation

network.allowed compiles statically into the .lock.yml (awf-config.json allowDomains). The compiled lock's on.workflow_call exposes only aw_context as an input. A consumer wrapper cannot extend or override the allowlist without forking the source .md and recompiling its own lock — which defeats central hosting.

The only workaround is a superset in the central source:

network:
  allowed: [defaults, rust, python, go]

Every consumer's agent then gets egress to every ecosystem's registries regardless of which it uses — a Go consumer's agent can reach crates.io and PyPI. Functional, but over-grants.

Proposal

Expose the network allowlist as a workflow_call input on the compiled lock, so a consumer wrapper passes its own ecosystem domains:

# consumer wrapper
jobs:
  run:
    uses: owner/repo/.github/workflows/worker.lock.yml@v1
    with:
      network_allowed: rust

The compiler unions the input with the source's network.allowed: the source sets a floor (defaults), the consumer extends it for its ecosystem. Least-privilege per consumer, central hosting preserved.

Gate it behind a frontmatter opt-in (e.g. network.allowed-input: true) so workflows that want a fixed allowlist keep one.

Context

Surfaced operating a multi-repo agentic-chore fleet. A Rust consumer's worker hit Firewall blocked index.crates.io because the central lock's defaults omits crates.io. The superset resolves it but is coarser than per-consumer scoping would be.