Network and data boundaries: what Standard setup actually buys you
Lesson 2 of 5 in Microsoft Foundry Agents in Practice: Identity, Boundaries, Guardrails, Traces, Bills.
Foundry Agent Service gives you three environment setups, and choosing between them is the most consequential decision in this module because one of them cannot be changed later.
Basic setup uses platform-managed resources — the fastest start, nothing of yours to provision. Standard setup with public networking and Standard setup with private networking both require bring-your-own Azure Storage, Azure AI Search and Azure Cosmos DB, so that all agent data — conversation history, uploaded files, vector stores — lands in resources in your own tenant. Standard setups also support customer-managed keys, and private network isolation (bring-your-own virtual network) is available with Standard setup only.
Read that as a sentence about custody, not features: Standard setup is how you answer the auditor’s question which subscription holds the conversation transcripts, and who holds the encryption keys.
| Setup | Where agent data lives | Network posture | Choose it when |
|---|---|---|---|
Basic | Platform-managed resources. | Public endpoints; no VNet injection. | Prototypes, internal tooling, anything where "Microsoft holds it" is an acceptable answer. Fastest path to a working agent. |
Standard, public networking | Your Azure Storage, Azure AI Search and Cosmos DB — conversation history, files and vector stores in your subscription. Customer-managed keys supported. | Still reachable over public endpoints, with Azure’s normal auth in front. | You need data custody and your own keys, but not full network isolation — the common enterprise middle. |
Standard, private networking | Same bring-your-own resources, reached through private endpoints with Private DNS zones. | A dedicated subnet delegated to | Regulated workloads where "no public network path" is a written requirement. Costs you setup time and some tool compatibility. |
The bring-your-own resources are worth understanding individually, because each one holds a different slice of your agent’s memory — and because one of them has a hard floor that surprises people on their first deployment.
A related distinction the docs are careful about, and teams routinely blur: sessions are not conversations. A hosted agent’s session is compute plus a persistent filesystem ($HOME and /files) that the platform provisions and deprovisions. A conversation is the durable server-side history of items — messages, tool calls, tool outputs — and in a Standard setup that history is sitting in your Cosmos DB. Retention, backup, legal hold and deletion requests attach to the conversation store, not to the sandbox.
Azure Storage — files and blobs
Holds the file content your agents upload and produce. In a Standard setup it is your storage account, which means your lifecycle rules, your diagnostic logs, your firewall and your keys.
Practical consequence: file retention becomes a storage-account policy question your data team already knows how to answer, rather than a platform behaviour you have to look up.
Azure AI Search — vector stores
Backs file search and the vector indexes behind retrieval. Bringing your own means the embedded chunks of your documents live in an index you can inspect, re-key and delete.
It also means index capacity and cost are yours to size. A RAG corpus that grows without a retention policy grows in your bill and in your breach surface at the same time.
Azure Cosmos DB for NoSQL — conversation state (mind the RU floor)
Holds conversation history. The documented requirement: the account needs a total throughput limit of at least 3000 RU/s, because Foundry provisions three containers requiring 1000 RU/s each. Both provisioned throughput and serverless are supported.
This is the number that breaks first deployments — a tidy 400 RU/s account fails setup rather than degrading. Treat 3000 RU/s as the entry ticket and check the current Use your own resources page before sizing anything larger.
Customer-managed keys — whose key encrypts it
Standard setups support CMK. The compliance value is specific and worth stating precisely: it moves the encryption key into a vault you control, so key rotation and key revocation become actions you can take unilaterally.
What it does not do is change who processes the data or which regions the model runs in. Encryption custody and data residency are different questions with different answers.
The Microsoft 365 publishing hole
If you publish an agent to Microsoft 365 Copilot and Teams, note that portal publishing is unsupported for projects that disable public network access. Such agents publish via REST with enable_m365_public_endpoint, which opens a scoped, source-IP-filtered public route for the Activity Protocol endpoint only — because Microsoft 365 cannot reach private endpoints. Requests from allowed Microsoft service IP ranges must still pass Bot Service or Entra authentication, and management APIs stay private.
Say that out loud before an architecture review, because "we are fully private" and "we publish to Teams" are in tension. The honest description is: one narrow, authenticated, IP-filtered ingress for the chat channel, and nothing else.
Tool: Cloud Deployment Wizard — Walk a workload through setup tiers, data custody and network isolation — and see where the one-way doors are — in the Deployment Wizard.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.