Skip to content

[awf] api-proxy: support user-provided service container as pluggable egress proxy #4849

Description

@lpcox

Problem

AWF's built-in api-proxy fully owns the engine→model path and provides no extension point for custom header injection or interposing a user-controlled proxy. Corporate environments requiring secret request headers on every model call (e.g., a gateway demanding a secret auth header) cannot be satisfied today.

Context

Original report: github/gh-aw#38925

Two use cases: (1) LLM request proxy for corporate header injection, (2) OTLP proxy for telemetry fan-out/span mutation.

Root Cause

containers/api-proxy/ intercepts all engine LLM/OTLP traffic, injects real API keys, and performs routing — but exposes no hook for user-defined middleware or header injection. ANTHROPIC_API_KEY is deliberately excluded from agent env, so all model traffic is forced through the built-in proxy with no bypass path.

Proposed Solution

Add a workflow option to declare a GitHub Actions Service container as an intermediate hop. AWF would:

  1. Detect the declared service and its port
  2. Repoint the engine's base URL (ANTHROPIC_BASE_URL, OTEL_EXPORTER_OTLP_ENDPOINT) to that service
  3. Allowlist the service IP in src/squid-config.ts
  4. Wire the service's upstream to the existing api-proxy chain

This avoids expanding the built-in proxy config for every bespoke enterprise requirement.

Generated by Firewall Issue Dispatcher ·

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions