Manage and monitor security posture
Microsoft Security Copilot Operations
CoreOperate Security Copilot through governed workspaces, layered roles, controlled plugins, and explicitly configured Microsoft or Security Store agents.
Aligned to the live SC-500 guide, which publishes no skills-measured date; guide and product behavior verified September 23, 2026.
Why this matters
Security Copilot can reach sensitive security data and automate work through plugins and agents. Workspace boundaries, product permissions, agent identities, dependent plugins, and purchasing lifecycle must be governed separately.
Must Know
- Security Copilot workspaces isolate capacity, membership, settings, plugin availability, data controls, and integrated agent assignment according to current workspace behavior.
- Security Copilot roles govern platform actions, while Microsoft Entra roles and Azure RBAC still govern access to product data such as Sentinel incidents.
- Plugins extend prompts and agents with Microsoft or non-Microsoft capabilities; enabling a plugin does not grant the signed-in user data permissions they do not already have.
- Owner-level and workspace-level settings determine who can add or publish custom plugins and which preinstalled plugins are available.
- A Microsoft-built agent can use a dedicated agent identity or, where offered, an existing user account; least privilege favors a dedicated, scoped identity.
- Security Store discovery or purchase, tenant approval, Security Copilot agent setup, dependent-plugin configuration, run state, and subscription billing are distinct steps.
Compare and Distinguish
- Workspace role grants Security Copilot capability; source-product role grants access to the security data a plugin uses.
- A plugin gives Copilot a capability or data connection; an agent combines identity, trigger, permissions, plugins, and configuration to perform work.
- Removing an agent from Security Copilot does not necessarily end a separately managed Security Store subscription.
Scenario examples
- Scenario: A regional SOC requires separate capacity and membership. Think: configure a workspace with its own settings and assign only the intended analysts.
- Scenario: A user can open Security Copilot but cannot retrieve Sentinel incidents. Think: grant the appropriate Sentinel data role rather than broadening the Copilot platform role.
- Scenario: A partner agent is acquired but fails at setup. Think: complete required tenant approval, configure its identity and dependent plugins, then test under least privilege.
Exam traps
- Security Copilot RBAC is not the same as Microsoft Entra RBAC or Azure RBAC.
- A globally enabled plugin can still return no data when the user lacks permission in the source product.
- Acquiring an agent from Security Store does not finish its Security Copilot configuration.
- Connecting a broad user account as an agent identity can give the agent more access than its task requires.
Key takeaways
- Design workspace boundaries around capacity, data, membership, and operational ownership.
- Layer Copilot platform permission with least-privileged source-product access.
- Treat plugins and agents as governed integrations with identities and lifecycle.
How it works
- A workspace supplies governed Copilot capacity and configuration; a prompt uses enabled plugins under the caller or agent authorization context.
- Agents run with configured identity, trigger, plugins, permissions, and parameters and can be paused or edited independently.
Objects and administrative surfaces
- Security Copilot workspace capacity, geography, membership, owner settings, plugin scope, and usage monitoring.
- Security Copilot Owner and Contributor roles plus Microsoft Entra and Azure source-product authorization.
- Manage sources, agent library, Security Store, ready-for-setup and active agents, identities, triggers, run state, and memory.
When to use it
- Use separate workspaces when teams need distinct membership, settings, capacity, or residency boundaries.
- Use Security Store for supported partner agents and complete operational setup in Security Copilot.
Security and governance implications
- Limit Owner and broad source-product roles, review plugins and agents, and monitor capacity and activity.
- Prefer dedicated agent identities and require explicit approval for high-impact permissions or partner integrations.
Troubleshooting signals
- For missing plugin results, verify workspace availability, plugin state, authentication, caller or agent role, and source-product permission.
- For an agent that will not run, inspect approval, identity, dependent plugin configuration, required products, trigger, and pause state.
More detail
- Create workspaces with intended capacity, location, membership, and settings.
- Assign Security Copilot roles without bypassing product-data authorization.
- Control plugin availability and configuration at owner and workspace boundaries.
- Set up and manage Microsoft-built and Security Store agents with least-privileged identities.
Ready for the quiz?
- Why can a Copilot Contributor still be unable to query Sentinel?
- What is the security difference between enabling a plugin and granting source-product access?
- Which steps remain after a Security Store agent is acquired?
Related objectives
- D4.3.S1 — Configure workspaces for Security Copilot
- D4.3.S2 — Manage permissions and roles in Security Copilot
- D4.3.S3 — Enable and configure plugins
- D4.3.S4 — Enable and configure Microsoft agents and Security Store agents