What it does

Plugins connect Security Copilot to data and tools; promptbooks package a fixed sequence of prompts into a repeatable workflow. Together with Logic Apps and custom code, they're how you extend Copilot beyond the built-in Microsoft sources.

Key facts

• A plugin is a set of tools (also called skills) Copilot can invoke. Built-in plugins connect to Microsoft's own services (Defender XDR, MDTI, Sentinel, Entra, Purview, Intune).
• Third-party plugins connect external tools — Splunk, ServiceNow, VirusTotal, GreyNoise, Red Canary and similar — so Copilot has visibility across a multi-vendor estate.
• Custom plugins are defined in a YAML manifest against a set schema; skill formats include KQL, API, GPT, LogicApp, and MCP, each with their own manifest shape and auth options.
• Model Context Protocol (MCP) is now a supported plugin type — you can wire MCP servers in as tools.
• Logic Apps integration works both ways: bring a Logic App workflow in as an invokable skill (outbound), and drive Copilot prompts/promptbooks from Logic Apps via the Security Copilot connector (inbound).
• Azure Functions is the documented pattern for triggering custom code as part of an investigation.
• Promptbooks are ordered prompt sequences that produce the same steps and output every run — Microsoft ships a library and you can author your own.
• Plugins can be scoped per-user or shared org-wide, and custom plugins carry their own auth (API keys, delegated, etc.) that you manage.

When to use / skip

Reach for a plugin when Copilot needs data or an action it can't get natively — your SIEM isn't Sentinel, your ticketing is ServiceNow, your enrichment is VirusTotal. Reach for a promptbook when a good investigation is really the same ten prompts every time; codify it so any analyst runs it consistently. Use Logic Apps/Functions when you need Copilot to actually do something in another system, not just read from it. Skip the custom-build effort if a built-in plugin or an existing promptbook already covers it — plenty of teams over-engineer here.

Configuration decisions

• Which third-party plugins to enable, and the auth/credentials each needs — this is a data-access decision, not just a toggle.
• Per-user vs org-published scope for each plugin and promptbook.
• Build custom plugins as KQL/API/GPT manifests, via Logic Apps, or via MCP — pick by what the target system exposes and who'll maintain it.
• Which investigations are worth turning into promptbooks (repeatable, high-value) versus left as ad-hoc prompting.
• Inbound vs outbound Logic Apps pattern — whether Copilot calls the workflow or the workflow calls Copilot.

Gotchas

• Custom plugin manifests are fiddly YAML against a strict schema — expect trial and error, and version them in source control.
• Third-party and custom plugins hand external systems into your security investigations; each one is a credential and a data-access path to govern.
• Plugin skills consume SCU capacity when invoked — a chatty custom plugin adds to the meter.
• Promptbooks are only as good as their prompts; a badly written one reliably produces the same mediocre output every time.
• Logic Apps and Functions add moving parts (auth, connectors, runtime) that live outside Copilot — when the workflow breaks, the Copilot side just looks like it "didn't work".

Consultant notes

• Promptbooks are the cheapest, highest-adoption win — standardise the client's top few investigations before you touch custom plugins.
• Position custom plugins/Logic Apps as the integration layer for non-Microsoft estates; that's where they justify the build cost.
• MCP support is worth flagging to clients already building agents — it lets them reuse MCP tools rather than write bespoke manifests.
• Keep a maintenance owner in mind for anything custom; manifests, connectors, and Functions rot, and an unowned plugin is a future incident.

---

Custom plugin manifest schemas change — pull the current schema from Microsoft Learn before hand-writing YAML, don't copy an old sample.