Privacy, Access Control, and Security in Enterprise AI

The leak that set the agenda

In April 2023, Samsung employees uploaded internal source code, meeting notes and other confidential material to ChatGPT. Within weeks, according to Bloomberg and Tech Monitor, the company temporarily restricted generative AI tools on company devices, warning that breaches could lead to disciplinary action up to dismissal. Several other large employers restricted the tools around the same time.

The incident shaped how many boards still think about AI risk: the fear that the model will absorb confidential data and repeat it to someone else. That risk was real for consumer services whose terms allowed training on user content. It is a much smaller part of the picture for enterprise deployments today. OpenAI, for example, has not used data sent to its API for training by default since 1 March 2023, and Microsoft states that prompts, responses and data accessed through Microsoft Graph are not used to train the foundation models behind Microsoft Copilot.

Our thesis is that enterprise AI exposure is now mostly an access-control problem in new places, and should be managed with the same discipline as any other access to sensitive data. Three paths matter more than model memorization:

• Data sent to services under the wrong terms, because staff use unsanctioned tools or because the sanctioned service's retention and storage settings were never reviewed.
• Retrieval that ignores or flattens permissions, so an assistant shows a user content they could technically open but should never have been able to find.
• Agents that take instructions from content they read, so an email or document can make the system send data somewhere it should not.

A fourth path runs underneath the other three: copies of prompts, retrieved text and embeddings in logs, indexes and stores that nobody governs.

Path 1: know exactly what your provider keeps

"Zero data retention" is often used loosely. In practice, enterprise model services keep data for three different reasons, and each has its own control.

• Abuse monitoring logs. Providers keep prompts and outputs for a period to detect misuse. OpenAI's API retains abuse monitoring logs for up to 30 days by default. Anthropic automatically deletes API inputs and outputs within 30 days by default, but keeps content flagged by its trust and safety systems for up to two years. On Azure, flagged samples may be reviewed by automated systems and, where necessary, by authorized Microsoft staff.
• Application state. Features that remember things store data by design. OpenAI lists conversations, assistants and threads, vector stores, files, fine-tuning and batch inputs as stored until deleted, even under zero data retention. Azure's equivalent stateful features, such as the Responses API, Assistants threads and stored completions, keep data at rest in the customer's resource and geography.
• Training. Excluded by default on the enterprise services above, but worth confirming in the contract for every provider and every product tier.

Zero data retention and modified abuse monitoring are not settings you switch on. OpenAI and Microsoft both make them available only after approval. Anthropic offers zero data retention by agreement.

Location matters too. Azure's Global and DataZone deployment types can process prompts in any geography where the model is deployed, or anywhere within the chosen data zone, while stored data stays in the customer's geography. OpenAI lists the UAE among its data residency regions. For Gulf organizations with residency obligations, the deployment type and region are compliance decisions, not performance settings.

The practical step is a provider data map: for each AI service in use, record what is stored, where, for how long, who can see it, and whether training is excluded, and keep it next to your records of processing.

Path 2: make retrieval respect the source's permissions

Retrieval-augmented generation (RAG) and enterprise copilots answer from your own content. That makes their access model the most important security decision in the system.

Microsoft's documentation states the principle plainly: Copilot only surfaces organizational data that the user has at least view permission to see. That is the right design, and it has an uncomfortable consequence. Content that was overshared but obscure becomes overshared and discoverable. A salary spreadsheet shared with "everyone" years ago was safe only because nobody knew it existed. An assistant that searches everything the user can open will find it.

Custom RAG systems carry a second risk: permissions that are copied rather than enforced. Azure AI Search's documentation describes a common pattern in which each indexed document carries a field of group identifiers and every query filters on the caller's groups. It is explicit that the principal in that field is just a string, with no authentication or authorization behind it. If group membership or document permissions change at the source and the index is not updated, the index keeps answering with yesterday's permissions.

Strong retrieval designs share five properties:

1. The user's identity flows end to end. The retrieval layer queries on behalf of the signed-in user, not a broad service account.
2. Permissions are enforced at query time against the source or a synchronized copy with a defined maximum lag, and the system fails closed when it cannot check.
3. Deletion and reclassification propagate to the index and embeddings within a defined window.
4. Embeddings are treated as sensitive data. OWASP's 2025 entry on vector and embedding weaknesses notes that embedding inversion attacks can recover substantial portions of source text.
5. Retrieval is logged per answer, so you can show which sources were used and investigate misuse.

Before rolling out any copilot, run an oversharing review on the content it will search. It is usually cheaper than any AI-specific control. For the broader design choice between retrieval and model customization, see RAG vs Fine-Tuning vs Custom LLM.

Path 3: assume content will try to give instructions

Large language models process instructions and data in the same channel. Anything an AI system reads, an email, a web page, a shared document, can contain text that the model treats as a command. OWASP ranks prompt injection first in its 2025 Top 10 for LLM applications.

The clearest real case is EchoLeak (CVE-2025-32711), found by researchers at Aim Security in Microsoft 365 Copilot. A single crafted email, without any click by the user, could lead Copilot to pull internal content into its answer and send it to an external server. The researchers describe chaining several bypasses, including Microsoft's cross-prompt injection classifier, link redaction, automatically fetched images and a Microsoft Teams endpoint allowed by the content security policy. Microsoft fixed it on the server side in May 2025, with no customer action required and no evidence of exploitation in the wild.

The lesson is not about one product. Any assistant that reads untrusted content, can access sensitive data, and can send data out has all three ingredients. Controls should break at least one of them:

