Copilot Studio Runtime Protection + Agent Management in the…

Why Copilot Studio agents are an SC-500 topic

Simple explanation

Microsoft Copilot Studio is the low-code tool that lets business users build their own AI agents — a “leave request helper”, a “compliance Q&A bot”, a “ticket-triage agent” — without writing real code. The agent reads from selected data sources (SharePoint sites, web URLs, Dataverse tables, custom connectors), is grounded with instructions, and goes live in Microsoft Teams or as a standalone web chat.

The risk: anyone licensed can build one. Without governance, you end up with hundreds of agents created by people who don’t know what “data scope” or “grounding source” mean — and each of those agents has access to whatever data its creator could see.

SC-500 expects you to know two things:

Real-time runtime protection — turning on the runtime safety controls that scan prompts, scan responses, block prompt-injection attempts, and apply Microsoft Purview DSPM-driven policy to live agent interactions.
Agent management in the Microsoft 365 admin center — discovering every agent in the tenant, reviewing its risk indicators, blocking high-risk agents, transferring ownership when the creator leaves, and applying tenant-wide guardrails.

The point of this module: bring “shadow agents” out of the shadows.

Real-time protection for Copilot Studio agents

Real-time protection is a runtime safety layer applied to live Copilot Studio agent interactions. Enabled per-agent (or, with tenant policy, by default for new agents), it covers four kinds of safety:

Real-time protection for Copilot Studio agents — four pillars of runtime safety
Safety control	What it does	When it triggers
Prompt safety	Screens user input against Microsoft-curated unsafe content classifications (violence, hate, sexual, self-harm)	Blocks or sanitises prompts matching the configured threshold
Response safety	Screens model-generated output against the same classifications before sending to the user	Blocks or sanitises responses matching the threshold
Prompt-injection detection	Detects attempts to subvert the agent's instructions via grounded content or user input	Surfaces alerts; can block when configured
Sensitive content via Purview	Applies Purview sensitivity labels and DLP for AI policies to agent interactions	Blocks responses that would surface labelled-sensitive content beyond scope; alerts on detections

Where it’s configured

Real-time protection settings live in the Copilot Studio agent’s settings (per-agent) and can be enforced tenant-wide via policy in the Microsoft 365 admin center. The protection thresholds (low / medium / high) determine how aggressively content is screened — higher thresholds reduce false negatives but increase false-positive blocks. The exam expects you to know that real-time protection is per-agent and that tenant policy can enforce a minimum protection level across all agents.

Agent management in the Microsoft 365 admin center

The Microsoft 365 admin center has a dedicated Copilot > Agents workspace (and broader Agents view for cross-product agent governance):

What admins see

Inventory of all agents in the tenant — Microsoft 365 Copilot agents (built-in + Copilot Studio + partner), with creator, owner, channels published to, knowledge sources, last-modified, last-published.
Per-agent risk indicators — flags for agents that read from sensitive-labelled sites, agents that publish to external-facing channels, agents that use unverified third-party connectors, agents whose creator is no longer in the tenant.
Usage telemetry — invocation counts, user counts, response times, top topics.
Microsoft Purview DSPM for AI signals — integrated into the agent view so admins see DSPM findings inline.

What admins can do

Disable an agent in the tenant (cuts off invocation regardless of permissions on knowledge sources).
Transfer ownership — reassign an agent when its creator leaves; agents with no owner are flagged and can be auto-disabled by tenant policy.
Block an agent from specific channels — e.g. block a Copilot Studio agent from being published to external-facing Microsoft Teams channels.
Require admin approval to publish to certain channels (the “agents can be developed in test channels by anyone, but require admin approval to go to production channels” pattern).
Apply tenant-wide policies — enforce minimum real-time-protection level, require Microsoft Entra Agent ID for all new agents, require Purview DSPM compliance before publish.

Why agent governance is harder than user governance

Traditional identity governance assumes the principal is a human — they sign in, you log who they are, you review their group memberships. Agents are different:

The agent’s actions are taken on behalf of the invoking user, but the agent’s instructions and knowledge sources were configured by the creator. Two principals, one action.
The agent’s “reach” is the intersection of its creator-configured knowledge sources AND the invoking user’s permissions on those sources. Hard to reason about across thousands of users.
The agent’s behaviour can drift — the creator updates the instructions on Friday, and Monday’s interactions behave differently than Thursday’s.
The agent can be invoked by external users (when published to public channels), making the invoker even harder to identify.

This is why M365 agent management surfaces creator, owner, knowledge sources, channels, AND risk indicators as first-class fields — the questions you must answer are not just “who is this agent?” but “what does it read, who can invoke it, who owns it, and what’s the worst it could do?”

Where this fits with the rest of AI security

This module sits between the previous one (DSPM for AI as the discovery surface) and the next two (Entra Agent ID as the identity surface; Defender for AI Service + Foundry AI Gateway as the runtime detection + access control surface).

A clean way to remember the four AI-security modules together:

The four AI security modules in SC-500 — different surfaces, complementary roles
Module	Layer	Primary surface
AI security foundations + DSPM for AI	Discovery + posture	Microsoft Purview portal — DSPM for AI
Copilot Studio runtime + M365 admin	Per-agent runtime + tenant lifecycle	Copilot Studio + Microsoft 365 admin center
Entra Agent ID + Defender XDR	Identity + access control + blast radius	Microsoft Entra + Defender XDR
Foundry + Defender for AI + AI Gateway	Foundry workload protection + traffic control	Microsoft Foundry + Defender for Cloud + Azure API Management

Scenario: Ravi tames agent sprawl at Maple Genomics

Six months after Maple Genomics rolled out Microsoft Copilot, business teams have authored 73 Copilot Studio agents. Ravi opens the Microsoft 365 admin center > Agents view and finds:

73 agents, of which:
- 41 are published to internal Teams channels only
- 19 are published to a public web chat (some externally)
- 13 have a creator who has left the company (no current owner)
- 7 have real-time protection disabled
- 4 read from sensitivity-labelled “Patient Data” sites

Ravi’s remediation:

Disable orphaned agents. Set a tenant policy: agents with no current owner are auto-disabled after 30 days unless transferred. Manually transfer ownership of any high-value orphans to the originating business team’s manager.
Enforce minimum real-time protection. Tenant policy: all agents must have real-time protection at medium or higher; existing 7 disabled-protection agents get auto-upgraded with notification to owners.
Block “Patient Data” sources from agents not approved by the security team. Configure the 4 agents reading patient data: validate the use case, ensure DLP for AI policy on the agent, document the approval.
Require admin approval for public-channel publishing. Tenant policy: publishing to a non-internal Teams channel requires admin approval. The 19 public-web-chat agents go through retrospective review; 5 are revoked, 14 are approved with conditions.
Schedule a quarterly agent inventory review. Cross-reference Microsoft 365 admin Agents view with Purview DSPM for AI findings; agents flagged by DSPM as touching sensitive content get a deeper review.

The 73 agents become 64, all with named owners, real-time protection on, audited Patient Data access, and reviewed external exposure.