Azure AI Foundary Retaining Data Issue

Question

Hi, we are requesting to stop retaining the prompt/completion data because it goes against our security posture for soc2. We are having trouble doing this ourselves.

Answer 1

Hello Stephanie Frenel,

Thanks for raising this question in Azure Q&A forum.

Azure AI Foundry does retain conversation data by design, but you have full control over where it is stored, how long it is retained, and whether you want to delete it. Here is the complete picture of data retention in Foundry projects.

How Foundry Stores Conversation Data

Default Behavior — Foundry automatically stores:

• Threads (conversation sessions)

Messages (user inputs and agent responses)

Runs (agent execution traces, tool calls)

Memory (if using agent memory features)

Storage Location Options:

Microsoft-managed Storage Account (default) — isolated by project, same geography as your Foundry resource

Bring Your Own Storage (BYOS) — your own Azure Storage Account

Azure Cosmos DB — for advanced scenarios with custom indexing/querying​

Data Retention:

Customer-controlled — data is retained until you explicitly delete it

Double-encrypted at rest (Microsoft-managed keys + optional customer-managed keys)

No automatic deletion unless configured

How to Delete Retained Data

1. Delete Individual Threads/Conversations

python
from azure.ai.projects import AIProjectClient

client = AIProjectClient(endpoint, credential)
client.delete_thread(thread_id="your-thread-id")

2. Delete All Data for a Project (Nuclear Option)

text
Azure Portal → AI Foundry Project → Overview → Delete → Permanently delete all data

Warning: This deletes everything — threads, messages, runs, memory, everything.

3. Use BYOS for Granular Control Configure Bring Your Own Storage to use your own Azure Storage Account:​

bash
# Bicep template configuration

Then delete containers/files directly via Azure Storage Explorer or SDK.​

4. Memory-Specific Deletion (Agent Memory)

python
# Delete specific memory entries

Data Privacy Guarantees

Microsoft does NOT:

Use your data to train foundation models

Share your data with third parties

Store data outside your specified geography

Microsoft DOES:​

Perform abuse monitoring (optional, can be disabled)

Store data encrypted at rest within your Foundry project boundary

Recommended Data Management Strategy

For Compliance/GDPR:

text
1. Use BYOS → Azure Storage Account (your control)
2. Configure lifecycle policies → Auto-delete after X days
3. Enable soft delete → 7-30 day recovery window
4. Use Azure Policy → Enforce data residency

For Development:

text
1. Default Microsoft-managed storage (simplest)
2. Delete threads after testing: `client.delete_thread(thread_id)`
3. Use short TTLs on memory stores

Complete Data Deletion Checklist:

text
☐ Delete all threads: client.list_threads() → client.delete_thread()
☐ Delete memory stores: client.list_memory_stores() → client.delete_memory_store()
☐ Delete project data: Portal → Delete project
☐ Verify BYOS containers emptied (if used)
☐ Confirm no data in Application Insights (if enabled)

If it helps kindly accept the answer.

Best Regards,

Jerald Felix

Answer 2

Hello Stephanie Frenel,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you are deeply concerns about Azure AI Foundry Retaining Data Issue.

Azure OpenAI, when used through Azure AI Foundry, applies a built‑in 30‑day abuse‑monitoring retention window for prompts and completions, and this cannot be disabled by customers on their own. The only path to fully stop this retention is applying for Modified Abuse Monitoring, an approval workflow available only to eligible managed organizations. Microsoft confirms the approval‑based process and the retention behavior in official references, including the Azure OpenAI Abuse Monitoring overview and the Microsoft Community Hub Data Storage article, which explains what data is and is not persisted in your tenant. - https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/data-storage-in-azure-openai-service/4382502 and https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/abuse-monitoring give you more insight.

If your organization does not qualify for that approval, the correct compliance posture shifts to preventing sensitive data from ever reaching the service. You can accomplish this by enforcing pre‑processing redaction or tokenization at an API gateway such as Azure API Management, and by avoiding stateful Foundry features like stored threads or memory that create additional persistence. These practices are consistent with guidance from Microsoft’s published abuse‑monitoring documentation, which clarifies that model safety systems operate independently from your own storage and that persisted data stems only from optional features you enable. - https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/data-storage-in-azure-openai-service/4382502 and https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/abuse-monitoring

To complete SOC‑2‑aligned governance, ensure your telemetry is captured without storing user content by routing only metadata into Log Analytics and enabling Microsoft Purview’s built‑in audit and lifecycle controls for Azure AI services. The Microsoft Community Hub guidance affirms that user‑controlled feature storage can be deleted at any time, and Purview’s governance pipeline provides compliant oversight without retaining sensitive payloads. Together, these measures form the only accurate, validated, and policy‑aligned method to operate Azure AI Foundry securely when full abuse‑monitoring opt‑out cannot be granted. - https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/data-storage-in-azure-openai-service/4382502

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

---

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.