14.2 Plugins and Security Agents

14.2 Plugins and Security Agents

After workspaces and roles exist, the exam turns to extensibility: plugins and agents. Plugins supply the skills and data connections that make answers relevant. Agents package multi-step, often scheduled or event-driven workflows so SOC teams spend less time on repetitive triage and more time on decisions. Microsoft’s SC-500 outline explicitly measures enable and configure plugins and enable and configure Microsoft agents and Security Store agents.

Plugins: the building blocks of grounded answers

A plugin is a collection of related tools (also called skills)—resources outside the base language model that Security Copilot can invoke. Examples include querying Defender incidents, reading Sentinel workspace data, checking Intune device state, looking up threat intelligence, or calling a partner reputation API.

Why plugins matter

Without plugins, Copilot can only reason generically. With plugins, preprocessing (grounding) and post-processing pull tenant-specific context so responses map to your alerts, assets, and policies. Products that integrate as plugins are typically licensed separately; enabling a plugin does not replace buying Defender, Sentinel, or a third-party product.

Enabling and configuring plugins

In the standalone experience, users can open the plugin control and see which plugins are toggled on. Owners manage organizational policy on the plugin settings page:

• Which preinstalled plugins are available broadly versus restricted.
• Whether contributors may add custom plugins for their own sessions.
• Whether contributors may publish custom plugins for everyone in the organization/workspace.
• Default: often owners only for adding and managing custom plugins until policy is relaxed intentionally.

Plugins added by owners can be scoped to themselves or to the organization. Org-available plugins can be toggled by users, but only owners modify the plugin definition itself.

Workspace-level plugin management (generally available in Microsoft’s workspace model) lets admins set plugin configuration once per workspace, which is far more scalable than per-user setup in large SOCs.

Exam scenario: when to enable a plugin

Enable a plugin when:

1. The investigation needs that product’s data (for example, turn on/configure Sentinel plugin before expecting KQL-backed incident answers from a workspace).
2. Users have product RBAC so on-behalf-of calls succeed.
3. The owner has decided the plugin is approved for the workspace (compliance, data residency, and partner risk).

Do not enable every plugin “because AI is better with more data.” Extra plugins expand blast radius, SCU usage, and accidental data exposure in prompts. Prefer a minimum necessary plugin set for each workspace’s mission.

Classic trap: Analysts complain Copilot “doesn’t know Intune.” Root cause is often plugin off, missing Intune role, or workspace policy—not a broken model.

Agents: automating SOC and security engineering work

Microsoft Security Copilot agents automate high-volume, time-consuming tasks across security and IT operations. They combine instructions, triggers, permissions, identity, and plugins so teams can scale without hiring linearly with alert volume.

Agent terminology you should recognize

Identity options for agents

When setting up Microsoft-built agents, Microsoft documents two identity patterns:

1. Create an agent identity (Microsoft Entra Agent ID) — Recommended. Dedicated non-human identity for the agent with scoped permissions. Aligns with SC-500’s broader Entra Agent ID story under Secure compute / Security for AI.
2. Connect with an existing user account — Agent runs with that user’s access. Simpler, but couples automation to a person and can over-privilege the agent if that user is highly privileged.

Exam preference: When a scenario emphasizes least privilege, auditability, or “agent-specific identity,” choose Agent ID, not “run as Global Admin.”

Microsoft-built vs partner-built agents

Microsoft-built agents are set up from the Agents library in Security Copilot: select agent → Set up → choose identity → configure parameters → Run or enable trigger.

Partner-built agents that need Microsoft product skills/data often require Global Administrator approval of required permissions before Owners/Contributors finish configuration. Agents that do not need Microsoft product permissions can proceed without that consent step. Share the setup link with a GA when blocked by consent banners—this is a deliberate control, not a product defect.

Example SOC-oriented agent use cases

Microsoft and the Security Store ecosystem publish agents for tasks such as:

• Alert / phishing triage — Reduce queue time on repetitive alerts.
• Threat intelligence briefings — Scheduled synthesis for stakeholders.
• Threat hunting assistance — Structured hunting workflows.
• Conditional Access optimization style operational agents (as documented in agent catalogs).
• Defender-integrated agents for investigation, hunting, and triage inside the Defender portal experience.

Exact agent names and preview status change; exam items care about when to deploy an agent, how to identity-bind it, and how to govern it, not memorizing an entire catalog.

Microsoft Security Store

Security Store is Microsoft Security’s storefront to discover, try, buy, and deploy Microsoft and partner security solutions and agents. Inside Security Copilot’s standalone experience, users can open Security Store (or Browse more agents) without leaving the portal.

Purchase vs operate (critical separation)

Microsoft emphasizes two independent cost/control planes:

1. Security Store subscriptions / purchases — Managed in Security Store billing. Removing an agent from Security Copilot does not cancel the subscription by itself.
2. SCU consumption — Running agents and other Copilot features still consumes SCUs, billed under the capacity model independently of store subscription fees.

Dependent plugins after agent acquisition

After you acquire and set up an agent:

• It appears under Active agents.
• If the agent has a dependent plugin, that plugin may be enabled for the agent without fully configuring org-wide plugin settings the way a human would for interactive chat.
• You may still need to configure the plugin under Manage sources (connections, auth, parameters) before the agent succeeds.

Exam scenario: “Agent installed but fails until plugin configuration is completed.” Answer: finish plugin configuration, not “delete the workspace.”

Governance of agent actions

Agents are powerful; SC-500 expects human control, not unsupervised magic.

Agents learn from feedback within governance bounds, but you remain accountable for actions and for validating high-impact recommendations. Treat agent output like junior-analyst output: useful, fast, and still subject to review for production changes.

Integration with Security for AI themes

SC-500’s AI security domain (Purview DSPM for AI, Copilot Studio protection, Entra Agent ID, Defender for AI, Foundry guardrails) and Security Copilot agents share a theme: agents are identities and automation surfaces that must be governed. When an item mentions Agent ID for a Security Copilot agent, connect it to Conditional Access, least privilege, and blast-radius analysis concepts from earlier chapters—not only to “chatbots.”

Putting plugins and agents together: investigation workflow

1. Owner enables the Microsoft plugins needed for the SOC workspace (Defender, Sentinel, threat intel, etc.).
2. Contributors receive Copilot access and product RBAC.
3. Analysts use chat prompts for ad-hoc questions and agents for repeatable triage.
4. For specialized partner capabilities, browse Security Store, acquire the agent, complete consent if required, configure identity and dependent plugins, then pilot.
5. Monitor SCU usage as agent adoption grows; adjust capacity/overage.
6. Pause or reconfigure agents that produce noisy or incorrect actions; manage memory when feedback drifts quality.

Scenario comparison table

Bottom line

Plugins ground Security Copilot in real security data; agents industrialize repeatable work. Owners enable and govern plugins and agent availability; contributors operate within that policy. Use Security Store to discover Microsoft and partner agents, remember store billing ≠ SCU billing, finish dependent plugin configuration, prefer Agent ID identities, and keep run/pause/memory/feedback controls in active use. On the exam, choose the control that enables investigation without granting unbounded access or skipping consent for partner agents that touch Microsoft product data.