SC-500 Security for AI: Copilot Oversharing, Purview DSPM, Entra Agent ID, Foundry Guardrails and Defender for AI

Use SharePoint Advanced Management's data access governance reports to find overexposed sites: the site permissions snapshot report gives you today's baseline, and the activity reports show oversharing from the last 28 days. This matters for AI because Microsoft 365 Copilot never grants new access: it answers from content the user can already open. A site that was opened to Everyone except external users (EEEU) years ago is invisible in daily work, but Copilot will happily summarize it for anyone in the tenant.

The distinction to remember: an activity report can never show a grant older than its 28-day window, so it catches new oversharing but not the backlog. For a pre-Copilot cleanup, start with the snapshot permissions report.

Fixing overshared sites: Restricted Content Discovery, restricted access control and site access reviews

Choose the remediation by what must change: Restricted Content Discovery hides a site from Copilot and organization-wide search without touching permissions; restricted access control denies entry to anyone outside chosen groups; a site access review asks the site owner to fix permissions.

Practical details

• Restricted Content Discovery is applied per site (from Active sites in the SharePoint admin center) and can be delegated to site administrators. On very large sites, Microsoft notes that sites with more than 500,000 items can take over a week to reflect the change, so it is not an overnight fix for a huge site.
• Restricted access control works immediately as an access gate: users outside the group are denied whatever their permissions say.
• A site access review is started from a supported data access governance report (sharing links, EEEU or site permissions). From the web view you can start reviews for up to 100 sites at once. Each owner receives an email tailored to that report's issue, fixes access through Manage access, then completes the review with comments that the admin tracks under My review requests.
• EEEU exposure is an internal problem: it comes from a grant to every employee, so controls aimed at external sharing (guest access, anyone links) don't change it.

Data risk assessments in Microsoft Purview Data Security Posture Management (DSPM) find SharePoint content that Copilot and agents could overshare, and their Protect tab turns each finding into a remediation. DSPM is the Purview solution for seeing and reducing data risk from Microsoft 365 Copilot, agents and other AI apps.

Default vs custom assessments

From item-level results you can resolve an item, apply a label, notify the site owner or remove the sharing link, all from Purview rather than the SharePoint admin center.

Protect-tab remediations

Pick by scope: when only some files must be kept from Copilot, label-scoped DLP beats a site-wide restriction; when files aren't labelled yet, auto-labeling comes first.

Seeing AI interactions: auditing, onboarded devices and the browser extension

DSPM sees different AI apps through different routes: Microsoft 365 Copilot and agent interactions arrive through the Purview audit log, while sensitive data pasted into third-party generative AI websites is only visible from devices onboarded to Purview, plus the Microsoft Purview browser extension for Chrome.

Each route is independent, so a partial view tells you which route is missing: Copilot data proves the audit route works and says nothing about the endpoint route, while a completely empty view points to the audit log, which every Copilot view depends on. Data risk assessments are a different tool altogether: they evaluate oversharing in stored content rather than recording interactions. Interactions appear in activity explorer, where you can see sensitive information types detected in prompts and responses.

Copilot Studio agents get real-time protection by connecting an environment to an external threat detection provider such as Microsoft Defender, which evaluates each tool invocation before it runs and can block it. Two layers are involved: the Copilot Studio side (Power Platform admin center) and the Defender side (rules and alerting).

Copilot Studio side: external threat detection

• Per environment. It is set up for each Power Platform environment under Security > Threat detection > Additional threat detection. There is no tenant-wide or inherited setting, so an environment created later is unprotected until you set it up too.
• Entra app with a federated credential. The connection uses a Microsoft Entra app registration with a federated credential. Registering an app alone does nothing until the environment is configured.
• Error behavior. If the provider doesn't answer within about one second, or errors, the default Allow the agent to respond lets the tool run (fail open). Choose Block the query to fail closed.
• Generative orchestration only. The provider is called when the generative orchestrator plans a tool call. Classic agents built on authored topics and trigger phrases skip it entirely, so switch them to generative orchestration to protect them.

Defender side: rules and alerts

