Clarification on Encryption in Transit and At Rest for Azure AI Document Intelligence and Azure OpenAI (GPT-4o)

Question

Hello Microsoft Team,

We are currently using Azure AI Document Intelligence for OCR extraction and Azure OpenAI (GPT-4o) for key–value pair mapping from a Python-based application.

We would like to understand and formally confirm how encryption in transit and encryption at rest are handled when data is sent from our application to these services.

Current Configuration

We have implemented the following security controls on both services:

• ✅ Customer-Managed Keys (CMK) enabled
• ✅ Azure Key Vault configured and validated
• ✅ Key Vault key audit logs verified
• ✅ Diagnostic settings enabled
• ✅ Request/response metadata visible in Azure Monitor / Log Analytics

⸻

Clarifications Requested

We request official clarification on the following points for both Azure AI Document Intelligence and Azure OpenAI (GPT-4):

1. Is the request payload (binary document/image content or prompt input) encrypted before transmission to the Azure service, or is encryption applied only during transport?

Is encryption applied exclusively via transport-level security (TLS/HTTPS), or is there any payload-level encryption performed by the service?

Is there any request header, parameter, or diagnostic indicator that explicitly denotes encryption for an individual request?

Can encryption of request payloads be viewed, verified, or inferred from Azure Monitor, Log Analytics, or other diagnostic logs?

Does Customer-Managed Key (CMK) encryption apply only to data persisted at rest, or does it also protect request payloads during processing or in transit?

Is TLS (HTTPS) the only supported and recommended mechanism for encrypting data in transit to Azure AI Document Intelligence and Azure OpenAI services?

From a Microsoft best-practice and compliance standpoint, how do regulated organizations (e.g., financial institutions) typically demonstrate to auditors and clients that:

         • Data sent to these services is encrypted in transit   
         • Data is encrypted at rest
```For external audits and compliance reviews, what mechanisms or documentation can customers rely on to verify and provide evidence that data:

```sql
         • Is encrypted in transit   
        • Is encrypted at rest
```We would appreciate guidance or references to official documentation that can be used to support **security reviews, audit requirements, and client assurance.**

Answer 1

Hey Akash Maurya

It sounds like you're diving deep into the security aspects of Azure AI Document Intelligence and Azure OpenAI (GPT-4o). Here's what I can share regarding your questions on encryption in transit and at rest:

1. Encryption of Request Payloads:
   • Azure OpenAI ensures that your data is encrypted by default when it is persisted to the cloud using 256-bit AES encryption, which is FIPS 140-2 compliant. This mainly pertains to data that's stored at rest. However, during transmission, Azure employs TLS/HTTPS to secure data while in transit, protecting it from interception. For your specific question, it’s important to note that the request payload (the data being sent to the service) is encrypted during transport but not pre-encrypted at the payload level prior to sending.
2. Indicators of Encryption:
   • There aren't explicit request headers or parameters from Azure OpenAI that specifically denote encryption for individual requests. As such, you'll need to rely on transport-level security to ensure your data remains secure while in transit.
3. Monitoring Encryption:
   • While Azure Monitor and Log Analytics provide comprehensive meta-data regarding requests and responses, they do not explicitly confirm encryption status for individual requests. Your best approach is to refer to the security configurations you have in place.
4. Customer-Managed Keys (CMK):
   • CMK applies to data at rest only. It doesn't extend to request payloads during processing or in transit. This means while your stored data is encrypted with CMK, the data transmitted for processing is secured via TLS rather than a CMK.
5. Supported Mechanisms for Data Encryption in Transit:
   • TLS (HTTPS) is indeed the only supported mechanism for securing data in transit to both Azure AI Document Intelligence and Azure OpenAI services. Following best practices as outlined in Azure’s security documentation is crucial for secure data transmission.
6. Audit Compliance for Regulated Organizations:
   1. For demonstrating compliance with auditors, you can refer to Azure's security and privacy documentation. Microsoft maintains extensive documentation and compliance offerings to assist organizations in securing their data.

Reference

1. Azure OpenAI Data Privacy Documentation
2. Microsoft Trust Center
3. Microsoft Products and Services Data Protection Addendum
4. Azure Compliance Offerings
5. Azure OpenAI encryption

Hope it addresses all your queries.

Thank you.

Answer 2

To confirm and prove to your financial client that payloads sent to Azure Document Intelligence and Azure OpenAI are encrypted in transit and protected from third-party access, consider the following points based on Microsoft's security practices:

1. Encryption in Transit: Azure services, including Azure Document Intelligence and Azure OpenAI, use Transport Layer Security (TLS) for encrypting data in transit. This ensures that data is protected from interception while being transmitted to Azure services.
2. Payload Encryption: The encryption applied is primarily at the transport level (TLS/HTTPS). There is no indication that the request payloads (Base64 encoded images or text prompts) are encrypted before they are sent to Azure services unless you implement client-side encryption.
3. Request Headers and Diagnostics: There are no specific request headers or parameters that explicitly indicate encryption for individual requests. However, you can monitor the security of your requests through Azure Monitor and Log Analytics, which can provide insights into the security of your data in transit.
4. Viewing Encrypted Payloads: Encrypted request payloads cannot be viewed in Azure Monitor or Log Analytics as they are transmitted securely over TLS. The logs will show metadata about the requests but not the content itself.
5. Customer-Managed Keys (CMK): CMK encryption typically applies to data at rest. It does not extend to the request payloads during transmission unless you implement additional client-side encryption before sending the data.
6. Supported Mechanisms for Encryption: TLS (HTTPS) is the primary and recommended mechanism for encrypting data in transit to Azure AI Document Intelligence and Azure OpenAI.
7. Demonstrating Security to Auditors: Financial institutions often demonstrate security compliance through a combination of official Microsoft documentation, security audits, and possibly packet captures showing TLS-encrypted traffic. Providing documentation from Microsoft regarding encryption practices can also be beneficial.
8. Recommended Proof: Official Microsoft documentation is typically the best way to prove payload encryption to external clients. Packet captures can provide additional evidence but may not be necessary if documentation suffices.

By implementing these practices and utilizing Azure's built-in security features, you can provide the necessary assurances to your client regarding the confidentiality and security of their sensitive data.

---

References:

• Data, privacy, and security for Document Intelligence
• Encryption in the Microsoft cloud
• Azure Government security