AI Security

Zero‑Trust File Handling for AI Summaries with Azure OpenAI and Blob Storage

Published 2026-07-10 by AISecAll Editorial

TL;DR: Store raw documents in an Azure Blob container encrypted with customer‑managed keys, grant the Azure OpenAI resource a short‑lived, read‑only SAS token, process the file in an isolated Azure Function, encrypt the summary before writing it back, and delete the original blob immediately after a successful run. Log every step to Azure Monitor for auditability.

What are the primary risks when feeding documents to an AI summarizer?

Even though Azure OpenAI does not retain user data by default, the data in transit and at rest can be exposed if the surrounding infrastructure is mis‑configured. The main attack vectors are:

• Unauthorized read access to the raw file before it reaches the model.
• Man‑in‑the‑middle interception during upload or download.
• Retention leakage when blobs are left in storage after processing.
• Privilege escalation if the AI service is granted broader permissions than needed.

Applying a Zero‑Trust mindset—verify every request, limit privileges, and encrypt data end‑to‑end—mitigates these risks.

How should I store the original document before sending it to Azure OpenAI?

Use an Azure Blob Storage container that meets the following criteria:

1. Enable Microsoft-managed keys or, preferably, customer‑managed keys (CMK) via Azure Key Vault. This ensures the data is encrypted at rest with a key you control.
2. Set the container’s public access level to Private so no anonymous reads are possible.
3. Apply a Network ACL that restricts traffic to your VNet or specific IP ranges.
4. Assign a dedicated Storage Blob Data Reader role to a service principal that will generate short‑lived SAS tokens for the summarization step.

When a user uploads a document, the web front‑end should write it directly to this container using a SAS token that expires in 5 minutes.

How can I give Azure OpenAI temporary access without over‑privileging it?

Azure OpenAI cannot be granted direct storage permissions. Instead, create a one‑time SAS URL that:

• Allows Read on the specific blob only.
• Expires after the expected processing time (e.g., 10 minutes).
• Is generated by an Azure Function that runs with a managed identity having Storage Blob Data Reader rights.

The function passes the SAS URL to the OpenAI ChatCompletion request via the file parameter (or via a prompt that includes the URL). Because the token is short‑lived and scoped to a single blob, the model can only fetch that file and nothing else.

How should I protect the summary output?

Once Azure OpenAI returns the summary, treat it as sensitive as the original document:

1. Encrypt the summary with a separate CMK before writing it back to a summaries container.
2. Store the encrypted summary in a blob whose name includes a UUID, making it hard to guess.
3. Set the Content‑Type to application/octet-stream to avoid accidental rendering in browsers.

If downstream systems need the plain text, they must request decryption through a controlled API that checks the caller’s role and logs the request.

When and how should I delete the original document?

After the Azure Function confirms a successful summary write, it should:

• Issue a Delete operation on the original blob.
• Verify deletion by attempting a GetProperties call; if the blob still exists, raise an alert.
• Optionally enable soft delete with a retention period of 1 day, then purge it after verification.

This guarantees that raw data does not linger in storage longer than necessary.

How can I audit and monitor the entire workflow?

Leverage Azure Monitor and Azure Log Analytics:

1. Log every SAS token creation with the requestor’s identity, blob name, and expiration time.
2. Log the Azure Function start/end timestamps, success/failure status, and any exception details.
3. Enable diagnostic settings on the storage account to capture Read, Write, and Delete operations.
4. Set up an alert rule for any Delete operation that does not originate from the approved function.

Export these logs to a Log Analytics workspace where you can query for anomalies, such as repeated reads of the same blob or SAS tokens that never expire.

Where does AISecAll fit into this workflow?

If you need a quick security review of your Azure OpenAI integration, AISecAll offers a free architecture assessment that checks encryption settings, role assignments, and logging completeness.

FAQ

• Do I need to encrypt the summary if it contains only public information? Yes. Treat every output as potentially sensitive because the model may retain context internally during the request.
• Can I reuse the same SAS token for multiple documents? No. Generate a unique token per document to enforce least‑privilege access.
• What if the Azure Function fails after the model has read the file? The original blob remains; you can retry the summarization or manually delete it after confirming no further processing is needed.
• Is customer‑managed key encryption mandatory? It is not required by Azure, but it gives you full control over key rotation and revocation, which is essential for Zero‑Trust compliance.
• How do I prove compliance to auditors? Export the Log Analytics query results showing SAS creation, blob reads, and deletions; these logs are tamper‑evident when stored in a separate retention‑locked workspace.