SC-500 Microsoft Security Copilot: Workspaces, Roles, Plugins and Agents

A Security Copilot workspace is a self-contained environment inside one tenant that has its own data storage location, its own capacity of Security Compute Units (SCUs), its own role assignments and its own plugin and owner settings. You give each workspace a name that must be unique in the tenant and can't be changed after it is created. Every session, promptbook run and agent run happens in a workspace, and the workspace decides where that data is stored, which compute pays for it and which tools Copilot can use.

Organizations create several workspaces when teams need different answers to those questions. Typical reasons are:

• Data residency: one team's prompts and responses must be stored in a different geography from the rest of the company.
• Cost separation: a SOC and a compliance team each get their own capacity, so one team's burst of usage can't exhaust the other's units.
• Different tool sets: a sandbox workspace can run experimental plugins that are never turned on in the production SOC workspace.
• Different administrators: each workspace can have its own Copilot owners.

Because workspaces are independent, nothing you configure in one appears in another. A plugin turned on and tested in a sandbox is still off in the SOC workspace until someone turns it on there (Manage plugins, or Sources in the prompt bar). Users switch between the workspaces they hold a role in from the standalone portal.

When you create a workspace you choose two separate geographic settings: the data storage location, which decides where session data rests, and the prompt evaluation location, which decides where prompts are processed. Compliance requirements often name one but not the other, so read which one the requirement actually covers.

Key consequences:

• Storage is immutable. If an existing workspace stores data in the US and one team now needs EU storage, you can't edit the location: you create a second workspace with EU storage for that team and leave the original one alone.
• Storage alone doesn't keep processing in-region. "Evaluate anywhere" routes prompts to the least-busy datacenter globally to improve responsiveness, so a policy that says data must stay in the EU both at rest and during processing needs EU storage and EU prompt evaluation.
• Evaluate anywhere is the right choice when speed matters and processing elsewhere is acceptable; the storage location still stays where you set it.

A capacity is the Azure resource that supplies Security Compute Units to a workspace, and each capacity serves exactly one workspace at a time. SCUs are not shared or pooled: spare units in a sandbox workspace can't help a busy SOC workspace, and you can't attach two capacities to one workspace or one capacity to two workspaces. If a new workspace needs compute, you create a new capacity for it (or disassociate an existing one, which leaves its previous workspace without compute).

When a workspace runs out of units in an hour, users are throttled and see errors that capacity is unavailable until the next billing hour. Raising provisioned units fixes this at a higher fixed cost; allowing (more) overage units absorbs bursts and is billed only when used.

Managing capacity needs Azure Owner or Contributor on the subscription or resource group plus the Copilot owner role (Security Administrator or higher in the tenant when you first provision). Owners monitor consumption, split into provisioned and overage units, on the usage dashboard in owner settings, which is a Copilot owner page inside Security Copilot.

Pausing a workspace: disassociate vs delete

Disassociating stops charges but doesn't stop people trying to use the workspace; to keep everyone out while it's paused, also remove the users' Copilot roles in that workspace.

Most owner settings, including roles, plugins, data sharing, file uploads and capacity, apply only to the workspace in which they are set; a few decisions are made once for the whole tenant. Knowing which is which tells you whether a workspace owner can make one workspace behave differently from another.

Copilot used inside other portals (Microsoft Defender, Microsoft Purview, Microsoft Intune, Microsoft Entra) and the Microsoft agents that run there are routed to a workspace by a tenant-wide assignment made per product; until you change it, the default is the oldest workspace. A user picking a workspace in the standalone portal only affects their standalone sessions. It doesn't move Copilot in Defender.

For example, if a SOC workspace was created first and a compliance team's workspace later, compliance analysts using Copilot in the Microsoft Purview portal consume the SOC workspace's units until an owner assigns the Purview product to the compliance workspace in owner settings.

Routing changes have two follow-on effects:

• Users need a role in the target workspace. Once a product is routed to a workspace, every user's embedded requests for that product land there, so each of them needs contributor (or owner) access in that workspace. Workspace access controls whether a request succeeds; only the product assignment decides where it goes.
• Agent setups don't move by themselves. An agent's configuration lives in a workspace. Before reassigning a product, turn off the agents' scheduled and automatic triggers so the old setup doesn't keep running (and duplicate work), then set the agents up again in the new workspace. Agent memory and feedback are not carried across.

Security Copilot has two roles of its own, Copilot owner and Copilot contributor, and neither is a Microsoft Entra role or grants any access to security data. They control what someone can do on the Copilot platform: owners administer the workspace, contributors use it.

Data access comes from on-behalf-of authentication: when Copilot calls a Microsoft plugin, it uses the signed-in user's own permissions in that service. Copilot never goes beyond the access the user already has, so each plugin needs its own service role:

A contributor whose prompts return nothing from Sentinel is missing a Sentinel role, not a Copilot role. Least privilege means granting the narrowest service role that covers what Copilot must read: for reading incidents, a reader role on the Sentinel workspace.

Shared sessions

The Copilot contributor role is the only requirement to share a session link or view one in the same tenant. The plugin access that produced a response is not re-evaluated when someone views the shared session, so a colleague without Intune access can read Intune results that a session creator shared with them. Shared sessions are read-only, contain all their prompts and responses, and forwarding a link doesn't grant access: only the session creator decides who can see it.

