Ship it like infrastructure

One virtual network, private endpoints for everything, and a pipeline that holds no secret.

In this order. Decide the network before you create anything; outbound isolation cannot be added to an existing Foundry resource, only redeployed.

1. Start from Microsoft's template

   Clone the Foundry samples repository and read the Bicep in infrastructure-setup-bicep/15-private-network-standard-agent-setup end to end before running it. Note what it creates and what it does not.

   You can list every resource the template creates from memory, and you noticed it does not create private endpoints for Search, Storage or Cosmos.
2. The network

   A virtual network with three subnets: one for private endpoints, one delegated to Microsoft.App/environments at /27 or larger for the agent client, and one for a firewall. Private DNS zones for every privatelink domain you will need, linked to the network.

   nslookup for the Foundry endpoint from a VM in the network returns a private IP; from your laptop it returns a public one you cannot use.
3. Foundry, standard setup, private

   Deploy the Foundry resource and project with public network access Disabled, a private endpoint, VNet injection into the delegated subnet, and your own Storage, AI Search and Cosmos DB as the standard setup. Then create the private endpoints for those three yourself.

   Four private endpoint connections show Approved. The Foundry portal from your laptop says you cannot reach the project. Good.
4. The agent, in the network

   Deploy the Project 01 agent into this project. Its OpenAPI tool and file search now travel through your subnet and private endpoints; check the tool support table before you rely on any other tool.

   From a VM in the network, the agent answers a warranty question. The Function App's public endpoint is disabled and it still works.
5. Egress

   Route the agent subnet through Azure Firewall with an allowlist of the FQDNs Foundry needs: Entra sign-in, the Application Insights ingestion endpoints, and nothing else.

   The agent still works. A curl to an unrelated site from the same subnet is blocked and the firewall log shows why.
6. The AI gateway

   Put API Management in front of the model deployment with managed identity, and add three policies: llm-token-limit per team key, llm-emit-token-metric with a team dimension, and llm-content-safety. Point the agent at the gateway, not the model.

   Set a 200 tokens-per-minute limit for a test key and get a 429 on the third question. Ours did exactly that: 163 tokens consumed on the first call, 37 remaining; 142 on the second, 0 remaining; then 429 Token limit is exceeded. Try again in 55 seconds. Two things to check while you are there: the x-consumed-tokens and x-remaining-tokens headers come back on every call, and the gateway reaches the model with a managed identity, so there is no key anywhere in the policy.⁴
7. The pipeline

   GitHub Actions with a federated credential to an Entra app: no client secret anywhere. azd provision then azd deploy on push to main, with a manual approval environment gate for production.

   grep -ri secret .github/ finds nothing. A push deploys; a second environment is one variable change away.
8. The second environment

   Create staging from the same templates with different parameters. Run the Project 03 evaluation against it.

   Two identical stacks, and the evaluation scores match within noise.
9. Tear it down

   azd down --purge

   Then check for the things Bicep does not own: the private DNS zone links, the firewall's public IP, and the API Management instance, which can take a while to delete.

   The resource group is empty. Today's cost is under $25, most of it the firewall and gateway hours.

Cause each one on purpose. Private networking fails silently and blames DNS.

• The empty index that reported success An indexer with the default execution environment cannot cross a private endpoint and indexes nothing without an error. Fix: set the indexer's execution environment to Private, then check the document count.
• The private endpoint you assumed The template made the Foundry endpoint private; Search, Storage and Cosmos still had public ones. Fix: create them yourself, and write that in the README so the next person does not assume either.
• The public gateway on a private project An API Management instance created from the Foundry portal is public by default. Fix: configure its own network isolation in the Azure portal, or it is a hole in the fence.
• The gateway that 404s everything An API in API Management with a correct backend URL still returns 404 Resource not found for every call until it has an operation that matches the path. Importing the Azure OpenAI spec gives you them; hand-creating the API does not. Budget the wait, too: a Developer-tier instance took 35 minutes to activate for us, and deleting one is slow enough that it is worth starting before you write the policy.⁴

az apim create --sku-name Developer     # 35 minutes to Activating -> Succeeded
then an API pointing at https://<account>.openai.azure.com/openai
call 1: HTTP 404   Resource not found
the backend was right. the API had no operation to match the path.
PUT .../apis/aoai/operations/chat    # POST /deployments/{deployment}/chat/completions
operation PUT: 201

policy: llm-token-limit tokens-per-minute=200, managed identity to the backend
6 identical calls through the gateway
call 1: HTTP 200   consumed=163  remaining=37
call 2: HTTP 200   consumed=142  remaining=0
call 3: HTTP 429   Token limit is exceeded. Try again in 55 seconds.
call 4: HTTP 429   Token limit is exceeded. Try again in 55 seconds.
the cap held on the third call, and no key appears anywhere in the policy.

• The subnet that is too small A /28 delegated subnet fails VNet injection, and it fails in the worst possible way: the create call returns 201 Created, the resource sits in Creating for several minutes, and only then goes to Failed with no error message on the resource at all. The reason is in the activity log, and it talks about the capability host rather than the subnet: Capability host creation failed with agent messages. Fix: /27 or larger, delegated to Microsoft.App/environments. Same subnet, same everything else, /27 succeeded for us.⁴

