Control 2.13: Plugin and Graph Connector Security Governance

Control ID: 2.13 Pillar: Security & Protection Regulatory Reference: GLBA §501(b), FFIEC Last Verified: 2026-08-09 Governance Levels: Baseline / Recommended / Regulated

Scope boundary: FSI-CopilotGov vs FSI-AgentGov

This control governs the Microsoft 365 Copilot surface only — tenant-level configuration, data-source posture, audit/eDiscovery, and admin-managed extensibility. Governance of the agents themselves (Copilot Studio agents, declarative agents, Agent Builder, custom pro-code agents) — including agent registration, risk tiering, environment zoning, model-card review, and lifecycle promotion — lives in the companion FSI-AgentGov framework. See Relationship to FSI-AgentGov for the full boundary map.

Objective

Establish a security governance framework for Microsoft 365 Copilot plugins (used as actions within declarative agents) and Microsoft 365 Copilot connectors. Synced connectors ingest external data into Microsoft Graph for Copilot grounding; federated connectors retrieve external data at query time through Model Context Protocol (MCP) without indexing it in Microsoft Graph. Plugins and connectors expand Copilot's reach beyond native M365 data, introducing calls to external services, authentication and consent flows, and external data access that must be governed through security review, approval workflows, and ongoing monitoring. This control supports compliance with GLBA safeguard requirements and FFIEC expectations for third-party risk management.

Why This Matters for FSI

GLBA §501(b) requires safeguards for customer information systems — plugins and connectors introduce third-party processing of data that flows through Copilot, expanding the safeguard boundary
FFIEC IT Examination Handbook (Outsourcing) expects due diligence and ongoing monitoring of third-party service providers — plugin publishers and connector data sources are third-party processors requiring risk assessment
FFIEC IT Examination Handbook (Information Security) expects controls over API access and OAuth permissions — plugins can use Microsoft Entra SSO or OAuth 2.0, and excessive permissions create security risk
OCC Bulletin 2023-17 (Third-Party Risk Management) requires risk management throughout the third-party relationship lifecycle — applies to plugin publishers and Copilot connector vendors
SEC guidance on outsourcing expects firms to maintain supervisory responsibility for outsourced functions — plugins that perform actions on behalf of users require supervisory controls
Interagency AI Guidance (2023) expects institutions to understand and manage risks from AI tool extensibility, including third-party integrations

Control Description

Microsoft 365 Copilot can be extended through agents that use plugins as actions and through Copilot connectors that supply external knowledge. Microsoft documents plugins as actions within declarative agents; they are not enabled directly in Microsoft 365 Copilot.

Plugin and Connector Types and Security Implications

Type	Description	Data Flow	Security Concern
MCP plugins	Declarative-agent actions that discover or invoke tools on a remote MCP server	Agent → MCP server → tool response	Tool definitions and data leave the agent boundary
API plugins	Declarative-agent actions backed by a REST API and OpenAPI description	Agent → API endpoint → response	API may process sensitive data or perform write actions
Copilot Studio actions	Actions configured in Copilot Studio and selected by the agent orchestrator	Agent → Power Platform action → response	Power Platform governance applies
Message extension plugins	Message-extension-based actions described through the app manifest	Agent → message extension service → response	Service may receive parameters derived from the user's request
Synced Copilot connectors	Connectors that ingest and index external content in Microsoft Graph	External source → Microsoft Graph → Copilot	Incorrect connector ACLs can overshare indexed content
Federated Copilot connectors	MCP-based connectors that retrieve external content in real time without Microsoft Graph indexing	Copilot → MCP server → source response	Query-time external access, authentication, and egress require review

Synced Copilot Connector Data Flow

External Data Source              Microsoft 365              Copilot
┌──────────────┐                ┌─────────────────┐
│ ServiceNow   │  Synced        │ Microsoft Graph  │
│ Salesforce   │  Copilot       │ index            │
│ SAP          │ ─────────────→ │                  │ ──→ Copilot grounds
│ Jira         │  connector     │ Indexed external │     responses on
│ Custom DB    │  ingestion     │ content          │     external data
└──────────────┘                └─────────────────┘

Federated connectors are not represented in this diagram: they retrieve data from an MCP server at query time and do not index content in Microsoft Graph.

Where authentication is required, Microsoft 365 Copilot obtains plugin credentials on behalf of the signed-in user. The supported authentication scheme depends on whether the plugin wraps an MCP server or an API.