You assign Copilot roles in Security Copilot (Role assignment > Add members), and the default contributor assignment is the Recommended Microsoft Security roles bundle, which gives platform access to people who already hold security roles.

Rules that decide many scenarios:

• Remove Everyone before you add the recommended bundle. Removing Everyone is one-way.
• Only role-assignable groups are supported. Role-assignable groups in Entra ID use assigned membership, so a dynamic-membership group can't be used.
• Use security groups, not individuals, and not privileged Entra roles. Some Entra roles automatically inherit Copilot owner: Global Administrator, Security Administrator, Billing Administrator, Compliance Administrator and Intune Administrator, plus Purview roles such as Compliance Administrator and Organization Management. Don't hand out those privileged roles just for Copilot. Put the person in a security group that holds the Copilot owner or contributor role.
• Security Copilot always keeps at least two owners, so the last owners can't be removed by accident.
• Platform access can be layered with Conditional Access, but Conditional Access doesn't replace a correct role assignment.

Contributors can use everything a user needs (sessions, promptbooks, file uploads by default), while owners alone change settings that affect everyone in the workspace.

To stop file uploads without disrupting work, an owner sets who can upload files to no one; removing contributor roles would also stop sessions and promptbooks.

Plugins are the sources Copilot can use. Preinstalled Microsoft and partner plugins are controlled by an availability setting, and custom plugins by two owner permissions and an upload scope.

Preinstalled plugins

• Owners set each preinstalled plugin's availability to All users or Owners only. Restrictions also affect embedded experiences: restricting the Microsoft Defender XDR and Natural language to KQL plugins degrades Copilot in the Defender portal for contributors, who can't override an owner restriction. The fix is to make the plugins available to all users again.
• After an owner has restricted any preinstalled plugin, new preinstalled plugins that Microsoft adds later arrive as Owners only. An owner must set each new one to All users before contributors see it.
• Plugins with a gear or Set up button, such as Microsoft Sentinel (subscription, resource group, workspace name), are configured per user. An owner completing the setup doesn't configure it for analysts; each analyst enters the values for themselves, and still needs their own Sentinel role.

Custom plugins

• A custom plugin is uploaded either as a Security Copilot plugin (a YAML or JSON manifest file) or as an OpenAI plugin (a link to the plugin's published manifest).
• At upload you choose Just me (a private plugin, the way to vet a new plugin) or Anyone in my organization (available to everyone straight away).
• Custom plugins uploaded by owners can't be edited by contributors. Only an owner can fix a shared plugin's file, from its gear icon. A contributor's private copy fixes only their own sessions.
• Plugins are turned on per workspace (Manage plugins / Sources).

A custom plugin is a YAML or JSON manifest with a Descriptor (name, description, settings) and one or more SkillGroups, each with a Format that decides what its skills do.

KQL targets

A fixed hunting query with no Sentinel workspace is the simplest case: a KQL skill with the Defender target.

API plugins support OpenAPI 3.0 or 3.0.1 only. An API described in Swagger 2.0 must be converted to OpenAPI 3.0.x and hosted before an API skill group can reference it; the OpenAPI version limit applies to the spec the skill group references.

Security Copilot agents are autonomous or scheduled AI workflows: Microsoft builds some (they appear under Active agents and inside product portals) and partners publish others, which you buy in Microsoft Security Store. Setting one up means choosing its identity, granting that identity the access it needs, turning on the plugins it depends on and setting its triggers.

Choosing the agent's identity

An agent identity starts with no service access, so grant exactly what the agent reads. For example, the Threat Intelligence Briefing Agent's exposure data comes from Microsoft Defender for Endpoint, which scopes data both by role permissions (such as Vulnerability Management and Advanced Hunting read) and by device group. Missing either one leaves the exposure report unavailable or showing zero CVEs. A privileged Entra role is far broader than that read access.

Agents that ran as a user before agent identities existed failed whenever that user's privileged role was only eligible through Privileged Identity Management and not activated. The durable fix is to create an agent identity from the agent's identity and permissions settings, not to make the user's role permanent or activate it before every run.

Conditional Access Optimization Agent (Microsoft Entra)

• Security Administrator activates the agent the first time; Conditional Access Administrators review and apply its suggestions; reader roles can only view.
• By default it only suggests. It doesn't create policies. If you want it to set up new protections itself, turn on its capability to create policies, which it creates in report-only mode. An administrator switches each one on only after reviewing its impact. Changes to existing policies also wait for approval.
• Applied suggestions are ordinary Conditional Access policies: removing the agent removes its own data, and the policies stay in force.

Security Store (partner) agents

• Procurement is separate from operations. Partner agents are bought, and cancelled, in Security Store. Removing the agent in Security Copilot doesn't stop the partner's charge. SCUs the agent consumes are billed separately on your capacity.
• A partner agent that uses Microsoft product data (Sentinel, Defender and so on) needs a Global Administrator to approve its requested permissions. Until then, Set up is unavailable and a consent banner shows; the requester sends the link to a Global Administrator, then finishes the identity and trigger settings.
• Plugins the agent depends on are enabled but not configured when it's installed. Complete their settings (for example an API key) from Manage sources, or runs fail.