Best practices for multi-project isolation on shared Microsoft Foundry platform (BYO Storage, Cosmos DB, AI Search) — how are enterprises handling this?

Hey @Shibily Abdul Shukoor , I cannot comment on roadmap or future developments from Microsoft but given my experience, I can guide on your questions from standard practices we follow and according to Microsoft's guidance.

For this type of enterprise Foundry rollout, I would separate cost-sharing from security isolation.

A shared Foundry Account with shared BYO Storage, Cosmos DB, and Azure AI Search can work for PREPROD, sandbox, and projects that sit inside the same trust boundary. It should not be treated as a hard isolation boundary for regulated production workloads.

For production workloads that need independent security and operational boundaries, use a dedicated Foundry resource and dedicated Cosmos DB, Azure AI Search, and Storage dependencies for the workload or defined security boundary. Sharing should be a documented exception for workloads that intentionally share the same identity, administrators, network policy, capacity, recovery objectives, and incident blast radius.

1. Are shared BYO resources across Foundry projects a supported pattern?

Yes, shared BYO resources can be used, but they should be used carefully.

For PREPROD, a shared Foundry Account with shared BYO resources is a reasonable cost-optimization pattern if the projects are part of the same trust boundary. Use separate project managed identities, scoped RBAC, naming conventions, diagnostics, monitoring, and written risk acceptance.

For PROD, shared BYO resources should not be the default for unrelated regulated workloads. Even when data-plane access is restricted, shared backing services still create metadata visibility, shared administration, shared capacity, shared backup/restore, shared failover, and shared incident-response concerns.

The better production pattern is to create dedicated BYO resource sets per workload, business unit, data-classification zone, or other clearly defined security boundary.

2. Is the right model one Foundry Account and one BYO set per project?

Not always.

The right model depends on the isolation requirement:

• If projects are low-risk, internal, and in the same trust boundary, one Foundry Account with shared BYO resources can be acceptable.
• If projects belong to different business units, data classifications, regulatory scopes, recovery objectives, or operational ownership models, use dedicated BYO resources.
• If users must not even see other projects, connections, knowledge bases, or account-level objects, use separate Foundry Accounts as well.

A practical enterprise model is:

• PREPROD: one shared Foundry Account and shared BYO resources, only for projects inside the same trust boundary.
• PROD, normal regulated workloads: shared Foundry Account only if project visibility is acceptable, with dedicated BYO resources per workload or security boundary.
• PROD, high-sensitivity workloads: dedicated Foundry Account and dedicated BYO resources per business unit, legal entity, or regulated workload.

A Foundry project is not always the right isolation-cell size. The better boundary is the workload or group of projects that intentionally share identity, administrators, network policy, capacity, recovery objectives, and incident blast radius.

3. Cosmos DB readMetadata: is dedicated Cosmos DB per project the only clean solution?

For strict Azure resource-level and operational isolation, use a dedicated Cosmos DB account per security boundary.

A shared Cosmos DB account can still provide project-level data-access isolation through project-specific containers and scoped permissions. That can protect the actual thread, message, and entity data stored in project-specific containers.

However, shared Cosmos DB does not provide clean independent boundaries for metadata confidentiality, account administration, throughput and capacity, backup and restore, failover, monitoring, or incident blast radius.

The reported account-root readMetadata behavior should be validated against the exact deployed role definitions and API calls. If testing confirms that one project identity can enumerate container names or database structures belonging to other projects, there is no clean documented mechanism to hide those names inside the same Cosmos DB account. In that case, separate Cosmos DB accounts are required for metadata confidentiality.

For PREPROD, this may be acceptable if the risk is documented.

For PROD, use dedicated Cosmos DB accounts per workload or security boundary when any of the following matter:

• Container/database names should not be visible across projects.
• Backup and restore must be independent.
• RU/s consumption must be isolated.
• Failover and disaster recovery must be isolated.
• Incident blast radius must be contained.
• Audit and compliance evidence must be clean.

4. How should per-project AI Search isolation be handled?

Azure AI Search now supports per-index scope for Search Index Data Reader and Search Index Data Contributor. This can restrict direct document and query operations against a specific index.

However, this does not provide full service or search-object isolation.