• Limit what agents can do. Give each agent the narrowest data access and tools it needs. OWASP lists excessive agency as a separate risk for this reason.
• Control egress. Block or proxy outbound links, image fetches and tool calls to unapproved destinations.
• Separate trusted instructions from retrieved content and treat model output as untrusted input to anything downstream.
• Require human approval for actions that send, publish, pay or delete.
• Test adversarially before launch and after each significant change, using injection payloads hidden in documents and emails.

Before every path: minimize what reaches the model

Every path above is less damaging if less sensitive data reaches the model in the first place.

• Classify sources before indexing and exclude or mask categories that the use case does not need. This depends on the classification work described in governance programs; without it, redaction rules have nothing to key on.
• Redact or tokenize personal data in prompts and retrieved text where the task allows, keeping reversible tokens only where an authorized user needs the original back.
• Apply the same rules to logs. Prompt and response logs are a copy of the most sensitive content in the system and need retention limits and access control.
• Be realistic about free text. Pattern-based redaction catches card numbers and national IDs reliably, names and context far less so. Use it to reduce risk, not as the only control.

The Gulf legal baseline

Saudi Arabia and the UAE both have comprehensive personal data laws that apply to AI systems in the same way as to any other processing.

Saudi Arabia. The Personal Data Protection Law (PDPL), regulated by SDAIA, has been enforceable since 14 September 2024 after a one-year transition. It applies to processing in the Kingdom and to processing abroad of data about people residing in the Kingdom. Breaches must be notified to SDAIA within 72 hours of becoming aware of them. Sensitive data includes health, genetic and biometric data, religious and political beliefs, criminal records and location data. Transfers outside the Kingdom need appropriate safeguards or adequate protection, and the Saudi Central Bank and the Communications, Space and Technology Commission have sector rules of their own. Fines reach SAR 5 million and can be doubled for repeat offences. Public entities face the NDMO standards as well, covered in our NDMO implementation guide.

UAE. Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data applies across the mainland, while the DIFC and ADGM free zones and some sectors, such as health and banking, have their own regimes. As of the Chambers 2026 practice guide (March 2026), the federal executive regulations had not been issued and enforcement had been limited, so organizations should monitor the UAE Data Office closely. The DIFC goes further for AI: its Regulation 10, issued in September 2023, specifically governs personal data processed through autonomous and semi-autonomous systems.

For both countries, three AI-specific questions recur: where prompts and stored data are processed, whether a cross-border transfer is taking place when a global model endpoint is used, and how deletion requests reach indexes, logs and fine-tuned models.

OWASP's 2025 risks, mapped to controls

A controls checklist with evidence

What to do in the next 90 days

1. Inventory every AI service in use, including browser tools and features embedded in existing software, and identify what data reaches each.
2. Build the provider data map and apply for zero data retention or modified abuse monitoring where your data requires it.
3. Run an oversharing review on the content any copilot or RAG system will search, starting with HR, finance and legal repositories.
4. Fix identity propagation in custom RAG systems so retrieval runs as the user, and set a maximum permission sync lag.
5. Register every agent with its data access, tools and approval requirements, and remove permissions that are not needed.
6. Run a prompt injection test against each system that reads email, documents or web content and can send data out.
7. Map Saudi and UAE obligations onto the AI data flows: processing location, cross-border transfers, breach notification and deletion.

For how these controls fit into the wider AI decision-rights model, see The Enterprise AI Operating Model.

Frequently asked questions

Do enterprise AI providers train models on our data?

The major enterprise offerings exclude customer data from training by default. OpenAI has not trained on API data by default since March 2023, Azure-hosted models do not use prompts to train foundation models, and Microsoft Copilot does not use prompts or Graph data for training. Confirm the terms for every product tier you use, because consumer terms differ.

What is zero data retention?

It is an arrangement under which a provider does not keep prompts and outputs in its abuse monitoring logs. It requires approval or a specific agreement, and it does not cover features that store data by design, such as files, vector stores, threads or stored conversations.

How do you enforce access control in RAG?

Run retrieval as the signed-in user, enforce document permissions at query time against the source or a closely synchronized copy, fail closed when permissions cannot be checked, propagate deletions to the index, and log which sources each answer used.

What is the biggest security risk in enterprise AI?

OWASP ranks prompt injection first in its 2025 Top 10 for LLM applications. The risk is greatest where a system reads untrusted content, can access sensitive data and can send data out. Breaking any one of those three conditions sharply reduces exposure.

Sources and further reading

• Samsung bans staff from using ChatGPT after data leak, Tech Monitor, 2 May 2023.
• Samsung Bans ChatGPT, Google Bard, Other Generative AI Use by Staff After Leak, Bloomberg, 2 May 2023.
• Data controls in the OpenAI platform, OpenAI. Training default, abuse monitoring retention, zero data retention, stored endpoints and data residency regions.
• How long do you store my organization's data?, Anthropic Privacy Center.
• Data, privacy, and security for Foundry Models sold by Azure, Microsoft Learn.
• Data, Privacy, and Security for Microsoft Copilot, Microsoft Learn.
• Security filter pattern, Azure AI Search, Microsoft Learn.
• EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System, Reddy and Gujral, arXiv, 2025.
• OWASP Top 10 for LLM Applications 2025 and LLM08:2025 Vector and Embedding Weaknesses, OWASP GenAI Security Project.
• Data protection laws of the world: Saudi Arabia and UAE (general), DLA Piper.
• Data Protection and Privacy 2026: UAE trends and developments, Chambers and Partners, March 2026.

Provider terms are as published on 9 August 2026 and change often. This article is general guidance, not legal advice; confirm obligations with counsel and current SDAIA and UAE publications.