Network-Isolated Foundry IQ: A Verified Enterprise Blueprint

A checklist-driven, auditor-ready blueprint for running Foundry IQ and the Foundry Agent Service with zero public data plane.

Regulated enterprises — electric utilities under NERC CIP, government, financial services, oil & gas — want the productivity of Foundry IQ (Azure AI Search Knowledge Bases) and the Foundry Agent Service that consumes them over MCP, but only if the entire AI data plane stays inside the customer VNet. No public endpoints. No keys. No exceptions.

This guide does not merely describe that architecture — it proves it. Every command, payload, and output below was executed against a real Azure deployment in West US 3, and the result of each step is captured as one of 9 acceptance criteria (AC1–AC9).

What you'll be able to tell your auditor: "The Foundry IQ Knowledge Base and the agent that queries it run entirely on private endpoints inside our VNet. We have an executed test that proves the identical data-plane calls succeed on the in-VNet jumpbox and fail with HTTP 403 from anywhere outside the network."

The sample workload is Contoso Grid, a fictional ISO/utility. Its knowledge base grounds on NERC CIP access-control policy, a SCADA network-segmentation standard, a substation incident-response runbook, and control-room operating procedures.

Architecture

flowchart LR
  subgraph VNet["Customer VNet (10.42.0.0/16) — West US 3"]
    subgraph peSub["pe-subnet 10.42.1.0/24 (private endpoints)"]
      PEsearch[PE: AI Search]
      PEaoai[PE: Foundry/OpenAI]
      PEblob[PE: Blob]
      PEcosmos[PE: Cosmos]
    end
    subgraph jbSub["jumpbox-subnet 10.42.2.0/24"]
      JB[Jumpbox VM<br/>no public IP]
    end
  end
  Search[(AI Search<br/>Foundry IQ KB)]
  AOAI[(Foundry account<br/>gpt-4.1-mini + embeddings)]
  Blob[(Storage)]
  Cosmos[(Cosmos)]
  JB --> PEsearch --> Search
  JB --> PEaoai --> AOAI
  Search -. shared private link .-> PEblob --> Blob
  Search -. shared private link .-> PEaoai
  AOAI --> PEcosmos --> Cosmos
  Internet((Public Internet)) x--x|403 publicNetworkAccess:Disabled| Search

Choose your isolation model — BYO VNet vs. Managed VNet

Microsoft offers two recommended ways to network-isolate the Foundry Agent Service. Both are best-practice — they differ in who builds and operates the network. Pick deliberately before you provision, because the choice is hard to reverse.

This guide implements BYO VNet end-to-end, because the regulated grid / gov / FSI customers it targets typically mandate that agent compute runs inside their VNet, behind their firewall, reachable from their on-prem hub. If you don't carry that mandate and simply want exfiltration-protected isolation with the least effort, use Managed VNet — fewer moving parts, no subnet/IP planning, no jumpbox to build. See Appendix A for the Managed VNet path.

⚠️ The part that's identical either way. Network isolation for Foundry IQ itself (Azure AI Search) is the same in both models: you still set publicNetworkAccess=Disabled, add an inbound private endpoint, create shared private links to Blob + the Foundry/OpenAI account, and you still need an in-VNet path (Azure Bastion) to create and query Knowledge Bases. Managed VNet simplifies the agent-compute network — it does not remove the Search data-plane bootstrap (Steps 2–6 below). Budget for it regardless of which model you choose.

📚 Docs: Set up private networking for Foundry Agent Service · Deep dive into Foundry Agent Service networking · Configure managed virtual network

How the isolation actually works — the two-context mental model

Once Azure AI Search has publicNetworkAccess=Disabled plus an inbound private endpoint, your laptop (off-VNet) can no longer reach the data plane — and that failure is the proof of isolation. So the work splits cleanly into two contexts:

• Off-VNet (control plane): everything that goes through Azure Resource Manager (ARM). Bicep deployment, model deployments, RBAC role assignments, shared private link create + approve, the project connection, and — critically — the negative isolation tests. ARM has its own public control endpoint, so these run fine from anywhere.
• In-VNet jumpbox (data plane): anything that hits the service data plane directly — create index / knowledge sources / knowledge base, run retrieve, and the agent-over-MCP calls. These only work from inside the VNet.