Keep the Default rule and add scoped custom block rules: switching the Default rule off removes visibility for every agent not covered by a custom rule. Alerts and incidents in the Defender portal need the Microsoft 365 connector (set up from the Security for AI Get started page). Without it, blocking still works, but the SOC sees no matching alerts.

Conditional Access for agents applies to the subject of the token being requested, so the policy must target the identity that actually asks for the token: the agent identity (or its blueprint) when the agent acts as itself, and the signed-in user when the agent acts on a user's behalf. Microsoft Entra Agent ID gives AI agents their own identities. An agent identity blueprint is the template that agent identities are created from; an agent user is a separate user-like account some agents use.

Agent identities are selected through the Agents option, not the Workload identities option used for ordinary service principals.

Scaling with custom security attributes

Picking agents one by one means editing the policy for every change, and excluding a blueprint is too coarse when agents from the same blueprint are approved individually. Microsoft's recommended pattern is a policy that includes all agent identities, excludes by a custom security attribute (for example an approval-status attribute) and grants Block. Approving an agent then means tagging it; the policy never changes, and new untagged agents are blocked automatically.

Agent risk

Microsoft Entra ID Protection scores agent identities, and Conditional Access exposes that as the Agent risk condition. To stop high-risk agents: all agent identities, all resources, Agent risk High, grant Block. Sign-in risk is a user signal and service principal risk covers workload identities, so neither applies to agents. As with any new block policy, start in Report-only, review the impact in the sign-in logs, then switch it On.

Licensing

Conditional Access for agents has its own licence requirement: Microsoft 365 E7 (which includes Agent 365 and Microsoft Entra Suite), or a Microsoft Agent 365 licence paired with at least Microsoft Entra ID P1 or Microsoft 365 E3. Entra ID P1 alone covers Conditional Access for users, not for agents.

Agent ID separates technical administration (owners) from business accountability (sponsors), and grants agents governed, time-bound access through entitlement management access packages.

The split is deliberate: a sponsor can always take an agent out of service quickly, but bringing it back is a technical decision reserved for an owner or an administrator such as an Agent ID Administrator.

Groups as sponsors

Every agent identity and blueprint needs at least one sponsor. Using a group keeps sponsorship working through staff changes, and all members get sponsor rights. Allowed: dynamic membership groups (security or Microsoft 365) and assigned-membership Microsoft 365 groups. Not allowed: assigned-membership security groups and any role-assignable group.

Access packages for agents

Entitlement management access packages can give agent identities security group membership, API permissions and Microsoft Entra roles. Set the assignment policy's Who can get access to include agent identities, add approvers and an expiry (for example 90 days). The sponsor (or the agent itself) requests the package with a business justification, approvers decide, the sponsor is notified before expiry and can request an extension, which goes through approval again.

Conditional Access sits on top of whichever grant is used: it can add conditions or block a token, but it never grants access itself.

An agent's blast radius is everything its identity could reach if compromised (permissions, knowledge sources and actions), and you assess it in the Microsoft Defender portal from the AI agents inventory, attack paths and advanced hunting.

• AI agents inventory (Assets > AI agents) lists discovered agents. For Microsoft Foundry agents (and AWS Bedrock or Google Vertex AI agents) the detail pane shows posture insights, permissions, knowledge sources, capabilities and risk factors, and links to attack paths on the map showing how a compromise could spread to sensitive resources.
• Copilot Studio agents are discovery only in the inventory: their detail pane doesn't show posture. Assess their permission breadth, knowledge source configuration and risky settings with the prebuilt AI Agents queries in Advanced hunting.

AI Gateway puts Azure API Management in front of a Microsoft Foundry resource so you can enforce per-project token limits, content safety and keyless authentication on model traffic. In Foundry you enable it for a Foundry resource under Manage > AI Gateway, add projects to it, and set limits per project from the Foundry portal without writing policy XML.

Which API Management instance

• Use existing APIM lists only instances in a v2 tier, in the same tenant and subscription, where you hold API Management Service Contributor or Owner. Classic tiers (including classic Premium) never appear, whatever your permissions.
• Create new provisions a Basic v2 instance.
• If the Foundry resource has public network access disabled, the gateway must be privately reachable: Standard v2 or Premium v2 with a private endpoint, or Premium v2 injected into a virtual network. Standard v2 virtual network integration is outbound only, so the gateway's inbound endpoint stays public.