Search Service Contributor remains a service-level object-management role. It can manage search objects at the service level, and where Foundry Standard Agent Setup requires the project managed identity to have Search Service Contributor and Search Index Data Contributor on the Search service, separate Foundry projects using one shared Search service should not be considered strongly isolated at the search-object management layer.

This distinction matters because:

• Human users should not receive Search Service Contributor unless they are platform administrators.
• Project managed identities may still need broader Search permissions because of the current Standard Agent Setup requirements.
• Therefore, a shared Search service can be acceptable for PREPROD or same-trust workloads, but not for strong isolation between regulated projects.

For PREPROD, the shared Search pattern can work if the controls are strict:

• Do not grant Search Service Contributor to ordinary project users.
• Recognize that project managed identities may still have service-wide Search object-management permissions.
• Disable API-key authentication where all required Foundry, deployment, and operational workflows support Microsoft Entra authentication.
• Otherwise, tightly restrict and monitor key access.
• Restrict Search administration roles to the platform team.
• Enforce index naming, tagging, logging, and monitoring.
• Apply document-level or query-time access filtering where content permissions matter.

For PROD, use dedicated Azure AI Search services per workload or security boundary where index names, knowledge bases, vectors, retrieval configuration, or indexed content are sensitive.

5. Foundry IQ knowledge bases: how should cross-project visibility be handled?

Do not rely on shared Azure AI Search for strict Foundry IQ knowledge-base isolation.

Foundry IQ uses Azure AI Search knowledge bases and associated search objects. If multiple Foundry projects use the same Search service, knowledge-base visibility and search-object management can be difficult to separate cleanly.

There are two different isolation concerns:

• Content authorization: whether a user can retrieve unauthorized documents.
• Object visibility: whether a user can see that another project’s knowledge base, index, or related search object exists.

Document-level access control and permission-aware retrieval can help with content authorization. They do not fully solve the object-visibility concern.

There is no project-scoped RBAC boundary for Azure AI Search knowledge-base object management that should be treated as a hard confidentiality control across Foundry projects sharing the same Search service.

For PREPROD, shared Search with strict naming, RBAC, and monitoring can be acceptable.

For PROD, use dedicated Azure AI Search per workload or security boundary when knowledge-base discoverability matters.

6. About roadmap items

Do not base the architecture on future roadmap assumptions.

Design the platform using the controls available today:

• Treat enterprise_memory as platform-defined.
• Treat Foundry IQ KB isolation as dependent on the Search service boundary.
• Treat Azure AI Search index-scoped data roles as useful for data-plane access, but not equivalent to full service isolation.
• Treat Search Service Contributor as a service-level object-management role.
• Treat Foundry Account scope as a real administrative and visibility boundary.
• Treat shared BYO resources as shared operational blast-radius domains.

If stronger KB-level RBAC, configurable Cosmos database naming, stronger project-scoped account behavior, or stronger Search object isolation becomes available later, the architecture can be simplified later. For now, production isolation should be designed around Azure resource boundaries, not roadmap expectations.

7. Foundry Account role inheritance: what should be done?

Apply separate permission models to human users and the project managed identity.

Human developers should normally receive project-scoped Foundry roles and only the minimum parent-resource visibility required. Project administrators should receive management roles only for the projects they own. Runtime callers should receive the narrowest agent or project-level consumer role that works.

The project managed identity is different. It must receive the supporting-resource permissions required by Standard Agent Setup, and some of those permissions are broader than project scope. That means the main isolation exposure may come from the managed identity and supporting-resource permissions, not only from human user permissions.

Use this pattern:

• Platform administrators get account/resource-scope administrative roles.
• Project leads get Foundry Project Manager on the Foundry resource.
• Developers get project-scope Foundry User access where possible.
• Agent callers get the narrowest agent or project-level consumer role that works.
• The project managed identity gets the required Standard Agent Setup permissions on Storage, Cosmos DB, and Azure AI Search.
• Platform automation identities are managed separately and reviewed regularly.

Do not assign Foundry User at the parent Foundry resource merely as a blanket fix for portal, upload, or connection failures. Identify the specific operation and required action, then assign the role at the narrowest supported scope.

