Ensure HTTP MCP GitHub OIDC bypasses the AWF agent credential boundary

[lpcox]

Context

github/gh-aw-firewall#6894 removes ACTIONS_ID_TOKEN_REQUEST_URL and ACTIONS_ID_TOKEN_REQUEST_TOKEN from the AWF agent environment across default passthrough, --env-all, env files, and explicit env configuration. It preserves direct OIDC forwarding to AWF's API proxy sidecar.

That security boundary is correct for gh-aw's MCP architecture, but gh-aw should validate the compiler/runtime contract and update any stale assumptions before the firewall change ships broadly.

Verified current architecture

The current gh-aw architecture does not require a runner -> AWF agent -> MCP gateway credential path:

• The compiler generates a separate runner-owned Start MCP Gateway workflow step (pkg/workflow/mcp_setup_gateway.go).
• That step launches the mcpg container directly with docker run; AWF does not launch or configure mcpg.
• HTTP MCP auth.type: github-oidc is represented in the mcpg stdin configuration as auth metadata (type and optional audience), not as Actions credential values.
• The generated gateway launch currently detects HTTP MCP GitHub OIDC and conditionally adds -e ACTIONS_ID_TOKEN_REQUEST_URL and -e ACTIONS_ID_TOKEN_REQUEST_TOKEN to the mcpg container.
• mcpg uses those runtime variables to mint an audience-bound GitHub Actions JWT and injects it as Bearer authentication on the remote MCP request.

Existing unit/compiler tests assert the conditional docker run -e flags and rendered auth metadata. They do not appear to exercise the complete runner/gateway/agent boundary against AWF behavior from #6894.

The credential flow described in gh-aw ADR-0001 and the original rationale for gh-aw-firewall#1796 assumes an unnecessary runner -> agent -> gateway path. In the generated architecture, the runner can and should pass the Actions OIDC capability directly to the separately launched gateway while the sandboxed agent receives neither variable.

Requested work

Validate and, where necessary, update the compiler/runtime integration so every supported generated lock-workflow topology passes the Actions OIDC runtime variables directly from the Actions runner's Start MCP Gateway step into the gateway container, never through the AWF agent.

If the current compiler already satisfies the runtime behavior for all supported engines/sandbox modes, treat this primarily as compatibility validation and regression hardening: add the missing end-to-end boundary coverage and update stale ADRs, docs, comments, and tests that imply the agent must receive or relay these values.

Do not propose or make mcpg changes unless the investigation demonstrates that its existing audience-bound token minting or Bearer injection is incompatible with this boundary.

Acceptance criteria

• The compiler detects an HTTP MCP server configured with auth.type: github-oidc.
• The generated workflow grants the relevant job id-token: write permission for that configuration.
• The gateway stdin configuration contains only OIDC auth metadata, including the requested audience when configured, and never contains ACTIONS_ID_TOKEN_REQUEST_URL, ACTIONS_ID_TOKEN_REQUEST_TOKEN, or their runtime values.
• The runner-owned Start MCP Gateway step conditionally passes both ACTIONS_ID_TOKEN_REQUEST_URL and ACTIONS_ID_TOKEN_REQUEST_TOKEN directly to the gateway launch for HTTP MCP GitHub OIDC across all supported engines and sandbox/runtime topologies.
• The AWF sandboxed agent receives neither Actions OIDC variable, including through default passthrough, --env-all, env-file, or explicit-env paths.
• Remote MCP calls still receive an audience-bound JWT as a Bearer token minted by the gateway.
• Workflows without HTTP MCP github-oidc auth pass neither Actions OIDC variable to the gateway or agent.
• An integration/regression test covers the runner -> gateway and runner -/-> AWF agent boundary using the behavior introduced by gh-aw-firewall#6894, rather than checking only generated command text.
• Compatibility is evaluated for previously compiled .lock.yml workflows. Document and implement the safe rollout behavior: either demonstrate that supported existing locks continue to work with Unbloat engines.md: reduce documentation by 36% while preserving technical content #6894 or identify the affected compiler versions and provide a clear recompile/version-gating migration path before removing the AWF fallback.
• ADR-0001 and any other stale documentation, comments, or tests are corrected to describe the direct runner -> gateway credential path and AWF's lack of responsibility for launching/configuring mcpg.