When an organization adopts Copilot and generative AI agents, an old data-permission problem becomes faster and more visible. Files that were overshared for years can now be found through natural-language search and summarized into convincing responses. At the same time, new AI components—model deployments, indexes, orchestration services and agent tools—add their own attack surface. An SC-500 engineer must distinguish data exposure management from cloud AI workload posture and threat protection rather than expecting one dashboard to solve both.
A fictional company wants an internal research assistant to summarize regional contract procedures. Some SharePoint files are available to too many employees, and one Foundry app retrieves those files through an index. The business wants to preserve useful collaboration while stopping inappropriate disclosure. The secure approach inventories the information, corrects source access, examines AI data flows, and protects the cloud assets that implement retrieval and generation.
Map data visibility before applying AI protections
Start by locating the information the assistant may reach. Identify source repositories, file owners, sharing groups, anonymous or organization-wide links, sensitivity labels, retention requirements and the account under which retrieval executes. A list of Copilot licenses does not show which documents are readable. The same permission can expose content through a conventional search or an AI summary; the model merely changes how quickly the content becomes useful to an unintended reader.
For each document class, record the intended audience. A policy visible to all staff might be appropriate, while a confidential compensation worksheet and a legal negotiation draft are not. Test the source system’s effective permissions using representative non-administrator identities. If the underlying file is overshared, asking the AI assistant to “keep it secret” is not an adequate fix.
Purview-driven AI data security begins by establishing which sensitive files a real user can already reach. A SharePoint site may contain confidential records, and a Copilot interaction can reveal that overexposure when an agent retrieves content within its allowed access. Use a fictional project with a public team site, a confidential finance document and two users with different permissions. Record source location, sensitivity label, actual read access, DLP policy coverage and the response when a user’s permissions change. Purview exposure findings and Defender posture insights can guide investigation, but a dashboard recommendation is not proof that permissions were corrected. An independent SC-500 Purview and AI-posture practice scenario that merely names a security product is incomplete: the relevant answer must identify the excessive source grant, the consuming workload identity, an authorized correction and a negative retrieval test showing that the protected document is no longer exposed.
Use Purview data risk assessments to find oversharing
Microsoft’s current Purview Data Security Posture Management guidance describes assessing potential oversharing risks. The current DSPM experience expands earlier DSPM for AI capabilities; documentation may still refer to DSPM for AI (classic). Confirm which portal/version is active before following screenshots or assuming a specific finding is present in every tenant.
An assessment can guide security owners toward publicly or broadly shared material, sensitive content and other risk patterns, subject to permissions and product coverage. Translate each finding into a source-level decision: restrict a sharing link, adjust group membership, apply an appropriate label, remove stale copies or accept a justified broad audience. A false positive should be documented and reviewed rather than used as an excuse to disable monitoring for the whole repository.
Do not confuse discovery with remediation. DSPM visibility helps identify data worth examining, but the effective permission is enforced by the repository and identity service. After a sharing correction, verify access as an unauthorized user and retest the assistant’s retrieval. A dashboard finding marked resolved without checking the original source permission and cache state is weak evidence.
Protect source classification and retrieval indexing
Information extracted for AI can become a second sensitive store. A search index, vector embedding, model input, generated citation and long-lived conversation transcript may each carry information from protected files. Configure ingestion to preserve source identity, sensitivity, version and access requirements. A document’s SharePoint ACL does not necessarily propagate automatically into every custom search or agent runtime.
For the fictional research assistant, place two policy files and one restricted legal document in a synthetic index. The research user should retrieve public policies but not the restricted source. If a revoked SharePoint grant remains in an older index or cached response, the retrieval pipeline requires a synchronization and invalidation strategy. A polite refusal after the private passage already reached the model is not a complete prevention success.
Protect evaluation datasets as well. Copying real confidential prompts and responses into a broadly accessible test workspace can recreate the leak the production controls were meant to stop. Use synthetic fixtures and restricted investigation stores when customer data is not necessary. Keep source evidence IDs and classification without logging every private paragraph into ordinary operational telemetry.
Distinguish Purview data risk from Defender AI posture
Purview focuses on information risks, classification, sharing and related governance controls. Microsoft Defender for Cloud’s AI security posture management addresses risk in cloud-hosted AI workloads and their dependencies, including model endpoints, data stores, identities and application infrastructure where supported. These responsibilities overlap but are not interchangeable.
Defender CSPM can show a generative AI bill of materials, cloud configuration recommendations and attack paths across supported Azure, AWS and Google Cloud workloads. Agent-level discovery and security posture are still identified as preview capabilities. Microsoft’s current guidance states that since July 1, 2026, discovery and posture for Microsoft Foundry and third-party cloud agents require Agent 365 licensing, while Defender CSPM continues to discover Foundry accounts and projects. Check that license, connector and onboarding coverage before claiming to see each agent, tool or backing data store; a missing agent-level finding may indicate absent entitlement rather than a safe workload.
For the fictional project, connect two views: which data source is overly exposed, and which AI resources and identities can reach it. Prioritize the combination of sensitive data, exploitable network reachability and excessive permissions. Microsoft SC-100 AI workload architecture helps define system-wide ownership; here the SC-500 implementation test is narrower and observable: change the affected permission or network route, confirm that the unauthorized retrieval path is denied, and verify that the legitimate assistant still works.
Identify AI infrastructure vulnerabilities and threats
Cloud AI services can be misconfigured in familiar ways: exposed endpoints, excessive credentials, unapproved network access and leaked application secrets. Defender CSPM provides preventive/posture signals; supported Defender for AI Service and workload protection capabilities can provide other threat and runtime context under applicable plans. Verify what protection is actually enabled for the chosen Foundry workload, rather than declaring that every cloud-hosted model request receives identical detection.
An attack-path finding is a hypothesis about exploitable combinations, not proof that data was stolen. Review the vulnerable entry point, principal and reachable target. Fixing only a visible warning banner may leave the underlying privilege chain intact. After remediation, test that the original unapproved path is denied and that the legitimate assistant still functions under its authorized scope.
Where the workload depends on an external API or MCP tool, evaluate the identity and destination path separately. Model safety filters can address some harmful content but do not replace access policies on a storage account, database or tool service. Keep logs and correlation identifiers sufficient to tie a suspicious request to its deployment and permitted scope, without storing unnecessary customer prompts.
Apply AI data policies and monitoring at the correct layer
Microsoft Purview can contribute labels, DLP, audit and data security governance for supported AI scenarios, while source services enforce real access. Decide which classifications prohibit external disclosure and which allow an approved internal use. Document the actual supported applications and data channels of any DLP rule; an enterprise policy does not automatically intercept every custom model client or third-party integration.
For a confidential contract summary, test sharing through the normal user interface, through a Copilot retrieval path and through the custom assistant’s index. If one route fails to apply the intended restriction, investigate its data source and identity binding rather than claiming the label alone is broken. Validate that an employee’s revoked entitlement does not persist indefinitely in an application cache.
Data inventory coverage must itself be tested. If a source lives outside a supported Purview connector, the absence of a DSPM finding cannot prove the source is appropriately restricted. If an AI workload was never onboarded into the cloud-security graph, a missing attack-path finding cannot prove it has no exploitable exposure. Reconcile the current source-repository inventory, deployed AI resources and configured product connectors, then document which portions are unassessed. This prevents apparently clean dashboards from masking the highest-risk unknowns.
Operations teams should review both preventive and detective signals. A Purview finding may show sensitive content shared too widely; Defender for Cloud may show an internet-exposed AI endpoint; identity logs may show suspicious agent access. Combine those facts into an incident timeline but retain their different evidentiary meanings. Do not equate “no alert” with “no exposure.”
Build a cross-product evidence and remediation workflow
Create a synthetic folder with a public policy, restricted finance note, and deliberately overshared dummy contract. Label owners and expected readers. Run a supported data-risk review or inspect effective permissions, correct the oversharing and verify a denied read as a nonmember. Then connect a synthetic Foundry application to only the permitted sources and test that an unauthorized user’s query never delivers restricted evidence to the model.
Separately, inspect the application’s deployment identity, endpoint exposure, network controls and model/agent inventory in Defender for Cloud where supported. Record which features were actually enabled and their plan/preview status. Create a controlled hypothetical attack path from an exposed endpoint to sensitive storage, apply a narrow permission or network fix, and recheck the path. If no active tenant is available, mark all simulated outcomes as planned tests, not executed results.
Finish with a clear ownership record: repository owner corrects sharing, identity team reviews grants, application owner updates indexing, security engineering remediates cloud exposure and incident response verifies any actual compromise. Those steps turn AI security findings into defensible controls rather than another dashboard. SC-500 readiness means the team can show that the right person gets the right answer without turning sensitive source content into a newly exposed AI artifact.