If a required capability genuinely cannot operate without inherited parent-resource access, and that inherited access exposes other projects, then the Foundry Account boundary is too broad. In that case, split the Foundry Account by business unit, regulated workload, or security boundary.

Deny assignments should not be the primary design pattern. They make the platform harder to operate and harder to troubleshoot. The cleaner solution is to align Foundry Account boundaries with real trust boundaries.

8. Is enterprise_memory configurable?

There is currently no documented supported option to override the enterprise_memory database name; therefore, design as though it is platform-defined.

If multiple projects share one Cosmos DB account, they also share the same platform-defined database structure and the same operational blast radius. Per-container RBAC can reduce data-access risk, but it does not give clean operational isolation.

For PREPROD, sharing may be acceptable.

For PROD, use dedicated Cosmos DB accounts per isolation boundary if backup/restore, throughput, failover, monitoring, incident response, or compliance separation matter.

9. What about shared BYO Storage?

Shared Storage should be treated the same way as shared Cosmos DB and shared Azure AI Search: it can work for PREPROD or same-trust workloads, but it is still one administrative and operational boundary.

Container-scoped Blob Data roles can protect blob contents, but a shared Storage account still creates shared concerns around:

• Account-level management permissions.
• Container enumeration.
• Network and firewall configuration.
• Private endpoints.
• Lifecycle policies.
• Diagnostics and logging.
• Deletion and recovery.
• Account-level compromise or misconfiguration.
• Offboarding and cleanup.
• Backup and restore ownership.

For PREPROD, shared Storage can be acceptable with clear controls and no regulated production data.

For PROD, use separate Storage accounts where metadata, networking, policy, monitoring, deletion, recovery, or administrative control must be independently governed.

10. Are there Microsoft templates or reference architectures for this?

You have already found the available resources by Microsoft relevant to your solution. I don't believe there are any more specific architectures available directly by Microsoft. Use those as building blocks, but do not treat them as a complete multi-project shared-BYO isolation blueprint.

The safest production format would be:

• Microsoft provides templates for deploying secure Foundry environments with BYO dependencies.
• Microsoft provides samples for standard setup, private networking, Terraform/Bicep deployment, and ACL-aware retrieval.
• For strict multi-project isolation, the architecture should still use dedicated Azure resource boundaries.

Recommended final architecture

For the environment described — regulated industry, private endpoints, CMK, single Entra tenant, Sweden Central, 3–5 PREPROD projects and 10+ PROD projects — I would use this model:

PREPROD

Use:

• One shared Foundry Account.
• Shared BYO Storage.
• Shared Cosmos DB.
• Shared Azure AI Search.
• Separate project managed identities.
• Cosmos DB permissions scoped as tightly as the deployed setup supports.
• Azure AI Search index-scoped data roles where useful for human or application access.
• No ordinary project-user Search Service Contributor.
• Recognition that project managed identities may require service-level Search permissions under Standard Agent Setup.
• Disable API-key authentication where all required workflows support Microsoft Entra authentication; otherwise, tightly restrict and monitor key access.
• No real regulated production data in PREPROD.
• Strong naming, tagging, diagnostics, and monitoring.
• Automated cross-project negative-access tests.
• Azure Activity Log and resource log alerts for unexpected index, container, or blob operations.
• Workload-level quotas and cost alerts.
• Documented recovery ownership.
• Documented deletion and offboarding procedures.
• Periodic role-assignment drift checks.
• Written risk acceptance for metadata visibility, service-wide managed identity permissions, and shared blast radius.

Shared PREPROD resources are acceptable only when all projects are within the same trust boundary and the organization explicitly accepts that shared Search project managed identities may have service-wide object-management capabilities.

PROD

Use:

• Dedicated Storage per workload or security boundary.
• Dedicated Cosmos DB per workload or security boundary.
• Dedicated Azure AI Search per workload or security boundary.
• Shared Foundry Account only when account-level visibility is acceptable.
• Dedicated Foundry Accounts where project visibility, connection visibility, role inheritance, or KB visibility must be isolated.

The isolation cell does not need to be one resource set for every small project. It should be one dedicated resource set per regulated workload, business/data-classification boundary, or group of projects that intentionally share identity, administrators, network policy, capacity, recovery objectives, and incident blast radius.