the create call is accepted. that is not the same as it working.
PUT .../accounts/campux-inj-agent28   # subnet 10.10.2.0/28, delegated
HTTP 201  ACCEPTED
PUT .../accounts/campux-inj-agent27   # subnet 10.10.3.0/27, delegated
HTTP 201  ACCEPTED

poll provisioningState
poll 1:  /28=Creating   /27=Creating
poll 3:  /28=Creating   /27=Creating
poll 4:  /28=Failed     /27=Creating
final:   /28=Failed     /27=Succeeded

the resource itself carries no error. it is in the activity log:
"code":"ResourceProviderExtensionError","message":"ExtendedErrorInfo:: Kind: AmlRp,
 Code: BadRequest, Message: Capability host creation failed with agent messages"
nothing about subnet size. you would look at the agent config for an hour first.

private endpoints are not created for you. three by hand, then the
dns zone group writes the A records.

az network private-endpoint list -g rg-campux-net -o table
Name        State      Ip         Fqdn
pe-cosmos   Succeeded  10.20.1.6  campux-cosmos.documents.azure.com
pe-search   Succeeded  10.20.1.5  campux-search.search.windows.net
pe-storage  Succeeded  10.20.1.4  campuxnet.blob.core.windows.net
az network private-dns record-set a list -z privatelink.documents.azure.com -g rg-campux-net
campux-cosmos          10.20.1.6
campux-cosmos-eastus   10.20.1.7   <- cosmos writes two, account and region

public access off. now call storage from outside, with a good token.

curl -H "Authorization: Bearer $TOKEN" "https://$SA.blob.core.windows.net/?comp=list"
HTTP 403
<Error><Code>AuthorizationFailure</Code><Message>This request is not authorized to perform this operation.
nothing about the network. that is a role-assignment error message.
az storage container list --account-name $SA --auth-mode login
ERROR: The request may be blocked by network rules of storage account.
the cli says it. the api does not.

now egress, for real: a container in a subnet routed 0.0.0.0/0 -> 10.20.0.4

az container logs -g rg-campux-net -n fwtest
ALLOWED-login.microsoftonline.com
  HTTP 200
BLOCKED-example.com
  HTTP 000
  curl-exit-35
BLOCKED-pypi.org
  HTTP 000
  curl-exit-35

exit 35 is "SSL connect error". the allowlist works, and it will
cost you an hour the first time it stops a package install.

• The 403 that looks like a permissions bug Disable public network access, then call the storage account from your laptop with a perfectly valid bearer token. You get 403 AuthorizationFailure: This request is not authorized to perform this operation. That is the same body a missing role assignment produces, and it says nothing about the network, so the afternoon goes into RBAC. The Azure CLI is kinder about the same call and mentions network rules; raw REST does not. Fix: when a resource has a private endpoint, check the network path before you check the role.⁴
• The allowlist that presents as a broken certificate From inside the locked-down subnet an allowed host answers normally and a host missing from the allowlist fails with curl: (35), an SSL connect error, because the firewall drops the handshake rather than returning a refusal. Nothing anywhere says "blocked by policy". Your pip install fails looking exactly like a corporate TLS problem. Fix: read the firewall logs, not the client error.⁴
• Adding outbound isolation later You deployed public, then tried to add VNet injection. You cannot; redeploy. This is why step 1 says read the template first.
• The firewall that ate tracing Traces stop the moment egress is locked down, because the Application Insights ingestion FQDNs were not on the allowlist. Fix: the list is on Learn; use it.

Standard setup, or basic?

Basic is faster and Microsoft manages the storage. Standard means you own every resource the agent writes to and can put each behind a private endpoint. Regulated data, or a platform team with rules, means standard.

Microsoft's template, or your own Bicep?

Their template encodes decisions that took a team months. Your own is smaller and you understand it. Start from theirs, strip what you do not use, and keep the commit history showing what you removed and why.

A gateway in front of the model, or direct?

Direct is one hop faster. The gateway gives per-team token limits, a metric per team, content safety, load balancing and a place to swap models without touching agents. From the second team onward, the gateway pays for itself.

Firewall, or NAT gateway?

A NAT gateway gives egress without inspection. A firewall gives an allowlist and a log. The allowlist is the compliance answer; the log is how you debug it.

Bicep, or Terraform?

Terraform works for Foundry too and is the right answer in a multi-cloud shop. Bicep is what the Foundry samples are written in, so you inherit the most tested path. Pick the one your platform team already reviews.

The two nslookups

The same hostname resolving private from inside and useless from outside.

The 429

The gateway refusing the third question under a test limit, and the per-team token chart.

The repo

Bicep, the workflow file with no secret in it, and a README that lists what the template does not create.

One sentence for the résumé

"Deployed a Microsoft Foundry agent platform as Bicep from GitHub Actions with federated credentials into a private-endpoint-only network with VNet injection and firewall egress control, fronted by an API Management AI gateway enforcing per-team token limits."