14.1 Microsoft Security Copilot Workspaces and Roles

14.1 Microsoft Security Copilot Workspaces and Roles

Microsoft Security Copilot is a generative AI-powered security solution that helps defenders investigate incidents, hunt threats, summarize posture, and produce stakeholder-ready narratives at machine speed. On SC-500 it sits under Manage and monitor security posture (20–25%) alongside Defender for Cloud and Microsoft Sentinel. Blueprint tasks are concrete: configure workspaces, manage permissions and roles, enable plugins, and enable Microsoft and Security Store agents. This section focuses on workspaces, roles, capacity concepts, admin setup, and how Copilot integrates with the Microsoft security stack.

What Security Copilot is (and is not)

Security Copilot is not a replacement for Defender for Cloud recommendations, Sentinel analytics, or Entra Conditional Access. It is an assistive and agentic layer that:

• Accepts natural-language prompts and structured agent workflows.
• Grounds responses using plugins that pull organization-specific signals (incidents, alerts, logs, policies) and authoritative Microsoft threat intelligence.
• Returns post-processed answers you must still review—especially before taking high-impact actions.

Microsoft documents both a standalone experience (the Security Copilot portal) and embedded experiences inside products such as Microsoft Defender XDR, Microsoft Sentinel, Microsoft Intune, and Microsoft Entra. SC-500 scenario items may mention either path; the underlying ideas—capacity, roles, plugins, and least privilege—stay the same.

Admin setup and onboarding paths

Before analysts use Copilot, an administrator must ensure the tenant is onboarded and has capacity. Microsoft’s guidance splits customers into two categories:

1) Microsoft 365 E5 and E7 inclusion customers

For eligible Microsoft 365 E5/E7 customers, Security Copilot can be included and auto-provisioned when Microsoft enables the benefit in the tenant. Eligibility alone is not enough—rollout/enablement must complete. Inclusion capacity is modeled as Default Security Copilot Capacity shared across the tenant. Microsoft documents an inclusion model of roughly 400 SCUs per month for every 1,000 paid user licenses, scaling with license count, up to a published monthly cap (Microsoft has documented an upper bound on the order of 10,000 SCUs/month for this inclusion model). Treat those numbers as licensing capacity concepts for exam reasoning, not as a fixed price sheet—always re-check current Microsoft Learn if your job depends on procurement.

2) Non–E5/E7 customers (manual SCU provisioning)

If Security Copilot is not included, admins provision Security Compute Units (SCUs) before the service is usable. Microsoft documents two practical paths:

• Provision capacity through Security Copilot (recommended guided flow): choose Azure subscription, resource group, capacity name, prompt evaluation location, provisioned SCUs, and optional overage.
• Provision capacity in Azure, then complete attachment/setup in the Security Copilot portal.

Minimum published requirement: at least one provisioned SCU is required to activate capacity and enable at least one workspace. Billing behavior for provisioned capacity is capacity-based (provisioned SCUs are billed as capacity is provisioned; overage is consumed as used). Do not invent per-SCU retail prices on the exam—Microsoft’s commercial rate cards change, and SC-500 tests concepts, not memorized invoice line items.

Roles needed to attach capacity

To attach SCU capacity to a Security Copilot workspace, Microsoft documents the need for:

• Azure Contributor or Owner on the subscription/resource group that hosts capacity, and
• Security Administrator or higher in the tenant being onboarded.

Whoever completes initial default environment setup is designated among default owners (and related Entra/service roles they hold may also surface as owners).

Security Compute Units (SCUs) — high-level model

SCUs are the compute capacity units that power Security Copilot workloads: standalone chat, embedded experiences, Microsoft-built agents, partner agents, and other Copilot features.

You monitor usage with in-product dashboards and adjust provisioned/overage settings as SOC load grows. Capacity calculators exist in product guidance to estimate needs—useful operationally, rarely a memorization target for SC-500.

Workspaces: segmenting the Copilot environment

Workspaces let organizations segment Security Copilot environments by team, region, or business unit. Microsoft’s workspace model highlights:

• Role-based access scoped to the workspace.
• Localized prompt history (sessions stay in the right operational boundary).
• Independent capacity planning (align SCUs with how each group works).
• Workspace-level plugin management so owners configure plugins once for a workspace rather than forcing every user to reinvent settings.

Planning a workspace deployment

Think like an engineer designing multi-tenant SOC operations inside one company:

