Compiler: extend engine.auth for Anthropic Workload Identity Federation; gate ANTHROPIC_API_KEY validation when WIF configured

[benissimo]

Problem

Two compiler-side gaps block end-to-end use of Anthropic Workload Identity Federation in gh-aw, even after the downstream firewall change (github/gh-aw-firewall#3974) is fixed:

1. EngineAuthConfig only handles Azure. A workflow author can't express engine.auth.type: github-oidc, provider: anthropic, federation-rule-id: ..., organization-id: ..., service-account-id: ..., workspace-id: ... in frontmatter today — the compiler silently drops everything past type and audience.
2. The validate_multi_secret.sh ANTHROPIC_API_KEY runtime step is emitted unconditionally for the Claude engine, so a fully WIF-configured workflow still fails the validation gate before the agent ever runs.

Evidence — EngineAuthConfig

pkg/workflow/engine.go:77:

type EngineAuthConfig struct {
    Type          string
    Audience      string
    AzureTenantID string
    AzureClientID string
    AzureScope    string
    AzureCloud    string
}

parseEngineAuthConfig (pkg/workflow/engine.go:602) and applyEngineAuthEnv (pkg/workflow/engine.go:628) only read/write Azure fields. No FederationRuleID, OrganizationID, ServiceAccountID, WorkspaceID.

The frontmatter schema mirrors this gap: pkg/parser/schemas/main_workflow_schema.json:10638 describes engine.auth purely in Azure-OIDC terms.

The downstream api-proxy (gh-aw-firewall #3974 once fixed) will expect AWF_AUTH_ANTHROPIC_FEDERATION_RULE_ID, AWF_AUTH_ANTHROPIC_ORGANIZATION_ID, AWF_AUTH_ANTHROPIC_SERVICE_ACCOUNT_ID, AWF_AUTH_ANTHROPIC_WORKSPACE_ID — but the compiler has no way to emit them.

Evidence — validate_multi_secret

pkg/workflow/claude_engine.go:55:

func (e *ClaudeEngine) GetRequiredSecretNames(workflowData *WorkflowData) []string {
    return append([]string{"ANTHROPIC_API_KEY"}, collectCommonMCPSecrets(workflowData)...)
}

pkg/workflow/claude_engine.go:61:

func (e *ClaudeEngine) GetSecretValidationStep(workflowData *WorkflowData) GitHubActionStep {
    return BuildDefaultSecretValidationStep(
        workflowData,
        []string{"ANTHROPIC_API_KEY"},
        "Claude Code",
        ...,
    )
}

Neither method checks workflowData.EngineConfig.Auth. So even if a workflow declares engine.auth.type: github-oidc, provider: anthropic, ... correctly, the compiled lock file still calls validate_multi_secret.sh ANTHROPIC_API_KEY 'Claude Code' ... at runtime — failing fast when the secret isn't set, before the api-proxy ever gets a chance to do the WIF exchange.

This was the first failure mode we hit when attempting a gh-aw + WIF workflow (RealPage/ai-internal-enablement PR #586 / run #26449417639).

Proposed changes

1. Extend EngineAuthConfig for Anthropic

type EngineAuthConfig struct {
    Type          string
    Audience      string
    Provider      string  // NEW — "azure" (default), "aws", "gcp", "anthropic"

    // Azure
    AzureTenantID string
    AzureClientID string
    AzureScope    string
    AzureCloud    string

    // AWS (in case the gh-aw-firewall AWS provider is also surfaced later)
    AWSRoleArn  string
    AWSRegion   string

    // Anthropic
    AnthropicFederationRuleID string
    AnthropicOrganizationID   string
    AnthropicServiceAccountID string
    AnthropicWorkspaceID      string
}

Update parseEngineAuthConfig to read these from authObj. Update applyEngineAuthEnv to emit AWF_AUTH_PROVIDER, AWF_AUTH_ANTHROPIC_* (matching the env-var names the api-proxy expects). Update the schema.

2. Skip / relax ANTHROPIC_API_KEY validation when WIF is configured

In ClaudeEngine.GetRequiredSecretNames and GetSecretValidationStep, branch on workflowData.EngineConfig.Auth:

• If Auth.Type == "github-oidc" and Auth.Provider == "anthropic", don't emit the ANTHROPIC_API_KEY validation step. (The api-proxy validates the WIF chain at startup.)
• Else: current behaviour.

Same logic for MCP_GATEWAY_API_KEY and any other secrets that should be ignored when WIF is the credential source.

3. Test coverage

Existing pkg/workflow/engine_config_test.go only covers Azure auth env mapping. Add a parallel test for the Anthropic case asserting:

• All four AWF_AUTH_ANTHROPIC_* env vars land in config.Env
• AWF_AUTH_PROVIDER is anthropic
• The compiled lock file does not include a validate_multi_secret.sh ANTHROPIC_API_KEY step

Working example (when both this and #3974 land)

engine:
  id: claude
  auth:
    type: github-oidc
    provider: anthropic
    federation-rule-id: fdrl_xxxxxxxxxxxxxxxxxxxxxxxx
    organization-id: 00000000-0000-0000-0000-000000000000
    service-account-id: svac_xxxxxxxxxxxxxxxxxxxxxxxx
    # workspace-id: wrkspc_... # only when rule covers multiple workspaces

permissions:
  id-token: write
  contents: read

Reference working POC (plain-YAML, no gh-aw): https://gist.github.com/benissimo/340e7cfb5fdd102c5cd8d39cf91bcc32

Related

• Original upstream request: github/gh-aw-firewall#3843 (closed by #3851)
• Bug in shipped Anthropic OIDC provider: github/gh-aw-firewall#3974

[lpcox]

🔗 AWF tracking issue: https://github.com/github/gh-aw-firewall/issues/github/gh-aw-firewall#3984

Generated by Firewall Issue Dispatcher · sonnet46 2.5M · ◷

[lpcox]

Closing — firewall-side Anthropic WIF support is complete (PRs #3979 and #4012 in gh-aw-firewall). Schema fields, env wiring, and OIDC token exchange all implemented. The remaining compiler-side gating of validate_multi_secret.sh is tracked separately. See github/gh-aw-firewall#4041 for details.

[benissimo]

@lpcox — thanks for closing the firewall-side concern; confirming PRs #3979 and #4012 address my original #3974.

I think this issue (#35561) got closed by mistake on the back of an auto-dispatcher misclassification, though. The two concerns it raises are gh-aw compiler concerns in this repo (Go), not firewall concerns (JS) — and the redirect to gh-aw-firewall#4041 leads to a copy that was also closed without addressing them, in the wrong repo.

Verification — current main of githubnext/gh-aw

I just pulled main after #35561 was closed; the two code paths flagged in the issue are unchanged:

1. pkg/workflow/engine.go:77 — EngineAuthConfig struct still has only Azure fields:

   type EngineAuthConfig struct {
       Type          string
       Audience      string
       AzureTenantID string
       AzureClientID string
       AzureScope    string
       AzureCloud    string
   }

   No FederationRuleID / OrganizationID / ServiceAccountID / WorkspaceID. So parseEngineAuthConfig (line 602) silently drops Anthropic frontmatter fields, and applyEngineAuthEnv (line 628) never emits the AWF_AUTH_ANTHROPIC_* env vars that the firewall side (now correctly) consumes.

2. pkg/workflow/claude_engine.go:55,61 — ClaudeEngine.GetRequiredSecretNames and GetSecretValidationStep still hardcode ANTHROPIC_API_KEY unconditionally:

   func (e *ClaudeEngine) GetRequiredSecretNames(workflowData *WorkflowData) []string {
       return append([]string{"ANTHROPIC_API_KEY"}, collectCommonMCPSecrets(workflowData)...)
   }
   
   func (e *ClaudeEngine) GetSecretValidationStep(workflowData *WorkflowData) GitHubActionStep {
       return BuildDefaultSecretValidationStep(
           workflowData,
           []string{"ANTHROPIC_API_KEY"},
           "Claude Code",
           ...,
       )
   }

   No branch on workflowData.EngineConfig.Auth. A WIF-configured workflow still fails the runtime validate_multi_secret.sh ANTHROPIC_API_KEY step before the agent ever runs.

Why the redirect didn't carry the work

• github/gh-aw-firewall contains the api-proxy (JS, containers/api-proxy/). PRs chore(deps): bump js-yaml from 4.1.0 to 4.1.1 in /docs #3979 and [docs] Consolidate developer specifications: Add template injection diagrams #4012 changed JS files there.
• The compiler concerns in Compiler: extend engine.auth for Anthropic Workload Identity Federation; gate ANTHROPIC_API_KEY validation when WIF configured #35561 live in github/gh-aw Go source under pkg/workflow/. Those files are not in the firewall repo and were not touched by either PR.
• gh-aw-firewall#4041's body was autogenerated by the "Firewall Issue Dispatcher" workflow ingesting Compiler: extend engine.auth for Anthropic Workload Identity Federation; gate ANTHROPIC_API_KEY validation when WIF configured #35561; it describes compiler-side problems but proposes a firewall-side fix and was closed alongside Compiler: extend engine.auth for Anthropic Workload Identity Federation; gate ANTHROPIC_API_KEY validation when WIF configured #35561 the same minute. Net effect: the actual work is unfiled and unimplemented.

Ask

Could this be reopened? The fix is straightforward — extend EngineAuthConfig with the Anthropic fields, wire them through parseEngineAuthConfig / applyEngineAuthEnv to AWF_AUTH_ANTHROPIC_*, and make ClaudeEngine.GetRequiredSecretNames / GetSecretValidationStep branch on Auth.Type == "github-oidc" and Auth.Provider == "anthropic" so the validation step is omitted (or relaxed) when WIF is configured. The full proposed shape is in the original issue body.

Working POC for the wire-level WIF flow: https://gist.github.com/benissimo/340e7cfb5fdd102c5cd8d39cf91bcc32 — happy to test a draft PR against it.

[benissimo]

@lpcox — bumping for visibility on the prior comment. Compiler-side concerns are unaddressed; could you take another look?