Turn compliance requirements into enforced boundaries

Learning objective

Map Zero Trust, tenancy, and data-minimization requirements to compliance controls.

Core idea

A compliance requirement becomes an architecture constraint when you identify the component that enforces it and the evidence that proves enforcement. “Keep tenants separate” must resolve into identity checks, retrieval filters, storage boundaries, and testable denied paths. “Minimize data” must change what crosses those paths and how long it remains.

Zero Trust provides three organizing principles: verify explicitly, use least-privileged access, and assume breach. Apply them at every agent-to-resource boundary. Being inside a project, virtual network, or agent team doesn’t establish authorization.

This lesson turns those principles into controls. It doesn’t claim that selecting a Microsoft service proves compliance with a particular law or contract. You must evaluate the complete application path, including external tools, model processing, stored history, and diagnostic data.

How it works

Verify callers and bound their authority

Use Microsoft Authentication Libraries (MSAL) for identity-platform authentication and token acquisition. Conditional Access authentication context and Continuous Access Evaluation (CAE) require applications to handle claims challenges. Use granular OAuth scopes and application roles for API authorization, including read-only permissions for read-only actions.

For Foundry tools, enforce resource-scoped permissions through the agent identity and the target’s permission system; see 1.2.3 for application-only versus delegated authority. To assume breach, test denied access to sibling tenants and unrelated resources as well as successful calls.

Match tenant isolation to the requirement

Azure Cosmos DB’s multitenant guidance distinguishes partition-key-per-tenant from database-account-per-tenant designs. A shared container with a key such as /TenantId provides logical isolation and shares throughput. It doesn’t supply physical isolation or independently configurable account-level features for every tenant.

Separate accounts provide a stronger resource boundary when each tenant needs independently tuned performance or customer-managed keys. Customer-managed keys are configured at the Cosmos DB account level, so a partition key can’t satisfy a per-tenant key requirement by itself.

Choose from the requirement rather than from a cost preference alone. A shared container can be appropriate when the application enforces authorized tenant access and shared performance is acceptable. A contractual need for independent account-level controls changes that decision even when shared storage would be cheaper.

The same distinction applies to knowledge retrieval. Azure AI Search’s security-filter pattern uses a field such as group_ids, marked filterable: true, and a query filter such as group_ids/any(g:search.in(g, 'AUTHORIZED_GROUP')). The value AUTHORIZED_GROUP represents a group derived by your trusted application, not text chosen by the model.

The documented pattern simulates document-level authorization with ordinary string filtering. It doesn’t authenticate those strings. Apply the filter to every query from a trusted boundary. Setting retrievable: false hides the group field in results but isn’t field-level security and doesn’t replace the query filter. Rejecting an answer after unauthorized documents enter model context is too late to enforce data access.

Separate storage location from processing location

Microsoft’s privacy documentation for Models sold by Azure distinguishes stateless model inference from optional stateful features. A model doesn’t retain prompts in its weights, but Responses history, uploaded files, and other configured features can persist content in service stores.

The same document distinguishes deployment processing boundaries. A Global deployment can process prompts and responses in any geography where the relevant model is deployed. DataZone deployments process within the specified data zone, such as the United States or European Union. Stored data remains in the designated geography even when processing has a broader boundary.

Therefore, a resource’s region alone doesn’t prove that every inference stays in that region. Select the deployment type that fits the required processing boundary, and record storage and processing separately. Don’t apply the Models sold by Azure privacy commitments to an external MCP server or every third-party model offering.

The documentation states that prompts, completions, embeddings, and training data aren’t used to train foundation models without permission or instruction. That commitment isn’t a zero-retention promise. The page describes stateful storage and abuse monitoring, with separate considerations for preview features.

Map regulatory evidence and retention to Purview

Microsoft Purview DSPM for AI (classic) provides Get guided assistance to AI regulations, using Compliance Manager control-mapping regulatory templates. Purview Audit captures prompts and responses in the unified audit log. Data Lifecycle Management retention policies retain or delete AI prompts and responses; select Enterprise AI apps and configure the required collection policy. Retention policies and holds can require keeping data beyond an application’s preferred deletion date.