Mechanism	Applies To	Verified Behavior	FSI Governance
Microsoft Entra SSO	MCP and API plugins	Uses Microsoft Entra authentication on behalf of the signed-in user	Require least-privilege delegated scopes and admin consent where policy requires it
OAuth 2.0 authorization code	MCP and API plugins	Prompts the user to sign in to the protected service	Preapprove the client and scopes; do not rely on unrestricted user consent
Dynamic client registration	MCP plugins only	Registers an OAuth client with the MCP server at runtime	Review the server, identity provider, redirect flow, and requested scopes
API key	API plugins only	Retrieves a configured key from the Microsoft Enterprise token store	Treat the key as a privileged secret and rotate it under policy
Anonymous	MCP and API plugins	Calls the service without an authentication credential	Block unless the service and exposed data are explicitly approved
Microsoft Graph application permissions	Custom synced Copilot connectors	Connector deployment requires an app registration and admin consent for required Graph permissions	Require admin consent and a least-privilege security review

Plugin Approval Workflow

Plugin Request
      │
      ▼
┌──────────────────┐
│ Security Review   │
│                  │
│ ├─ Publisher      │
│ │  reputation     │
│ ├─ Permissions    │
│ │  requested      │
│ ├─ Data flow      │
│ │  analysis       │
│ ├─ SOC 2/ISO     │
│ │  certification  │
│ └─ Privacy        │
│    assessment     │
└────────┬─────────┘
         │
    ┌────┴────┐
    │         │
  Approve   Reject
    │         │
  Deploy    Document
  + Monitor  rationale

Plugin Security Assessment Criteria

Criterion	Assessment Questions	Weight
Publisher trust	Is the publisher Microsoft-verified? SOC 2 certified? Known in FSI?	High
Permission scope	What permissions are requested? Are they least-privilege?	Critical
Data handling	Where is data processed? Is data stored? What retention?	Critical
Authentication	Does the plugin use Entra SSO, OAuth 2.0, dynamic client registration, an API key, or anonymous access?	High
Encryption	Is data encrypted in transit and at rest?	High
Compliance	Does the publisher have FSI-relevant compliance certifications?	Medium
Update cadence	How frequently is the plugin updated? Security patching?	Medium
Exit strategy	Can the plugin be removed cleanly? What happens to data?	Medium

Copilot Surface Coverage

Surface	Verified Behavior	Governance Implication
Microsoft 365 Copilot declarative agents	MCP and API plugins are supported as actions within declarative agents; plugins are not enabled directly in the base Microsoft 365 Copilot experience	Approve the agent, its packaged actions, and its declared host channels together
Agent host channels	An agent request can declare channels such as Copilot, Teams, Outlook, Office, Word, Excel, or PowerPoint; availability depends on the individual agent package and deployment	Verify each agent's declared channels rather than applying a blanket app-support assumption
Synced Copilot connectors	Indexed external content can power Microsoft 365 Copilot, Microsoft Search, Copilot in Excel, and Researcher	Verify source ACL mapping, schema, and staged rollout before broad deployment
Federated Copilot connectors	External content is retrieved in real time through MCP and is not indexed in Microsoft Graph	Apply the query-time controls in Control 2.16
Microsoft Scout (Frontier preview)	Scout can connect to MCP servers; automation instructions and MCP output are stored on the local endpoint and are outside the Microsoft 365 DPA	Apply Scout-specific review of the data path, authentication, and external egress under Control 4.16

Governance Levels

Level	Requirement	Rationale
Baseline	Disable all third-party plugins for Copilot; restrict to Microsoft first-party plugins only; block user consent for OAuth apps; do not deploy external Copilot connectors; document the restriction rationale	Maximum restriction during initial Copilot deployment — eliminates third-party extensibility risk entirely
Recommended	Enable Microsoft first-party plugins; create a plugin approval workflow requiring security review; allow approved synced Copilot connectors with admin consent only; implement OAuth app governance via Entra ID; quarterly review of approved plugins; monitor plugin usage via audit logs	Controlled extensibility with formal approval process — suitable for firms that need selected third-party integrations
Regulated	All Recommended requirements plus: full third-party risk assessment for each plugin publisher; annual plugin security re-assessment; Copilot connector data classification and documented label handling; agent and tool policy controls supported by the licensed platform; monitoring of documented plugin and tool telemetry; plugin governance committee with compliance representation; plugin inventory included in examination packages	Comprehensive extensibility governance — designed for firms where every third-party integration requires formal risk management

Setup & Configuration

Step 1: Govern Agents via the Microsoft 365 Admin Center

Portal: Microsoft 365 Admin Center > Agents > All agents > Registry

Microsoft Agent 365 is the centralized control plane for AI agents. In the Microsoft 365 Admin Center, the Agent Registry governs agents, Agent Tools governs plugins, skills, and MCP servers, and Copilot > Connectors governs Copilot connector connections. Basic registry and agent governance actions are included in eligible Microsoft 365 plans; policy templates, advanced observability, and tenant-wide tool controls require Microsoft 365 E7 or Microsoft Agent 365.

