[awf] Support Microsoft Foundry decision models through the credential-isolated API proxy #11344

Upstream companion

Relates to github/gh-aw#74832.

This tracks only the AWF-side portion of the request. Workflow frontmatter, typed job outputs, confidence gates, and safe-output integration belong in github/gh-aw.

Problem

The upstream request proposes inexpensive decision/classification calls, including Microsoft-Decision-1 deployed on Microsoft Foundry, instead of a full generative agent run. A custom host-side curl step is possible today, but leaves authentication, sandbox routing, and usage reporting to every workflow author.

Current AWF has native Decisions forwarding and conformance coverage for OpenAI/Copilot paths. Its maintained Decisions model evidence currently covers exact OpenAI gpt-6-luna and Copilot gpt-6-luna-decisions identities, not Microsoft-Decision-1 or an arbitrary Foundry deployment. Existing Azure target/auth support is a useful primitive, but does not establish that this particular model's protocol, credentials, usage, and accounting work.

The newly merged github/gh-aw#76008 adds skip-if-decision using existing proxy endpoints. It does not by itself establish Foundry decision-model support.

Evidence

Reviewed AWF main at 76a054a73c712bf36b82e93b204a9936b7eafee5:

• containers/api-proxy/server.decisions.test.js: native Decisions forwarding, custom base paths, policy, usage, and failure cases.
• shared/model-information/sources/decisions.json: exact-model protocol evidence for OpenAI and Copilot.
• containers/api-proxy/providers/openai.js and docs/auth-matrix.md: existing custom-target/Azure authentication mechanisms to reuse where compatible.

No AWF defect in an actual Microsoft-Decision-1 request has been reproduced by this audit. This is a missing supported-provider contract and acceptance coverage, not a claim that generic forwarding is necessarily broken.

Proposed AWF work

1. Establish the exact supported Foundry deployment endpoint, native request/response format, API version, authentication, and usage fields from provider documentation and a bounded authorized reproduction. Do not assume compatibility with OpenAI /decisions from the model's purpose or name.
2. Reuse existing custom-target, base-path, and Azure key/Entra OIDC handling if the native protocol is compatible. Add only the missing provider-specific handling; do not introduce a new listener or translate between protocols without a demonstrated requirement and reviewed contract.
3. Keep real Foundry credentials and OIDC exchange material in the trusted sidecar. The agent should use an internal proxy endpoint with no upstream secrets.
4. Preserve model restrictions, request/invocation limits, and applicable budget enforcement. Parse the provider's actual usage and report unsupported or unknown pricing explicitly rather than inventing a rate or silently treating it as free. Preserve typed answers and refusals without injecting chat-only fields.
5. Publish the exact supported model/deployment and authentication contract, runtime configuration, and minimum AWF version so gh-aw can integrate and version-gate it.

Acceptance criteria

• A documented Foundry decision-model request reaches a mock upstream through the real proxy with the correct path, version, headers, and body; predicate/choice/score coverage follows the provider's actual supported capabilities.
• Static-key and Entra OIDC cases are covered where supported, with no upstream credentials visible to the agent or public diagnostics.
• Model-policy rejection, usage/accounting, unsupported pricing/capabilities, malformed answers, upstream errors, timeouts, and request-size limits have focused regressions.
• Existing OpenAI/Copilot Decisions behavior remains unchanged.
• Record an authorized live Foundry smoke result before claiming end-to-end availability; until then distinguish protocol coverage from live provider support.

Out of scope

Implementing gh-aw's classification frontmatter, configuring workflow secrets, adding a new agent engine, and automatically changing user workflows. This companion does not close the broader upstream request.