Data Loss Prevention (DLP) supports blocking prompts based on sensitive information types for a scoped Entra-registered AI app that integrates with Purview APIs. Purview data security policies apply only to calls using an Entra user-context token or explicitly including user context. Other authentication scenarios provide audit and classified interaction visibility rather than that policy enforcement. Managing Foundry interaction policies requires pay-as-you-go billing; Audit includes Foundry data through the Purview license.

Minimize collection and retention explicitly

Use an application-owned input contract to send only fields necessary for the tool’s task. For a claim classifier, a claim category and approved excerpt might be sufficient; a complete customer record isn’t automatically justified. The application must enforce that projection before the tool call. Natural-language instructions can guide generation but don’t provide a field-level access barrier.

Foundry Memory offers preview controls for persistent personalization, including store-level default time to live (TTL) and item-level create, read, update, and delete operations. See 1.2.5 for the configuration identifiers and scope behavior. Retention for extracted entries is separate from retention of original conversations.

Remove secrets before memory extraction, and plan deletion across application-owned summaries and retrieval artifacts. Conversation deletion alone leaves those derived copies to manage.

For stricter ownership and networking requirements, Foundry’s bring-your-own-resources option connects Azure Storage, Azure Cosmos DB, and Azure AI Search. Microsoft’s networking guidance warns that private endpoints for those services aren’t created automatically with the Foundry resource. Configure each required endpoint; making the Foundry endpoint private doesn’t make every connected resource private.

Memory stores don’t support VNet integration. That constraint can rule out managed Memory for a workload requiring end-to-end private networking, even if other components satisfy the requirement.

Key distinctions and trade-offs

Use separate evidence for each boundary:

Logical sharing reduces cost and administration but raises the importance of trusted routing and filtering. Resource separation increases operational work while enabling account-level controls. No single identity, networking, or retention setting substitutes for the others.

Architecture / decision scenario

A legal-support agent serves several enterprise tenants. One tenant requires its own encryption key and independent storage control; place its application-owned case state in a separate Cosmos DB account. For tenants that permit logical sharing, use the partition-key model and derive /TenantId from authenticated application context.

A trusted retrieval service applies the Search security filter on every query before documents enter model context. Entra authentication establishes the caller, granular API permissions bound the operation, and the agent identity has only the resources needed for its role. The team tests a tenant attempting to reach another tenant’s state and documents.

The contract also restricts inference geography. Choose the model deployment type accordingly rather than relying on the resource’s storage location. Project only necessary excerpts into model and tool requests. Map regulatory evidence through DSPM for AI (classic) and Compliance Manager. Configure Purview Audit and Enterprise AI apps retention alongside store retention, and verify derived-copy deletion. Supply user context for Purview policy enforcement and enable pay-as-you-go billing for policy management.

If end-to-end private networking is mandatory, configure private endpoints for the connected resources and exclude Foundry Memory because its documented VNet limitation conflicts with that requirement. Each compliance decision now has a named mechanism and an observable failure case.

Common exam traps

• Treating authentication as authorization to every tenant’s data.
• Treating /TenantId as physical isolation or a per-tenant encryption-key boundary.
• Trusting model-supplied group IDs in a Search security filter.
• Assuming retrievable: false enforces document authorization.
• Equating no model training with no service storage.
• Assuming a private Foundry endpoint makes all dependencies private.

What to remember

Map every requirement to the boundary that can enforce it, then verify forbidden paths. Keep user authority, agent authority, tenant scope, storage location, processing location, and retention separate. Preview and network-support constraints can invalidate an otherwise attractive component choice.

Knowledge check

References

• Microsoft, Increase application security using Zero Trust principles
• Microsoft, Agent identity concepts in Microsoft Foundry
• Microsoft, Multitenancy and Azure Cosmos DB
• Microsoft, Security filter pattern
• Microsoft, Data, privacy, and security for Foundry Models sold by Azure in Microsoft Foundry
• Microsoft, How to configure network isolation for Microsoft Foundry
• Microsoft, What is Memory?
• Microsoft, Use Microsoft Purview to manage data security & compliance for Microsoft Foundry