1. Who needs isolation? Separate SOC, identity/IT, and compliance teams if prompt history or plugin blast radius must not mix.
2. Where may data and evaluation run? Select locations consistent with residency and compliance needs documented during capacity setup.
3. How much capacity? Start from expected concurrent investigations and agent usage; enable overage carefully so spikes do not surprise finance—or leave analysts blocked with zero headroom.
4. Who owns vs uses? Map Owners (configure) and Contributors (operate) before go-live.
5. Which agents bind where? Integrated agents are assigned to workspaces so automation runs in the intended boundary.

Exam scenario pattern: “Contoso wants EMEA SOC prompts and plugins isolated from APAC with separate capacity tracking.” Answer points to workspaces, not a new Azure AD tenant for every region.

Security Copilot roles: Owner and Contributor

Security Copilot defines two platform roles. Critical exam distinction:

Security Copilot roles are not Microsoft Entra roles. They control platform capabilities (settings, sessions, admin tasks) and do not by themselves grant access to Sentinel incidents, Defender alerts, Intune devices, or Purview data.

Microsoft enforces that at least two owners remain so organizations cannot accidentally lock themselves out of ownership.

Entra / service roles that inherit Owner access

Certain highly privileged Microsoft Entra and related roles automatically inherit Copilot owner access to keep the platform administrable. Microsoft documents inheritance for roles such as:

• Global Administrator, Security Administrator, Billing Administrator
• Intune Administrator, Entra Compliance Administrator
• Selected Microsoft Purview management roles (for example Compliance Administrator / Organization Management family as documented)

Least-privilege warning (exam + real life): Do not assign Global Administrator or Security Administrator only to give someone Copilot access. Prefer a security group added to the Copilot Owner or Contributor role, and keep Entra privileged roles for true admin duties.

Contributor access patterns

For contributors, Microsoft recommends the Recommended Microsoft Security roles bundle: users who already hold security-related Entra permissions get balanced contributor access. Alternatives include carefully managed custom group assignments. An Everyone default may exist on older tenants for simplified onboarding, but it is a weak long-term pattern—users without any security data roles get a confusing empty experience, and least privilege suffers.

Layered permissions: the three-layer model

Memorize this stack—it shows up in scenario items:

1. Security Copilot RBAC — May the user enter the platform and perform Owner vs Contributor actions?
2. Microsoft Entra / Azure / product RBAC — May the user’s token actually read the data a plugin needs?
3. Licenses and product enablement — Is Defender, Sentinel, Intune, or the third-party product licensed and connected?

Copilot uses on-behalf-of authentication for Microsoft plugins. It does not elevate the user. Example:

• Analyst has Copilot contributor → can open sessions.
• Without Microsoft Sentinel Reader (or equivalent) → Sentinel plugin cannot surface workspace incidents.
• Without an appropriate Intune role → Intune plugin cannot describe device posture.
• Without Defender XDR permissions → Defender-focused prompts fail or return incomplete context.

Exam trap: “Assign Security Copilot contributor so the analyst can query Sentinel.” Incomplete—you still need Sentinel data permissions (and a connected workspace/plugin).

Integrating with Microsoft security products (overview)

Security Copilot’s value on SC-500 is that it stitches the same products you secured in earlier chapters:

For multi-tenant or MSSP scenarios, Microsoft documents partner access patterns (Azure Lighthouse, GDAP, B2B guest). Capacity billing (whose SCUs are consumed) depends on the access method—know that Lighthouse-style delegated Sentinel access can consume partner capacity in documented cases, while guest/GDAP-style access typically consumes customer capacity. Details are operational; the exam point is that partner access is deliberate and model-specific, not “share one Copilot tenant magic switch.”

Conditional Access and protecting the AI surface

After RBAC is correct, Microsoft recommends protecting the Copilot platform with Conditional Access policies appropriate for AI security access (strong authentication, compliant devices, risk-based controls). Treat Security Copilot like any other high-value security console: phishing-resistant MFA, device compliance where required, and restricted break-glass paths.

Scenario: first-week admin checklist

1. Confirm customer category (E5/E7 inclusion vs provisioned SCUs).
2. Provision or verify capacity; set sensible overage limits.
3. Create/confirm workspace boundaries for teams that need isolation.
4. Assign Owners (admin groups) and Contributors (analyst groups)—avoid Everyone long term.
5. Verify service roles so plugins can actually see data.
6. Apply Conditional Access to the Copilot access surface.
7. Pilot with a small analyst group before org-wide enablement.

Bottom line

For SC-500, Microsoft Security Copilot is the AI investigation and automation layer for security operations. You must know how to onboard capacity (SCUs), configure workspaces, assign Owner vs Contributor platform roles, and explain the three-layer permission model (Copilot role + Entra/Azure/product RBAC + licenses). Copilot integrates across Defender, Sentinel, Entra, Intune, and Purview, but it never silently grants more access than the signed-in user already has.