Token limits and their status codes

The point of the gateway is per-project metering. A model deployment's own TPM quota is one pool for all callers of that deployment; AI Gateway divides consumption by project in front of it.

API Management policies for model traffic

• llm-token-limit enforces token rate limits and quotas (what AI Gateway configures for you).
• llm-content-safety sends content to an Azure AI Content Safety backend and returns 403 when it is flagged. In the inbound section it checks prompts before they reach the model; in the outbound section it checks completions. shield-prompt="true" adds detection of user prompt attacks (jailbreaks). Per-category thresholds block content at or above the threshold severity: threshold 4 blocks severity 4 and higher, threshold 5 lets severity 4 through.
• Managed identity to the backend: the authentication-managed-identity policy gets a Microsoft Entra token with API Management's system- or user-assigned identity and attaches it to backend calls, so no Foundry API key is stored anywhere (not even in named values or Key Vault). The identity needs a suitable Azure role on the Foundry resource. validate-jwt is different: it checks tokens that callers present to the gateway.

Defender for AI Services (threat protection for AI services) is the Defender for Cloud plan that scans prompts to Foundry and Azure OpenAI workloads and raises alerts such as jailbreak, credential theft and data leakage; the Data and AI security dashboard summarizes AI and data resources and that protection in one view.

Enabling and tuning the plan

Enable it per subscription: Defender for Cloud > Environment settings > the subscription > the AI services plan On. It works with Azure AI Content Safety Prompt Shields and Microsoft threat intelligence, and its alerts flow into Defender XDR. Plan settings and app changes enrich those alerts:

Data and AI security dashboard

The dashboard in Defender for Cloud gives a per-cloud view of data and AI resources, their protection coverage and top issues. Its AI closer look shows AI discovery, AI threat protection (prompts scanned and AI alerts by severity), AI queries in security explorer, and internet-exposed resources used for grounding; a data closer look does the same for data stores. It needs the Microsoft.Security resource provider registered on each subscription, and viewers need at least the Security explorer role (read access to assessments, subassessments and alerts). Each widget depends on a plan:

Because each tile maps to one plan, a dashboard where some tiles are populated and others are empty is diagnosed tile by tile: find the plan behind the empty tile and check whether it is enabled on that subscription. Microsoft 365 data posture lives in Purview DSPM, a separate product.

A Foundry guardrail is a set of risk controls (such as hate, violence, user prompt attacks and indirect attacks) applied at chosen intervention points, and an agent uses the guardrail assigned to it, which fully replaces its model deployment's guardrail.

Intervention points

Match the risk to where it arrives. A user prompt attack (jailbreak) is typed by the user; an indirect attack (cross-domain prompt injection) hides instructions in data the agent reads, such as web pages from Bing grounding, so it is caught by an indirect attack control at tool response. Scanning output is too late: the agent has already acted on the injected content.

Which guardrail applies

• An agent with its own guardrail uses only that guardrail: no merge and no "strictest wins". The deployment's guardrail still governs direct calls to the model.
• An agent with no assigned guardrail inherits its model deployment's guardrail.
• Controls are evaluated independently at their own intervention points.

Coverage limits for agents

• Agents support only the annotate and block action.
• Some preview risks, such as Groundedness and Spotlighting, aren't supported for agents: they still work for model deployments using the same guardrail.
• Tool call and tool response controls need moderation support from the tool. Supported tools include Azure AI Search, Azure Functions, OpenAPI, SharePoint grounding, Fabric Data Agent, Bing grounding, Bing Custom Search and Browser Automation; other tools, such as a custom MCP server, aren't scanned at those points.

Guardrails handle content risk only; token limits belong to AI Gateway.

The Microsoft 365 admin center's agent registry lets an AI Administrator control each agent's availability and lifecycle, and each action has a different reach: block, uninstall, delete, stop, and owner changes.

Reading the table by reach: block is reversible and leaves the agent's configuration untouched, delete starts a removal clock, and stop is the only action that reaches the Azure compute behind a Foundry agent, which matters because block's Copilot Chat scope leaves direct callers unaffected. Ownership changes follow the same logic: adding owners is additive, while assigning a new owner is a transfer.