A generative AI application is still an application, but its interaction with retrieved documents, tools, plugins and delegated identities can expose information in unfamiliar ways. The SC-500 secure-compute domain explicitly tests AI security: SharePoint data exposure, Microsoft Purview DSPM, Copilot Studio real-time protection, Microsoft Entra Agent ID, Defender XDR investigation, API Management AI gateways, Defender for AI Services, Foundry guardrails, data and AI security visibility, and Microsoft 365 agent administration. These topics require distinct controls rather than a single generic \u201cAI safety\u201d setting.<\/p>\n
Consider an internal research agent that answers staff questions from SharePoint and can call a ticketing service. If a folder was broadly shared before the agent existed, the agent may make its contents easy to discover even without bypassing permissions. If a tool receives more privilege than necessary, a mistaken model instruction can translate into a consequential action. If the model endpoint lacks monitoring or request controls, unexpected usage patterns may go unnoticed. The defender needs to examine access, data, tool authority and observability separately.<\/p>\n
For the Microsoft SC-500<\/a> audience, the question is not whether model responses can be made eloquent. It is how to discover material exposures, enforce identity controls, reduce unauthorized data movement and detect credible threats. Microsoft\u2019s May 2026 skills guide names a mixture of product experiences that evolve rapidly; precise licensing, support and preview status must be checked for the environment being discussed.<\/p>\n Collaboration repositories often contain long-lived folders whose permissions were granted for convenience and never revisited. A Copilot experience may respect existing authorization yet reveal that sensitive content is visible to a broad group. This is not necessarily a new permission bypass: the underlying oversharing is the defect. An information-security team should locate the exposure, identify the data owner, evaluate legitimate access needs and correct the sharing arrangement before relying on application-level prompts to hide the material.<\/p>\n Microsoft Purview Data Security Posture Management provides visibility into sensitive data risks, including supported AI app interactions. Microsoft’s current Data Security Posture Management<\/a> describes expanded coverage and distinguishes newer experiences from classic interfaces. A dashboard recommendation must be evaluated against its affected data and actual supported source. Do not assume every third-party AI app receives identical label, audit or DLP features, or that one displayed risk score captures every record that an agent might use.<\/p>\n Imagine the agent can answer a question using a salary workbook in a broadly accessible team library. Disabling an unrelated model option is not the direct fix. Review permissions on the workbook, determine intended business access, document corrective action and test the authorized audience. Appropriate detection and governance can then reduce the risk of recurrence.<\/p>\n Microsoft Entra Agent ID extends identity-oriented management to supported agent scenarios. SC-500 includes conditional access for Agent ID, access management, and assessing the blast radius of agent-related risk in Defender XDR. These controls help security teams treat agent principals as actors with identifiable access rather than assuming every agent shares one unlimited application identity. The exact supported Conditional Access conditions and risk signals depend on feature maturity and licensing.<\/p>\n A fictional workflow agent can look up a support case but cannot approve refunds. The security design should limit its tool and data permissions to that function and provide a human approval path for actions outside its authority. Prompts stating \u201cnever approve refunds\u201d can guide language behavior, but actual authorization must be enforced by the downstream service. A legitimate authenticated identity can still be dangerously overprivileged if its grants encompass unrelated customer records or administrative operations.<\/p>\n Investigating an agent begins with what it can reach, what principal it runs as, what tools were called and which data permissions were granted. Defender XDR risk context may help understand related assets and exposures, but it is not proof that every possible instruction path has been evaluated. Security engineers should combine identity evidence, tool audit trails and business ownership to judge whether a reported agent risk merits containment or policy revision.<\/p>\n Copilot Studio agents can interact with users, knowledge sources and connected tools. SC-500 includes configuring supported real-time protection for these agents. Such protection should be considered alongside content\/data access controls, not as a replacement for them. A security team should know which supported actions can be monitored, what an alert means, and who can investigate or restrict a problematic agent. A control may have different coverage across channels, connector types or preview offerings.<\/p>\n Foundry guardrails aim to reduce certain categories of unsafe or disallowed model interactions. They can provide useful protections, but models and filters are probabilistic and cannot replace resource permissions or application validation. An agent permitted to call a sensitive API needs a hard authorization boundary even if a content safety filter is enabled. A generated response that includes no harmful language can still expose a confidential project detail if the retrieval and access design was wrong.<\/p>\n The useful test is a protected action or dataset with an explicit expected boundary. Would an unauthorized principal receive the data? Could a tool be invoked without the required approval? Are model and agent events visible at a useful level? The answer must come from supported controls and actual evidence. Avoid describing a policy as guaranteed to stop every prompt injection or every indirect instruction from a document.<\/p>\n Azure API Management can be used as an AI gateway for supported Microsoft Foundry-related API traffic. A gateway can provide controlled access, policy application, usage handling and other API-management capabilities according to its configured features. It does not automatically decide whether a human is authorized to read each source document returned by an application. A design that sends model traffic through an API gateway while leaving a tool’s database unrestricted is still incomplete.<\/p>\nOvershared SharePoint data can become a Copilot risk<\/h2>\n
Agent identity and tool permissions need their own controls<\/h2>\n
Copilot Studio real-time protection and Foundry guardrails<\/h2>\n
AI Gateway and Defender for AI Services address different layers<\/h2>\n