Review the Registry categories: Microsoft agents, External partner-built agents, Published by your org, and Shared by creator. Review Frontier experiences separately where enabled.
Confirm each broadly available agent has an owner and a documented approval record; block, uninstall, or delete agents that do not meet policy, using the action supported for that agent type.
Under Agents > Settings:
- Allowed agent types — for Baseline, restrict to Microsoft and organization-published agents only; disable external publishers until vendor risk assessment is complete.
- Sharing — restrict broad sharing to a designated governance group (sharing controls apply only to agents built with Microsoft 365 Copilot Agent Builder).
- User access — scope which users or groups can access and install agents across the organization; manage individual agent distribution from the Registry.
- Policy templates and Agent management rules — apply preset policies and bulk lifecycle actions (for example, reassign ownerless agents built with Microsoft 365 Copilot Agent Builder to the previous owner's manager).
Review plugins, skills, and MCP servers under Agents > Tools, and review Copilot connectors separately under Copilot > Connectors.

Portal: Microsoft Entra Admin Center > Identity > Applications > Enterprise apps > Consent and permissions > User consent settings

Set user consent to "Do not allow user consent" for enterprise applications
Enable admin consent workflow
Configure admin consent request notifications to security team
For agents that are assigned an Entra Agent ID, govern the agent's permission grants the same way you govern any enterprise application — admin consent only, least-privilege scopes, and periodic access review.
Review and revoke existing grants separately; changing user consent settings affects future consent operations only.

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

# Remove self-consent policies while preserving any owned-resource policies
$authorizationPolicy = Get-MgPolicyAuthorizationPolicy
$preservedPolicies = @(
  $authorizationPolicy.DefaultUserRolePermissions.PermissionGrantPoliciesAssigned |
    Where-Object { $_ -like "managePermissionGrantsForOwnedResource.*" }
)
$params = @{
  defaultUserRolePermissions = @{
    permissionGrantPoliciesAssigned = $preservedPolicies
  }
}
Update-MgPolicyAuthorizationPolicy -BodyParameter $params

# Enable admin consent workflow
# Portal: Entra Admin Center > Identity > Applications > Enterprise apps
#         > Consent and permissions > Admin consent settings

Step 3: Govern Plugin, Skill, and MCP Tool Availability

Portal: Microsoft 365 Admin Center > Agents > Tools

The Tools page provides a centralized inventory of plugins, skills, Power Platform connector usage, and MCP servers. Tenant-wide tool controls require Microsoft 365 E7 or Microsoft Agent 365.

In Tools > Registry, filter by Status and Publisher, and inspect the Type column to identify available MCP servers and other tools.
In Tools > Plugins, block non-Microsoft plugins for Baseline. For approved plugins or skills, use the install flow to scope access to all users or specific users and groups.
For Recommended/Regulated, review Tools > Requests for pending bring-your-own MCP server registrations. Approve or Reject each request and record the rationale; approval also requires consent to the Microsoft Entra permissions requested by the server.
Treat bring-your-own MCP server registration as preview. The documented supported clients are Copilot Studio, Visual Studio Code, Claude Code, and GitHub Copilot CLI; Microsoft 365 declarative agents are not currently supported by this Agent 365 registration path.
Where licensed, monitor approved MCP server invocations through Microsoft Defender advanced hunting. Do not treat Registry approval alone as evidence that every client or agent channel can invoke the server.

Step 4: Configure Copilot Connector Governance

Portal: Microsoft 365 Admin Center > Copilot > Connectors

Review Your Connections and proposed connector deployments
Require security review before connector deployment
In Custom setup, configure source ACL mapping, staged rollout, schema properties, and sync settings
Assign connector semantic labels to schema properties for retrieval and display; do not treat semantic labels as Microsoft Purview sensitivity labels
Document connector-specific sensitivity-label handling as a separate verification item. If access permissions are wrong after creation, delete and recreate the connection because in-place permission updates are not currently supported.

Step 5: Implement Plugin Approval Workflow

Create a formal plugin approval process:

Step	Owner	Deliverable
1. Business request	Requesting department	Business justification document
2. Security review	Information Security	Security assessment report
3. Privacy review	Privacy/Legal	Privacy impact assessment
4. Compliance review	Compliance	Regulatory risk assessment
5. Architecture review	IT Architecture	Integration architecture review
6. Approval decision	Plugin governance committee	Approval/denial with rationale
7. Deployment	IT Operations	Controlled deployment with monitoring
8. Ongoing monitoring	Information Security	Quarterly usage and security review

Step 6: Collect Workload-Scoped Plugin Usage Evidence

Treat configuration state and usage telemetry as separate evidence. Verify enabled and blocked tools through Agents > Tools, the Agent Registry, and the corresponding approval record. For usage telemetry, connect with the Exchange Online Management module and run Script 4 in the PowerShell playbook. The script pages each time segment with a stable SessionId and SessionCommand ReturnLargeSet, deduplicates by audit record ID, and stops if the Exchange Online 50,000-record session limit prevents a defensible completeness claim. Reduce the segment duration when that guard is reached. Organizations with high-volume recurring ingestion should use the Office 365 Management Activity API.

Review OAuth consent policy and existing grants separately through Microsoft Entra. If consent-event audit records are retained as evidence, retrieve them with the same documented paging and time-segmentation pattern rather than a single ResultSize 5000 call.

EnablePlugin is intentionally excluded. Microsoft's audit activity catalog lists that same operation under both Microsoft 365 Copilot admin activities and Microsoft Security Copilot platform management, so an operation-only search cannot prove which product supplied the event. Microsoft also documents that CopilotInteraction covers Microsoft 365 Copilot, Security Copilot, and other Microsoft-developed Copilots, while their audit records share the Copilot workload. Microsoft's example scenarios distinguish Microsoft Copilot (Copilot.MicrosoftCopilot.BizChat) from Security Copilot (Copilot.Security.SecurityCopilot). Follow Microsoft's guidance to export the interaction records and filter AppIdentity offline, then accept plugin evidence only when both the exact AppIdentity and CopilotEventData.AISystemPlugin.ID match the approved inventory.

The candidate export is not Microsoft 365 Copilot evidence until that filtering is complete. Script 4 fails closed, explicitly rejects Copilot.Security.*, and retains unknown applications or plugin IDs in a separate rejected set.

Financial Sector Considerations

Third-Party Risk Management: Financial regulators (OCC, FFIEC) have specific expectations for third-party risk management. Each plugin publisher and Copilot connector vendor should be assessed using the firm's third-party risk management framework. This includes due diligence, contract review, ongoing monitoring, and exit planning.
Data Residency for Plugins: Plugins may process data outside the firm's M365 tenant geography. Assess whether plugin data processing locations comply with the firm's data residency requirements (see Control 2.7).
Sensitive Data Exposure: Before a plugin sends data for the first time, Copilot prompts the user to allow the transfer. The remote MCP server or API receives the parameters and other data that the agent sends for the selected operation, which may include sensitive business context or customer information. Document and assess the actual request schema and data flow for each plugin rather than assuming the entire prompt—or only the literal prompt—is transmitted.
Copilot Connector Data Classification: Data ingested through synced Copilot connectors can become available to Copilot for grounding according to the connector's ACL or tenant-wide visibility setting. Classify the source data and document sensitivity-label handling. Connector semantic labels are retrieval metadata and are not a substitute for Microsoft Purview sensitivity labels.
SOC 2 Requirements: For Recommended and Regulated governance levels, require SOC 2 Type II reports from plugin publishers. This provides assurance about the publisher's security controls, availability, and data handling practices.
Regulatory Notification: Some regulatory frameworks require notification when new third-party services are engaged for processing customer data. Evaluate whether plugin deployment triggers notification requirements.
Plugin Inventory for Examinations: Maintain a current inventory of all deployed plugins and Copilot connectors, including publisher information, permissions granted, data flows, and last security review date. Examiners may request this during IT examinations.

Verification Criteria

Third-Party Plugin Status: Verify that third-party plugins are disabled (Baseline) or restricted to approved plugins only (Recommended/Regulated)
User Consent Blocked: Confirm that users cannot consent to OAuth applications — attempt user consent and verify it is blocked
Admin Consent Workflow: Verify that admin consent requests are routed to the security team and that a documented review process exists
Plugin Inventory: Confirm a current inventory of deployed plugins exists with publisher, permissions, and last review date
Copilot Connector Governance: Verify that Copilot connector deployment requires admin approval and that ingested data is classified
Plugin Approval Workflow: Confirm a documented plugin approval workflow exists with security, privacy, and compliance review steps
Permission Scoping: For approved plugins, verify that granted permissions follow the principle of least privilege
Plugin Usage Monitoring: Verify that audit evidence is limited to approved AppIdentity and AISystemPlugin.ID values and excludes Security Copilot or other unrelated Copilot applications
Third-Party Risk Assessment: Confirm that plugin publishers have been assessed under the firm's third-party risk management framework
Periodic Review: Confirm that approved plugins are re-assessed at least annually (Recommended) or quarterly (Regulated)