Chapter 4 of 6
Decisions and stop conditions#
Record the named owners and approved resources in the customer copy of gateway-inputs.json. The approval flags record decisions Azure cannot infer; set them to true after the responsible owner has checked the corresponding item below. Preflight performs read-only resource and file checks. It does not approve the identity design, WAF rules, or data-handling policy.
| Owner decision | Inspect before approving | Stop when |
|---|---|---|
| Foundry hosting | Model deployment details, Marketplace terms, region scope | Hosting or processing location differs from the residency approval |
| Identity | Two single-tenant apps, token claims, consent, assigned roles | Audience, issuer, or role differs from the policy |
| Budget | Exact lowercase deployment names and monthly allowances | A default or override lacks finance approval |
| Telemetry | Application Insights logger, body bytes, allowed headers, access and retention | A token, prompt, or response body would be logged |
| Network | APIM-to-Foundry reachability and approved client entry point | Clients can bypass a required WAF, or a private backend is unreachable |
| Restore | Prior API policy/settings and client configuration in the approved change store | Restoring the route would remove an unrelated control |
Budget precedence is explicit user-model override, then model default, then zero. An explicit zero blocks that pair. A user absent from the override map receives defaults only after identity authorization succeeds. To block all access, remove the user's app-role assignment or set every enabled model to zero. These examples are token allowances, not recommended spending limits.
UPN is readable but mutable. A rename starts a different counter unless you plan the transition. For durable identity, change the maps and counter consistently to tid:oid before rollout; do not mix identity schemes between clients or change schemes mid-period without a budget decision.
The shipped Code validator expects a v1 access token with audience api://<gateway-api-client-id>. Configure the API registration to issue v1 tokens and verify the actual result locally. Azure CLI does not determine the resource's token version. If the API issues v2 access tokens, update that validator's issuer, discovery URL, audience, and identity claim contract together. Do not add a broad audience fallback.
The backend policy requests https://ai.azure.com, following the current Foundry Claude guidance. It does not reuse the client's gateway audience. If that resource token is rejected by the selected deployment, stop and resolve the hosting/authentication contract with the platform owner.