Keep this split in mind for every cell below: the cell header notes whether it runs off-VNet (ARM) or on the jumpbox (data plane).

Acceptance criteria summary (verified results)

Prerequisites checklist

• Azure subscription with Owner or Contributor and User Access Administrator (you assign roles).
• Azure CLI az >= 2.60 with the Search extension: az extension add --name search.
• Resource providers registered (next cell): KeyVault, CognitiveServices, Storage, MachineLearningServices, Search, Network, App, DocumentDB.
• Quota in West US 3 for: Azure AI Search (Standard), Cosmos DB, the Azure OpenAI deployments (text-embedding-3-large, gpt-4.1-mini), and VM cores (Standard_D2s_v5).
• A tenant policy that allows private endpoints (some orgs deny them by Azure Policy — clear this with your platform team first).
• Azure Bastion permitted in the VNet (you'll reach the no-public-IP jumpbox through it for the portal walkthrough in AC9).

Step 1 — Provision the private foundation with the official Bicep

Don't hand-roll the network. Use the official Microsoft foundry-samples "Network Secured Standard Agent Setup" (sample 15-network-secured-agent). In one deployment it creates:

• The Foundry account + project, AI Search, Storage, and Cosmos DB.
• Private endpoints + private DNS zones for every service.
• The VNet with pe-subnet (private endpoints) and agent-subnet (delegated to the agent runtime).
• The BYO connections (Search / Storage / Cosmos) and the capability host that makes the project an isolated agent host.

Source (verified): https://github.com/azure-ai-foundry/foundry-samples/tree/main/samples/microsoft/infrastructure-setup/15-network-secured-agent

It wires 6 private DNS zones — confirm all six exist after deployment:

privatelink.services.ai.azure.com
privatelink.openai.azure.com
privatelink.cognitiveservices.azure.com
privatelink.search.windows.net
privatelink.blob.core.windows.net
privatelink.documents.azure.com

📸 Screenshot placeholder: media/network-isolated-foundry-iq/01-bicep-deployment-succeeded.png — Resource group deployment "Succeeded" in the portal.

⚠️ Field note (the single most common stumbling block). Standard Agent VNet injection takes ~45–60 minutes. The account capability host sub-deployment frequently reports InternalServerError in the ARM long-running operation even though the resource actually succeeded. Do not assume failure. Verify the real provisioning state, and if the project capability host is missing, (re)create it directly with an idempotent PUT (next cell).

Verified output — the project capability host reaches a terminal success state:

caphostproj   provisioningState: Succeeded

Step 2 — Lock down inbound, then prove it (AC1)

The first acceptance criterion is the most fundamental: the AI Search service must reject all inbound traffic from the public internet. Two conditions must hold:

1. publicNetworkAccess = Disabled on the search service.
2. The inbound private endpoint (groupId searchService) is in state Approved.

The next cell reads both directly from ARM.

Verified output (quote exactly):

{ "publicNetworkAccess": "Disabled", "semantic": "free", "sku": "standard", "status": "running" }

[ { "group": "searchService",
    "name": "foundryiqlltusearch-private-endpoint.f922aa8f-65ad-42ff-9057-cfa25b020375",
    "status": "Approved" } ]

✅ AC1 PASSED

Inbound public access is OFF (publicNetworkAccess: Disabled) and the inbound private endpoint is Approved. The service can only be reached from inside the VNet.

Step 3 — Outbound only over shared private links, then prove it (AC3)

Foundry IQ has to reach out to two services to do its job: Blob storage (to index the policy documents) and the Foundry/OpenAI account (for embeddings and answer synthesis). With public access disabled everywhere, those outbound calls must travel over shared private links (SPLs) — never the public internet. Two SPLs are required, and each must be approved on the target resource:

• blob → the storage account
• openai_account → the Foundry account

⚠️ Field note (real gotcha). az search shared-private-link-resource create uses an older API that rejects openai_account with: "Supported types are: blob, table, dfs, file, Sql, sqlServer, vault." Create the AOAI SPL with az rest against api-version=2025-05-01 instead. The blob SPL works fine through the CLI.

Verified output — both shared private links approved:

[ {"groupId":"blob","name":"spl-blob","provisioningState":"Succeeded","status":"Approved"},
  {"groupId":"openai_account","name":"spl-aoai","provisioningState":"Succeeded","status":"Approved"} ]

And the blob indexer that later ran over that private path (captured during the data-plane build in Step 6):

{ "name": "grid-policy-ks-indexer",
  "lastResult": { "status": "success", "itemsProcessed": 3, "itemsFailed": 0,
                  "mode": "indexingAllDocs", "errors": [], "warnings": [] } }

✅ AC3 PASSED

Outbound traffic runs only over approved private links; the blob indexer processed 3 documents with 0 errors without ever touching the public internet.

📸 Screenshot placeholder: media/network-isolated-foundry-iq/02-shared-private-link-approved.png — Shared private link connections "Approved" on the storage and Foundry accounts.

Step 4 — Least-privilege RBAC, no keys anywhere (AC4)

Keys are disabled across the stack; every component authenticates with a managed identity and the minimum roles it needs:

• Search MI reads the blob container and calls the Foundry/OpenAI account.
• Project MI reads/writes Search, Storage, and Cosmos — including the Cosmos SQL data-plane role, which is easy to miss.
• Jumpbox MI lets the admin run the data-plane scripts (Steps 6–7) without any keys.

⚠️ Field note (real gotcha). When the capability-host deployment is cancelled or errors mid-flight, the Cosmos SQL data-plane role assignment is silently skipped. The agent then fails later with a Cosmos 403 (readMetadata). Assign the built-in Cosmos DB Built-in Data Contributor (...0002) explicitly — see the last command below.

Verified RBAC matrix:

✅ AC4 PASSED

Least-privilege assignments are present for all three managed identities (including the easily-missed Cosmos SQL data-plane role). No API keys are used anywhere.

Step 5 — The jumpbox is your data-plane workstation, then prove DNS (AC2)

The jumpbox VM has no public IP and no inbound ports open. Per Azure best practice, the recommended way for a human admin to reach it is Azure Bastion — browser-based RDP/SSH with no public IP and nothing exposed to the internet — or a site-to-site VPN / ExpressRoute from your corporate network. From that in-VNet session you run every data-plane step in Steps 6–7 against the private endpoints, using the VM's system-assigned managed identity — no keys anywhere.

💡 Why a jumpbox at all, and why Bastion? Once Search has publicNetworkAccess=Disabled, some host inside the VNet must issue the data-plane calls (create KB/KS, retrieve, build the agent). A Bastion-reached jumpbox is the standard, auditable answer and the recommended developer experience. In this notebook the scripts are instead delivered unattended via az vm run-command invoke purely so the walkthrough is fully reproducible end-to-end — that's an automation convenience, not the interactive DX we recommend. For day-to-day work: connect over Bastion and run these same scripts in a terminal on the box.

Before building anything, prove the routing: every service FQDN must resolve to a private 10.42.1.x address (via the private DNS zones) and accept TCP 443.

Verified output (from the jumpbox):

foundryiqlltusearch.search.windows.net    -> 10.42.1.10
foundryiqlltu.openai.azure.com            -> 10.42.1.6
foundryiqlltu.cognitiveservices.azure.com -> 10.42.1.5
foundryiqlltust.blob.core.windows.net     -> 10.42.1.4
foundryiqlltucosmosdb.documents.azure.com -> 10.42.1.8
TCP 443: search OPEN, openai OPEN, blob OPEN

✅ AC2 PASSED

Every endpoint resolves to a private 10.42.1.x address via the private DNS zones, and 443 is reachable. The data plane lives inside the VNet.

Step 6 — Build the Knowledge Base over the private data plane (AC5 / AC6)

Now the data plane. From the jumpbox (managed identity, no keys) we:

1. Upload the 3 NERC/grid policy docs to the private blob container.
2. Build a Blob (Indexed) knowledge source — Foundry IQ auto-creates the indexer pipeline and pulls the docs over the blob shared private link.
3. Build a Search Index knowledge source for the control-room operating procedures.
4. Compose a unified Knowledge Base (outputMode=answerSynthesis, retrievalReasoningEffort=medium, gpt-4.1-mini).

⚠️ Field notes (hard-won).

• Blob KS extraction: use contentExtractionMode: "minimal" — standard requires a Content Understanding resource and its own shared private link. With disableImageVerbalization: true you must omit chatCompletionModel and keep only embeddingModel.
• MI auth (no keys): use connectionString: "ResourceId=<storageRID>;".
• KB sources: list knowledgeSources: [{name: ...}] only — do not add includeReferenceSourceData (invalid here).
• Accept HTTP 200 / 201 / 204 on PUT updates.

Auth scopes used by the data-plane scripts: https://search.azure.com/.default (Search) and https://cognitiveservices.azure.com/.default (Foundry/OpenAI). Run them on the jumpbox with ManagedIdentityCredential.

✅ AC5 PASSED

The index, the grid-policy-ks (blob) knowledge source, the control-room-ks (search index) knowledge source, and the unified contoso-grid-kb Knowledge Base were all created over the private data plane from the jumpbox.

Verified Q&A (real retrieve outputs, grounded + cited):

Q: How often must a personnel risk assessment be reviewed, and what happens to access when someone is terminated?

A: "According to Contoso Grid policies, a Personnel Risk Assessment (PRA) must be reviewed at least once every 15 calendar months [ref_id:0]. When someone is terminated, their electronic access to BES Cyber Systems must be revoked within 24 hours of the termination [ref_id:0]." — 1 reference → nerc-cip-access-control-policy.md (source grid-policy-ks)

Q: What does the operator do when frequency drops below 59.95 Hz?

A: "When the grid frequency drops below 59.95 Hz, the control room operator immediately initiates Load Shed Block A, which sheds approximately 150 MW of interruptible industrial load. If the frequency continues to fall below 59.90 Hz within 30 seconds, Load Shed Block B is armed automatically. All load shed actions must be logged in the operations journal and reported to the Regional Transmission Operator within 15 minutes [ref_id:0]." — 2 references (source control-room-ks)

The activity trace proves the full agentic pipeline ran for each answer:

modelQueryPlanning → azureBlob / searchIndex (knowledge source queries) → agenticReasoning (medium) → modelAnswerSynthesis

✅ AC6 PASSED

Answers are grounded with ≥1 citation and carry a complete agentic activity trace — over the private data plane.

Step 7 — Connect a Foundry Agent over MCP (AC7)

Foundry IQ exposes each Knowledge Base as an MCP endpoint. The canonical v2 pattern (see https://learn.microsoft.com/azure/foundry/agents/how-to/foundry-iq-connect) is:

1. Create a RemoteTool project connection that authenticates with ProjectManagedIdentity and targets the KB MCP endpoint, with audience = https://search.azure.com/.
2. Create an agent and attach an MCPTool with allowed_tools=["knowledge_base_retrieve"], pointing at the connection.

ℹ️ Field note. This RemoteTool/connection pattern works for CognitiveServices (Foundry) projects too — not just hub-based projects. The MCP endpoint is {search}/knowledgebases/{kb}/mcp?api-version=2025-11-01-preview.

Verified RemoteTool connection (redacted):

{ "name": "contoso-grid-kb-mcp",
  "properties": { "authType": "ProjectManagedIdentity", "category": "RemoteTool",
    "audience": "https://search.azure.com/",
    "target": "https://foundryiqlltusearch.search.windows.net/knowledgebases/contoso-grid-kb/mcp?api-version=2025-11-01-preview",
    "metadata": {"ApiType": "Azure"} } }

Agent answer (real):

"A terminated employee's access to BES cyber systems must be revoked immediately upon termination to ensure compliance with cybersecurity policies and prevent unauthorized access. The black-start priority 1 substation is SS-12 (Riverside), which supplies power to the downtown medical district. This substation is critical and any SEV-1 incident affecting it triggers automatic escalation to the Regional Transmission Operator 【28:0†source】."

⚠️ Field notes (real). The agent first failed with a Cosmos 403 (missing the SQL data-plane role — see Step 4) and once with a transient 429 (resolved by raising gpt-4.1-mini to 100K TPM). After both fixes it returned the grounded, cited answer above.

✅ AC7 PASSED

The Foundry Agent answered over the Knowledge Base via MCP, grounded and cited.

Step 8 — Prove isolation from OFF the VNet (AC8)

This is the auditor's money shot. Run the same data-plane calls from the admin's laptop (off-VNet), with a valid Entra token. They must fail with 403. The identity and the token are valid — only the network path is different — so the failure isolates the network as the sole control. Run negative_isolation_test.py from your workstation (not the jumpbox).

Verified output (quote exactly):

[ISOLATED] Search data plane (list indexes): public-resolved-ip=4.227.75.183 status=403
   :: "Request is denied as the source is not allowed... 'publicNetworkAccess: Disabled'."
[ISOLATED] Search data plane (list KBs):     status=403  (same)
[ISOLATED] KB retrieve endpoint:             status=403  (same)
AC8 PASSED — service is unreachable from off-VNet

Same identity, same token — only the network path differs:

✅ AC8 PASSED

The data plane is genuinely private. Public callers get 403, not data.

Step 9 — Portal UX over Bastion (ai.azure.com) — AC9 walkthrough

ai.azure.com data-plane operations also traverse the private path, so the portal build must be done from inside the VNet — i.e., a browser running on the jumpbox, reached through Azure Bastion. These steps are the portal equivalent of AC5–AC7; capture redacted screenshots during your own run.

1. Connect to foundry-jump via Azure Bastion (RDP/SSH); open a browser to https://ai.azure.com from inside the VNet.
   • 📸 media/network-isolated-foundry-iq/03-bastion-session.png
2. Open the project → Knowledge → + Knowledge source → pick Azure Blob (Indexed), point at the private storage, choose text-embedding-3-large.
   • 📸 media/network-isolated-foundry-iq/04-create-knowledge-source.png
3. + Knowledge base → add both sources → set answer synthesis + gpt-4.1-mini.
   • 📸 media/network-isolated-foundry-iq/05-create-knowledge-base.png
4. Agents → new agent → add the Knowledge base (MCP) tool → select contoso-grid-kb.
   • 📸 media/network-isolated-foundry-iq/06-agent-add-kb-mcp-tool.png
5. Playground → ask "Which substation is black-start priority 1?" → confirm a grounded answer with a citation.
   • 📸 media/network-isolated-foundry-iq/07-agent-playground-grounded-answer.png

📋 AC9 — walkthrough

These steps are the portal equivalent of AC5–AC7. The image references above are placeholders — replace them with your own redacted captures taken during the Bastion session.

Troubleshooting — the real issues we hit

Cleanup

Once the audit evidence is captured, tear everything down to stop billing:

az group delete -n rg-foundryiq-isolated-wus3 --yes --no-wait

Appendix A — The easier alternative: Managed VNet

If you do not need to operate your own VNet, Managed VNet is the lower-friction recommended path. It "streamlines and automates network isolation for your Foundry resource by provisioning a Microsoft-managed virtual network that secures the Agents service underlying compute" — you get a secure default without building or maintaining a VNet, subnets, DNS zones, or a jumpbox-as-agent-host. Managed private endpoints are abstracted away: they create no customer-visible NICs in your subscription.

The CLI below is reproduced from Microsoft Learn and the official foundry-samples (sample 18). Unlike Steps 1–9 of this guide, it was not executed against our Contoso Grid deployment — treat it as the documented happy-path for the Managed VNet model.

Outbound isolation modes

⚠️ The mode is permanent. Once you set Allow Internet Outbound or Allow Only Approved Outbound you cannot change it, you cannot disable Managed VNet after enabling it, and there is no upgrade path from BYO VNet → Managed VNet — a Foundry resource redeployment is required. There is no Azure portal create UI yet (CLI / az rest / Bicep / Terraform only). You can't bring your own firewall, and each account gets (and pays for) its own managed firewall in Approved-Outbound mode.

Deploy (Azure CLI / az rest, from Microsoft Learn)

# 1) Create the AIServices account WITH the managed-network injection. networkInjections,
#    customSubDomainName, and allowProjectManagement must be set AT CREATION TIME.
az rest --method PUT \
  --url "https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<rg>/providers/Microsoft.CognitiveServices/accounts/<account>?api-version=2026-03-01" \
  --body '{
    "location": "<region>", "kind": "AIServices", "sku": {"name": "S0"},
    "identity": {"type": "SystemAssigned"},
    "properties": {
      "allowProjectManagement": true,
      "customSubDomainName": "<account>",
      "networkInjections": [{"scenario": "agent", "subnetArmId": "", "useMicrosoftManagedNetwork": true}],
      "disableLocalAuth": false
    }
  }' --headers "Content-Type=application/json"

# 2) Grant the account's managed identity the role that auto-approves managed PEs:
#    Azure AI Enterprise Network Connection Approver (b556d68e-0be0-4f35-a333-ad7ee1ce17ea)
PRINCIPAL=$(az cognitiveservices account show -g <rg> -n <account> --query identity.principalId -o tsv)
az role assignment create --assignee-object-id $PRINCIPAL --assignee-principal-type ServicePrincipal \
  --role b556d68e-0be0-4f35-a333-ad7ee1ce17ea --scope /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<rg>

# 3) Create the managed network in the MOST SECURE mode (managed firewall enforces approved egress):
az cognitiveservices account managed-network create -g <rg> -n <account> \
  --managed-network allow_only_approved_outbound --firewall-sku Standard

Or deploy the official Bicep / Terraform sample (≈30 min): foundry-samples → 18-managed-virtual-network.

What still applies from this guide

Managed VNet replaces Step 1 + Step 5 (you no longer build the VNet or the jumpbox-as-agent-host). Everything about Foundry IQ is unchanged: you still disable public access on Azure AI Search, add the inbound private endpoint (AC1), create the shared private links to Blob + the Foundry account (AC3), assign least-privilege RBAC (AC4), and reach an in-VNet host over Bastion to build and query the Knowledge Base (AC2, AC5–AC7). The off-VNet 403 proof (AC8) and portal walkthrough (AC9) apply as-is.

🧭 On-prem access: with Managed VNet, private access to on-premises resources is supported via Azure Application Gateway (L4 + L7, GA) rather than direct VNet peering.

📚 Docs: Configure managed virtual network for Microsoft Foundry

Appendix B — Reference tables and links

Verified API versions

Reference links (Microsoft Learn)

• Connect Foundry IQ to an agent (MCP)
• Agentic retrieval overview
• Create a knowledge base
• Knowledge sources overview
• Knowledge source: Azure Blob
• Azure AI Search private endpoints
• Managed identities in Azure AI Search
• Connect through a firewall / network security
• foundry-samples — sample 15: network-secured-agent
• foundry-samples — sample 18: managed-virtual-network
• Set up private networking for Foundry Agent Service
• Deep dive into Foundry Agent Service networking
• Configure managed virtual network\n- Add a search service to a network security perimeter\n- Add Microsoft Foundry to a network security perimeter\n- Network security perimeter concepts

Acceptance criteria summary

Appendix C — Turning the trusted-service bypass OFF (shared private link vs. NSP)

Some regulated customers (utilities, FSI, defense) prohibit the Foundry account's trusted-service bypass — networkAcls.bypass = AzureServices, the "Allow Azure services on the trusted services list to access this resource" checkbox. They're right to: with the bypass on, the resource is reachable from any Azure VM that presents valid credentials, so stolen creds from anywhere in Azure defeat the isolation. The goal is to run with bypass = None (box unchecked) and still have the agent reach the Knowledge Base.

✅ The headline (validated, sometimes surprising): with the shared private link from the main guide (Step 3, Search → Foundry account, group openai_account) already in place, you can set bypass = None and the agent KB retrieve keeps working — no NSP required. The Search→Foundry hop (query planning + answer synthesis) rides the private endpoint, which is bypass-independent. So for the architecture in this cookbook, the trusted-service bypass was effectively redundant, and disabling it is essentially free.

A Network Security Perimeter (NSP) is the defense-in-depth layer on top — a logged, deny-by-default boundary. It is not what makes the bypass-free hop work (the private endpoint is), and you only need it in specific cases. This appendix shows both, with the verified evidence.

📚 Add a search service to an NSP · Add Microsoft Foundry to an NSP · both Azure AI Search (Microsoft.Search/searchServices) and the Foundry account (Microsoft.CognitiveServices/accounts, kind AIServices) support NSP. Everything below was executed against rg-foundryiq-isolated-wus3 and reverted.

Option 1 (recommended) — just turn the bypass off

If you followed Step 3 (the openai_account shared private link is approved), this is the whole change — one PATCH, no new resources:

# Turn the trusted-service bypass OFF on the Foundry account (keep PNA Disabled)
az rest --method patch \
  --url "https://management.azure.com<FOUNDRY_ARM_ID>?api-version=2025-06-01" \
  --headers "Content-Type=application/json" \
  --body '{"properties":{"networkAcls":{"bypass":"None","defaultAction":"Deny","ipRules":[],"virtualNetworkRules":[]}}}'

Then re-run the Step 6 retrieve and the Step 7 agent — both still return grounded, cited answers.

Option 2 — add an NSP for defense-in-depth

Use this when you want a logged, deny-by-default perimeter around both resources, your auditor requires an explicit network trust boundary, or you do not have a private path between Search and Foundry (no openai_account SPL) and still need the bypass off. Put both resources in the same perimeter; same-perimeter + managed-identity gives implicit intra-perimeter trust.

az extension add --name nsp --upgrade

az network perimeter create  --name nsp-foundryiq -g <rg> -l <region>
az network perimeter profile create --name nsp-profile --perimeter-name nsp-foundryiq -g <rg>

# Associate BOTH resources to the same profile — in ENFORCED mode (see the gotcha below)
az network perimeter association create --name assoc-search  --perimeter-name nsp-foundryiq -g <rg> \
  --access-mode Enforced --private-link-resource "{id:<SEARCH_ARM_ID>}"  --profile "{id:<PROFILE_ARM_ID>}"
az network perimeter association create --name assoc-foundry --perimeter-name nsp-foundryiq -g <rg> \
  --access-mode Enforced --private-link-resource "{id:<FOUNDRY_ARM_ID>}" --profile "{id:<PROFILE_ARM_ID>}"

flowchart LR
  subgraph NSP["Network Security Perimeter (ENFORCED) — defense-in-depth"]
    Foundry["Foundry account (AIServices)<br/>PNA=Disabled · bypass=None"]
    Search["Azure AI Search<br/>PNA=Disabled · KB"]
  end
  Agent["Foundry Agent (MCP knowledge_base_retrieve)<br/>auth: ProjectManagedIdentity"]
  Agent -->|"agent → KB retrieve (over private endpoint) ✅"| Search
  Search -->|"query planning + answer synthesis → Foundry (private endpoint / intra-perimeter) ✅"| Foundry
  Ext["Off-perimeter VM / laptop"] x--x|"403 deny-by-default ✅"| Search

Prereqs that still apply: managed identity + RBAC only (no keys), the Search KB already built, and an in-VNet host (Bastion) to issue the data-plane retrieve.

Verified results (executed, then reverted)

⛔ NSP gotcha — do not validate in Learning mode. The docs say "associate in Learning mode, check logs, then switch to Enforced." For agentic retrieval that does not work: associating both resources in Learning mode breaks the KB retrieve (server-side InternalServerError), and the implicit intra-perimeter trust only activates in Enforced. Associate directly in Enforced, or expect a transient outage. (Filed as a product bug; same query-time-read signature as Foundry File Search vector stores.)

🔎 Verify functionally, not via NSP logs. The agent→Search and Search→Foundry hops travel private endpoints / shared private links, so they don't appear in NSPAccessLogs — that table stays empty for these calls. Confirm success by running the retrieve (and the off-perimeter 403), not by reading perimeter logs.

Which should I use?

Bottom line: the shared private link is what makes bypass-free isolation work; NSP is additive governance, not a prerequisite. Add NSP when you want the perimeter's logging/deny-by-default guarantees or when there's no private path to make redundant — not because it's the only way to uncheck the box.