Skip to content

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-05-25 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 (extending Copilot's capabilities with third-party actions) and Microsoft Graph connectors (ingesting external data into the Microsoft 365 index for Copilot grounding). Plugins and connectors expand Copilot's reach beyond native M365 data, introducing third-party code execution, OAuth consent flows, and external data ingestion 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 use OAuth for authentication, 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 Graph 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 two primary mechanisms:

Plugin Types and Security Implications

Plugin Type Description Data Flow Security Concern
Message extension plugins Teams message extensions used as Copilot plugins User query → plugin service → response Third-party sees user queries
API plugins Custom API-based plugins with OpenAPI spec User query → API endpoint → response API may process sensitive data
Copilot Studio plugins Plugins built in Copilot Studio User query → Power Platform → response Power Platform governance applies
Graph connector plugins Plugins that query Graph connector data User query → connector index → response External data ingested into search

Graph Connector Data Flow

External Data Source              Microsoft 365              Copilot
┌──────────────┐                ┌─────────────────┐
│ ServiceNow   │  Graph         │ Microsoft Graph  │
│ Salesforce   │  Connector     │ Index            │
│ SAP          │ ─────────────→ │                  │ ──→ Copilot grounds
│ Jira         │  (data         │ Indexed external │     responses on
│ Custom DB    │   ingestion)   │ content          │     Graph data
└──────────────┘                └─────────────────┘
Permission Type Description Risk Level FSI Governance
Delegated permissions Plugin acts on behalf of the signed-in user Medium User consent may be acceptable for low-risk plugins
Application permissions Plugin acts with its own identity High Admin consent only — never user consent for FSI
Graph connector permissions Connector ingests data into the Graph index High Admin consent + security review required
Overprivileged permissions Plugin requests more permissions than needed Critical Block — require least-privilege scoping

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 How does the plugin authenticate? OAuth 2.0? Certificate? 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

M365 Application Plugin Support Graph Connector OAuth Consent Notes
Microsoft 365 Copilot Chat Yes Yes Yes Primary extensibility surface
Word Limited Yes Yes Document-focused plugins
Excel Limited Yes Yes Data analysis plugins
PowerPoint Limited Yes Yes Presentation plugins
Outlook Yes Yes Yes Email/calendar plugins
Teams Yes Yes Yes Full plugin support in Teams
OneNote Limited Yes Yes Limited plugin support
Loop Limited Yes Yes Limited plugin support
Copilot Pages Yes Yes Yes Plugins available in Pages
SharePoint (Agents) Yes Yes Yes Agents can use plugins and connectors

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; disable Graph connectors from external sources; 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 Graph 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; Graph connector data classification and labeling; plugin-specific DLP policies; real-time monitoring of plugin API calls; 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 Plugins and Agents via the Agents Control Plane (Agent 365)

Portal: Microsoft 365 Admin Center > Agents

Microsoft Agent 365 is the centralized control plane for AI agents, plugins, and connectors across the Microsoft 365 ecosystem. The Agents node in the Microsoft 365 Admin Center is the primary surface for governing agent and plugin availability — Settings > Integrated apps remains as the legacy app inventory and user-request surface but is no longer the primary plugin governance flow.

  1. From the Agents node, review the agent and plugin inventory across the standard agent type categories: Published by your organization, Shared by creator, Microsoft agents, External partner agents, and Frontier agents (where licensed).
  2. On the All agents (Registry) view, confirm each broadly available agent or plugin has an owner and a documented approval record; block or remove any agent or plugin that does not meet policy.
  3. 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; this controls consumption, not creation (agent creation is gated by Copilot license, Microsoft 365 Copilot Agent Builder availability, and SharePoint agent permissions).
    • Security templates and Agent management rules — define preset policies and bulk lifecycle actions (for example, reassign ownerless agents built with Microsoft 365 Copilot Agent Builder to the previous owner's manager).
  4. Use Settings > Integrated apps only to maintain the legacy integrated-app inventory and to triage user requests for apps not yet in the agent catalog.

Portal: Microsoft Entra Admin Center > Applications > Consent and permissions

  1. Set user consent to "Do not allow user consent" for enterprise applications
  2. Enable admin consent workflow
  3. Configure admin consent request notifications to security team
  4. 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.
# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

# Disable user consent for applications
Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions @{
  PermissionGrantPoliciesAssigned = @()
}

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

Step 3: Govern Plugin and Tool Availability for Agents

Portal: Microsoft 365 Admin Center > Agents > Tools (where licensed)

The Tools page provides a centralized view of AI-powered tools and Model Context Protocol (MCP) servers available to agents in the tenant. Availability of this surface is rolling out to Frontier tenants and may not yet appear in every region; where it is available, it should be the primary surface for governing tool/plugin availability for agents.

  1. Review the Tools list filtered by Type (for example, MCP Server) and Publisher to identify tools that are currently Available to agents.
  2. For Baseline: Block all non-Microsoft tools and require an approval record before unblocking.
  3. For Recommended/Regulated: review the Requests tab for pending MCP server registrations and either Approve (which prompts for the Entra permission consent the server requires) or Reject the request, recording the rationale.
  4. Until the Tools surface is available in your tenant, continue to govern plugin availability through Agents > Settings and the legacy Settings > Integrated apps inventory, and document the interim governance approach.
  5. Configure which users or groups can use each approved plugin or tool via the Agents > Settings > User access scoping described in Step 1.

Step 4: Configure Graph Connector Governance

Portal: Microsoft 365 Admin Center > Settings > Search & intelligence > Connectors

  1. Review Graph connector deployment requests
  2. Require security review before connector deployment
  3. Configure connector data ingestion scope
  4. Apply sensitivity labels to connector-ingested content

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: Monitor Plugin Activity

# Search audit logs for plugin-related activities
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
  -Operations "AppConsented","CopilotPluginUsed" -ResultSize 5000

# Monitor OAuth consent events
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
  -Operations "Consent to application" -ResultSize 5000

Financial Sector Considerations

  • Third-Party Risk Management: Financial regulators (OCC, FFIEC) have specific expectations for third-party risk management. Each plugin publisher and Graph 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: When a user asks Copilot a question and a plugin processes the query, the plugin's service receives context from the user's prompt. This may include sensitive business context or customer information. Assess this data exposure risk for each plugin.
  • Graph Connector Data Classification: Data ingested via Graph connectors into the M365 index becomes available to Copilot for grounding. This data must be classified and labeled appropriately. Unclassified external data in the Graph index could be surfaced by Copilot without proper sensitivity controls.
  • 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 Graph connectors, including publisher information, permissions granted, data flows, and last security review date. Examiners may request this during IT examinations.

Verification Criteria

  1. Third-Party Plugin Status: Verify that third-party plugins are disabled (Baseline) or restricted to approved plugins only (Recommended/Regulated)
  2. User Consent Blocked: Confirm that users cannot consent to OAuth applications — attempt user consent and verify it is blocked
  3. Admin Consent Workflow: Verify that admin consent requests are routed to the security team and that a documented review process exists
  4. Plugin Inventory: Confirm a current inventory of deployed plugins exists with publisher, permissions, and last review date
  5. Graph Connector Governance: Verify that Graph connector deployment requires admin approval and that ingested data is classified
  6. Plugin Approval Workflow: Confirm a documented plugin approval workflow exists with security, privacy, and compliance review steps
  7. Permission Scoping: For approved plugins, verify that granted permissions follow the principle of least privilege
  8. Plugin Usage Monitoring: Verify that plugin usage events are captured in audit logs and monitored
  9. Third-Party Risk Assessment: Confirm that plugin publishers have been assessed under the firm's third-party risk management framework
  10. Periodic Review: Confirm that approved plugins are re-assessed at least annually (Recommended) or quarterly (Regulated)

Additional Resources