Control 1.13: Extensibility Readiness (Copilot Connectors, Plugins, Declarative Agents)

Control ID: 1.13 Pillar: Readiness & Assessment Regulatory Reference: GLBA §501(b), FFIEC IT Handbook (Information Security Booklet), OCC Bulletin 2023-17 (Third-Party Relationships), Interagency AI Guidance (2023) Last Verified: 2026-07-26 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

Conduct a pre-deployment assessment for Microsoft 365 Copilot extensibility features -- including Microsoft 365 Copilot connectors (synced and federated), plugins that act as declarative agent actions, and declarative agents (including agents in SharePoint) -- to evaluate the security, data flow, governance, and compliance implications of extending Copilot's capabilities beyond native M365 functionality. Extensibility features introduce external data sources and third-party code into Copilot's processing pipeline, creating additional risk vectors that must be assessed before deployment in regulated financial services environments.

Why This Matters for FSI

GLBA §501(b): Extensibility features that bring external data into Copilot's grounding scope or that allow Copilot to take actions in external systems expand the data protection surface area. Safeguards must extend to cover data flows through connectors, plugins, and agents.
FFIEC IT Handbook (Information Security): Security assessment of new technology components is a core expectation. Each extensibility feature represents a new component in the Copilot architecture that requires security evaluation, including authentication, authorization, data encryption, and input validation.
OCC Bulletin 2023-17: Third-party plugins and connectors may be developed by vendors outside Microsoft. These relationships create third-party risk that must be managed per OCC expectations.
Interagency AI Guidance (2023): AI systems that interact with external data sources and take actions based on AI processing require heightened risk assessment, including evaluation of data quality, bias, and operational risk.
Sarbanes-Oxley §§302/404 (where applicable to ICFR): If extensibility features enable Copilot to interact with financial systems or reporting data through connectors or plugins, the internal control implications must be assessed.

Control Description

Terminology Update (verified 2026-07-26)

Connectors: Microsoft's current product name is Microsoft 365 Copilot connectors. The earlier name "Microsoft Graph connectors" persists in the underlying developer API (the Microsoft Graph connectors API), in the Microsoft Graph connector agent for on-premises sources, and in some admin center UI. This control uses "Copilot connectors" for the product and "Graph connectors API" where the API is meant.

Plugins and actions: Microsoft Learn continues to use "plugins" as the name of the extensibility mechanism, while "actions" describes the role a plugin plays inside a declarative agent. Plugins are supported only as actions within declarative agents and are not enabled in Microsoft 365 Copilot itself.

Copilot Extensibility Architecture

Microsoft 365 Copilot supports the following primary extensibility mechanisms:

Extension Type	Description	Data Flow	Risk Profile
Copilot connectors (synced)	Crawl and index external data into Microsoft Graph, making it discoverable by Copilot and Microsoft Search	External system -> synced connector -> Microsoft Graph index -> Copilot	Medium-High: External data enters M365 search and Copilot grounding scope
Copilot connectors (federated)	Fetch external data in real time over Model Context Protocol (MCP) without indexing it into Microsoft 365	User query -> federated connector -> external system (live) -> Copilot	Medium-High: Data is not indexed, but live queries leave the M365 boundary and authenticate per user
Plugins (declarative agent actions)	Let a declarative agent call an MCP server or an OpenAPI-described REST API to retrieve data or create, update, and delete records	Declarative agent -> plugin -> MCP server / REST API -> response back to the agent	High: The agent interacts with external systems, creating potential for data exfiltration or unauthorized write actions
Declarative agents	Custom Copilot experiences scoped to specific instructions, knowledge sources, and actions	User -> declarative agent -> Copilot + scoped knowledge sources	Medium: Custom Copilot experience with potentially expanded or restricted scope
Agents in SharePoint	Site-scoped agents that become available automatically to licensed users on eligible SharePoint sites	User -> SharePoint agent -> Copilot + SharePoint site content	Low-Medium: Scoped to specific SharePoint content with site-level permissions

Federated connectors differ materially from synced connectors

Federated connectors do not index content into Microsoft Graph. They operate at user level (each user authenticates with OAuth 2.0) rather than organization level, are read-only, and are available only as Microsoft-provided default connectors — custom federated connectors are not supported. Assessments written for the synced/indexed model do not automatically cover the federated data flow.

Copilot Connector Assessment

Synced Copilot connectors bring external data into the Microsoft 365 search and Copilot grounding scope:

Assessment Area	Key Questions	Risk Consideration
Data inventory	What external data sources are connected or planned for connection via Copilot connectors?	Each connector expands Copilot's grounding scope with external data
Data classification	What is the sensitivity classification of data flowing through each connector?	External data may include regulated data (customer records, financial data, PII)
Access control	How are permissions applied to connector-ingested content? Does it use ACLs from the source system?	Permission model mismatches can create oversharing of external data
Data freshness	How frequently is connector data refreshed? Does the connector support incremental refresh, or full refresh only?	Stale connector data can lead to inaccurate Copilot responses; incremental refresh is not available for all data sources
Data quality	What quality controls exist for data ingested through connectors?	Low-quality external data degrades Copilot response quality
Connector source	Is the connector Microsoft-built (one of the 100+ prebuilt connectors), partner-built, or custom-developed?	Third-party and custom connectors require additional security review
Connector mode	Is the connector synced (indexed into Microsoft Graph) or federated (live MCP fetch)?	Federated connectors keep data in the source system but shift authentication to the user and send live queries outside the M365 boundary
On-premises indexing	Does the connector use the Microsoft Graph connector agent to index on-premises content?	On-premises connector agents create an additional network path and host to secure and patch

Copilot Connector Inventory Template

Connector	Source System	Mode (Synced/Federated)	Data Type	Sensitivity	Permission Model	Refresh Frequency	Connector Provider	Approval Status
[Name]	[System]	[Synced/Federated]	[Type]	[Level]	[ACL/Group/None]	[Frequency]	[MS/Partner/Custom]	[Status]

Plugin Assessment

Plugins enable declarative agents to interact with MCP servers and OpenAPI-described REST APIs:

Assessment Area	Key Questions	Risk Consideration
Plugin inventory	What plugins are configured as actions on which declarative agents?	Each plugin extends an agent's capability to interact with external systems
Plugin type	Is the plugin backed by an MCP server or an OpenAPI REST API?	MCP and REST plugins have different discovery, authentication, and change-management characteristics
Dynamic tool discovery	For MCP plugins, are tools resolved dynamically at runtime, or pinned to a fixed set in the plugin manifest?	Dynamic discovery means the tool surface can change without the agent being repackaged or republished, bypassing change control unless tools are pinned
Authentication	How does the plugin authenticate to external systems? What credentials are used?	Credential management and authentication security are critical
Authorization	What actions can the plugin perform? Read-only, or create/update/delete?	Write actions create risk of unauthorized changes in external systems
Data flow	What data flows from the agent to the plugin? What data returns?	Data leaving M365 through plugins may include sensitive information
Input validation	Does the plugin validate inputs to prevent injection attacks?	Prompt injection could trigger unintended plugin actions
Audit logging	Are plugin invocations logged for audit and compliance purposes?	Regulatory requirements for audit trails extend to AI-initiated actions
Plugin source	Is the plugin from Microsoft, a verified publisher, or custom-developed?	Source determines trust level and security review requirements

Plugin Risk Classification

Risk Level	Criteria	Approval Requirement
Low	Read-only access to non-sensitive external data; Microsoft-published plugin	IT admin approval
Medium	Read-only access to sensitive external data; verified publisher plugin	IT admin + security review
High	Create, update, or delete access to external systems; custom-developed plugin; access to financial systems	IT admin + security review + compliance approval
Critical	Create, update, or delete access to financial systems or regulated data; unverified publisher	Full security assessment + compliance review + CISO approval

Declarative Agent Assessment

Declarative agents create custom Copilot experiences:

Assessment Area	Key Questions	Risk Consideration
Agent inventory	What declarative agents exist or are planned?	Each agent creates a custom Copilot experience with specific scope
Scope definition	What knowledge sources does each agent have access to (SharePoint, OneDrive, Copilot connectors, uploaded files)?	Agent scope determines what content it can reference and generate
Instructions	What custom instructions are configured for the agent?	Instructions shape agent behavior and may create compliance implications
Authoring tool	Was the agent built with Agent Builder in Microsoft 365 Copilot, Microsoft 365 Agents Toolkit, Copilot Studio, or SharePoint?	The authoring tool determines which governance controls apply — for example, sharing controls and ownerless-agent reassignment rules currently apply only to Agent Builder agents
Target audience	Who can access and use each agent?	Agent access should be governed and limited to appropriate populations
Agents in SharePoint	Which SharePoint sites expose agents to licensed users?	Agents in SharePoint inherit site permissions but may make content more discoverable
Agent actions	Can the agent invoke plugins or take actions?	Agents with action capabilities inherit plugin risk considerations

Agents in SharePoint Considerations

Agents in SharePoint are a specific category that merits focused attention:

Aspect	Detail	Governance Action
No activation step	Agents in SharePoint do not require activation. Once a user holds a Microsoft 365 Copilot license (or is covered by a pay-as-you-go billing policy), agents become available on eligible sites where the user has permissions	Treat agent availability as on-by-default for licensed users; govern through license assignment, the Microsoft 365 Copilot for SharePoint service plan, and pay-as-you-go billing scope rather than a tenant on/off switch
Permission inheritance	Agents respond based on each user's existing permissions to the underlying site content	Sites with oversharing create agents with oversharing; remediate the permission model, not only the agent
Content scope	Agents use SharePoint sites, pages, and document libraries as knowledge sources	Verify that site content is appropriate for AI-powered discovery
Per-site suppression	Flagging a site with Restricted Content Discovery turns off all agent-related features on that site and prevents its content from surfacing in Copilot or organization-wide search	Apply Restricted Content Discovery to sites holding sensitive content; note that it does not change site access itself
Restricted access control	A restricted access control policy limits site access to a specified group, so site content is visible in Copilot only to that group	Use for sites requiring a hard access boundary rather than discovery suppression alone
Agent file permissions	Agents in SharePoint are `.agent` files; file permissions determine who can access or edit the agent	Govern `.agent` files as content — DLP conditions can target the `.agent` extension, because sensitivity labels cannot yet be applied directly to `.agent` files
Discoverability	Agents do not automatically appear in a published list; site owners can designate one main agent that opens from the Agent icon in the global header	Review designated site agents on sensitive sites
Blocking in Copilot Chat	Tenant and AI admins can block agents in SharePoint from the Agents section of the Copilot Control System in the Microsoft 365 admin center	Note the current limitation: blocking affects availability in Copilot Chat only, not OneDrive, SharePoint, or Teams

Extensibility Governance Framework

1. INVENTORY: Catalog all connectors, plugins, and agents
       |
2. CLASSIFY: Assign risk classification per extension
       |
3. ASSESS: Conduct security and compliance review per risk level
       |
4. APPROVE: Obtain appropriate approvals per risk classification
       |
5. DEPLOY: Deploy with configured governance controls
       |
6. MONITOR: Ongoing monitoring of extension behavior and data flows
       |
7. REVIEW: Periodic re-assessment of extension inventory and risk

Agent 365 Platform Assessment

Organizations should assess readiness for the Agent 365 platform as part of extensibility planning:

Assessment Area	Key Questions	Risk Consideration
Admin access	Which administrators have access to Agent 365? Are roles appropriately scoped?	Overly broad administrative access to the centralized agent platform increases governance risk
Inventory baseline	Has the organization established a baseline inventory of agents across all sources (M365, Copilot Studio, third-party)?	Agent 365 consolidates visibility, but organizations should document the initial inventory before governance review begins
Telemetry readiness	Is the organization prepared to monitor agent usage analytics (sessions, active users, exception rates)?	Agent 365 telemetry signals support operational governance but require defined review cadences and escalation procedures
Policy alignment	Do existing agent governance policies cover the full scope of agents visible in Agent 365?	Policies written for M365-only agents may not address Copilot Studio or third-party agents now visible in the consolidated registry
Management rules	Has the organization evaluated Agent management rules in the Microsoft 365 admin center for bulk governance actions?	Agent management rules apply governance actions in bulk. The currently supported rule-based bulk actions are Install Microsoft (first-party) agents and Reassign ownerless agents created with Agent Builder to manager — publisher restriction is handled separately through Allowed agent types, not through a management rule
Allowed agent types	Has the organization decided which publisher categories (Microsoft, your organization, external publishers) users may view and install from the agent store?	Disabling a category hides those agents from the store; Microsoft-built agents remain visible but cannot be installed
Policy templates	Has the organization evaluated Agent 365 policy templates for consistent policy application?	Policy templates apply predefined security policies, rules, and allow lists to new agents, supporting examination-ready evidence of standardized governance. These appear as "Security templates" on the Agent settings page and are documented as policy templates in the Agent 365 documentation
Agent Map	Has the organization reviewed the Agent Map (Microsoft 365 admin center > Agents > All Agents > Map) for cross-platform agent visibility?	Agent Map groups agents by build platform and surfaces total agents, agents at risk, agents without owners, and unmanaged agents. Note the current limitation: knowledge-source signals are not yet included, so the Map does not close knowledge-source visibility gaps on its own. Access requires an E7 (Agent 365) license and the Entra Global Admin or AI Administrator role
Ownerless agent remediation	Does the organization have a process for reassigning ownerless agents discovered in Agent 365?	Ownerless agents lack governance accountability. The built-in bulk reassignment rule transfers ownership to the previous owner's manager based on the Entra ID hierarchy, but it currently applies only to agents created with Microsoft 365 Copilot Agent Builder — other platforms require a manual workflow

Frontier Agent Governance (Researcher and Analyst)

Microsoft's Researcher and Analyst capabilities are first-party experiences within the core M365 Copilot Chat surface, surfaced under Tools and invocable by the user at any time. They use multi-step reasoning, autonomous web research, and data analysis workflows that differ from standard Copilot interactions. Microsoft documents that Researcher and Analyst are part of the core Copilot Chat experience and do not fall under agent-related settings, so they require a distinct governance approach:

Assessment Area	Key Questions	Risk Consideration
Access scoping	Which user populations have access to Researcher and Analyst? Is access limited to approved roles?	Researcher and Analyst provide capabilities (autonomous multi-step research, code execution) that may not be appropriate for all user populations
Supervisory alignment	Are Researcher and Analyst interactions captured in the same supervisory workflows as standard Copilot usage?	FINRA Rule 3110 supervisory systems and WSPs must cover all AI-assisted interactions; Researcher and Analyst must not create a supervisory blind spot
Data access scope	Does Researcher's web research capability introduce unvetted external data into regulated workflows? Does Analyst have access to data sets containing NPI or MNPI?	Researcher can pull external web content into Copilot responses; Analyst can process uploaded data — both expand the data surface beyond standard Copilot grounding
Exception handling	If the organization blocks Researcher or Analyst for general users, is there a documented exception process for approved business functions (e.g., equity research, compliance monitoring)?	Blanket blocking may impair legitimate business use; documented exceptions with business justification support examination readiness
Agent 365 mapping	Are Researcher and Analyst documented in the agent governance inventory even though they are not Registry-managed agents?	Microsoft documents Researcher and Analyst as core Copilot Chat capabilities that do not fall under agent-related settings, so they are not governed as installable agents — organizations should document them separately in their governance framework to avoid an inventory gap

Entra Agent ID Readiness

Organizations should assess readiness for Entra Agent ID — the capability that assigns unique Entra identities to Copilot agents:

Assessment Area	Key Questions	Risk Consideration
Identity governance	Does the existing identity governance framework accommodate non-human identities for agents?	Agent identities should be managed with the same rigor as service principals and managed identities
Conditional Access	Have Conditional Access policies been reviewed to account for agent identities?	Agents may be subject to or exempt from policies designed for human users — this should be an explicit decision
Audit integration	Are Entra sign-in and audit logs monitored for agent identity activity?	Agent identity events appear alongside human user events and require filtering and review procedures
Lifecycle management	Is there a process for provisioning, reviewing, and deprovisioning agent identities?	Orphaned agent identities create security risk similar to orphaned user or service accounts

Third-Party Model Provider Readiness

Some agents and extensibility components may use third-party model providers (non-Microsoft LLM inference services). Organizations should assess readiness for this risk:

Assessment Area	Key Questions	Risk Consideration
Data residency	Where does inference processing occur? Does the model provider's data processing location comply with organizational and regulatory data residency requirements?	Third-party inference may process data outside the M365 compliance boundary and outside approved geographic regions
Model governance	What model governance, versioning, and change control does the provider maintain?	Model updates by the provider may change behavior, introduce bias, or affect output quality without notice
Data handling	Does the model provider use customer data for training, fine-tuning, or improvement?	Data handling terms for third-party providers may differ from Microsoft's no-training commitment
Contractual coverage	Are third-party model providers covered under existing vendor risk management and third-party agreements?	OCC Bulletin 2023-17 expectations apply to AI model providers that process regulated data
Audit and logging	Does the third-party provider support audit logging and evidence production for regulatory examination?	Regulatory expectations for audit trails extend to all AI processing components, including external inference

Copilot Surface Coverage

Copilot Surface	Extensibility Relevance	Notes
Microsoft 365 Copilot Chat	Critical	Primary surface where Copilot connector data and declarative agents are invoked
SharePoint Copilot	High	Agents in SharePoint create site-scoped Copilot experiences
Teams Copilot	High	Declarative agents (and their plugin actions) can be invoked from Teams conversations
Word / Excel / PowerPoint	Medium	Copilot connector data may surface in document generation
Outlook Copilot	Medium	Agents for CRM and other systems may be surfaced in Outlook
Copilot Pages	Medium	Pages may reference content from Copilot connectors
Copilot Notebooks	Medium	Notebooks may reference content from Copilot connectors
Loop Copilot	Low	Limited extensibility surface
OneDrive Copilot	Low	Limited extensibility surface
Viva Copilot	Medium	Viva-specific connectors and agents

Governance Levels

Level	Requirement	Rationale
Baseline	Inventory existing Copilot connectors, recording synced versus federated mode. Review agent settings in the Microsoft 365 admin center (Allowed agent types, User access, Sharing). Assess which SharePoint sites expose agents to licensed users and whether Restricted Content Discovery is warranted. Document extensibility posture. Disable extensibility features that have not been assessed.	Minimum awareness of extensibility landscape and proactive disabling of unassessed features to reduce risk.
Recommended	All Baseline requirements plus: implement an agent and plugin approval process with risk classification, using the agent request and approval workflow in the Microsoft 365 admin center. Conduct security review for all active Copilot connectors. Assess data flows for each connector and plugin, covering both indexed and live federated paths. Configure SharePoint agent governance (license scope, pay-as-you-go scope, and Restricted Content Discovery based on content sensitivity). Establish an extensibility change management process, including a position on dynamic tool discovery for MCP plugins. Monitor connector and agent usage through admin reports.	Structured governance of Copilot extensibility with security review, approval workflows, and ongoing monitoring.
Regulated	All Recommended requirements plus: conduct full security assessment for all extensions including custom-developed connectors and plugins. Implement formal change control for extensibility deployments, including pinning MCP plugin tools where change control requires a fixed tool surface. Include extensibility in vendor risk management for third-party providers (see Control 1.10). Require compliance sign-off for plugins with create, update, or delete access to external systems. Maintain extensibility governance documentation in regulatory examination file. Conduct quarterly extensibility inventory review. Include extensibility risk in AI governance reporting.	Comprehensive extensibility governance with formal security assessment, compliance oversight, and examination readiness documentation.

Setup & Configuration

Step 1: Review Extensibility Settings

Sign in to the Microsoft 365 admin center and select Copilot > Settings (the Copilot Control System). Review the settings grouped under User access, Data access, Copilot actions, and Other settings, including:

Data access > Agents — tenant controls over agents in Copilot
Data access > AI providers for other large language models — third-party model provider access
Data access > Web search for Microsoft 365 Copilot and Microsoft Copilot
Settings > View all > Copilot Frontier — availability of frontier capabilities

Step 2: Inventory Copilot Connectors

Navigate to Microsoft 365 admin center > Search & intelligence > Data sources to review:

Active Copilot connectors and their connection status
Connector source (Microsoft prebuilt, partner, or custom)
Connector mode (synced or federated)
Data source connections
Item count per synced connector
Permission configuration per connector

Federated connectors provided by Microsoft appear as Ready in the connections list. Custom connectors are supported for synced connectors only.

Step 3: Configure Agent and Plugin Governance

In the Microsoft 365 admin center, agents are managed under the Agents node (the Copilot Control System, formerly surfaced as integrated apps):

Agents > All Agents — review the Agent Registry inventory, and the Map view where licensed
Agents > All Agents > Requests — review and approve or reject pending agent requests before publication to the agent store
Agents > Settings > Agent management rules — apply supported bulk governance actions
Agents > Settings > Allowed agent types — control whether users can view and install agents built by Microsoft, by your organization, and by external publishers
Agents > Settings > Security templates — apply predefined policy templates to new agents
Agents > Settings > Sharing — control who can share agents built with Microsoft 365 Copilot Agent Builder
Agents > Settings > User access — control which users or groups can access agents

Because plugins run as actions inside declarative agents, plugin governance is exercised through the governance applied to the agents that carry them, together with the security review of the plugin's MCP server or REST API.

Use roles with the fewest permissions required. Microsoft identifies Entra Global Admin as a highly privileged role and recommends limiting its use; agent management is also available to the AI Administrator role.

Step 4: Configure Agent Governance in SharePoint

Agents in SharePoint do not require activation — once a user is assigned a Microsoft 365 Copilot license (or is covered by a pay-as-you-go billing policy), agents become available on eligible sites where the user has permissions. There is no tenant-level on/off switch for these agents in the SharePoint admin center. Govern them through the following controls instead:

License and service plan scope — in the Microsoft 365 admin center license details page for Microsoft 365 Copilot, turn the Microsoft 365 Copilot for SharePoint service plan on or off per user. Note that turning it off also disables Copilot in OneDrive and SharePoint page authoring for that user.
Pay-as-you-go billing scope — for unlicensed users, control access through the security group assigned to the pay-as-you-go billing policy.
Restricted Content Discovery — in the SharePoint admin center, flag sites holding sensitive content to turn off all agent-related features on those sites and prevent their content from surfacing in Copilot or organization-wide search.
Restricted access control — apply where a site requires a hard access boundary limited to a specified group.
.agent file permissions and DLP — govern agent files as content; use DLP conditions based on the .agent extension, because sensitivity labels cannot yet be applied directly to .agent files.
Block in Copilot Chat — block specific agents from the Agents section of the Copilot Control System in the Microsoft 365 admin center. Blocking currently affects availability in Copilot Chat only.

Step 5: Establish Approval and Change Management

Document and implement:

Extension request and approval workflow
Risk classification criteria and corresponding approval authorities
Security review requirements per risk level
Change management process for new extension deployments
Periodic review cadence for extension inventory

Financial Sector Considerations

CRM Connector Risk: Many financial institutions consider connecting CRM systems (Salesforce, Dynamics 365) to Copilot via Copilot connectors — both are among Microsoft's prebuilt connectors. This brings client data directly into Copilot's grounding scope. Assess the implications of CRM data in Copilot responses, particularly for institutions subject to SEC Reg S-P and GLBA NPI protections.
Trading System Integration: Plugins or connectors that interact with trading platforms, order management systems, or portfolio management tools introduce the risk that Copilot could initiate or influence trades. Because plugins can create, update, and delete data in the systems they reach, implement strict controls around any extensibility that touches trading infrastructure.
Regulatory Filing Systems: Connectors to regulatory filing systems (EDGAR, FINRA Gateway, regulatory reporting platforms) should be evaluated carefully. Copilot grounding on regulatory filing data could create disclosure risks.
Third-Party Plugin Vendors: Plugins developed by third parties create vendor risk relationships that must be managed per OCC Bulletin 2023-17 and the institution's third-party risk framework. Include plugin vendors in the vendor risk inventory.
MCP Server Change Management: For plugins backed by MCP servers, Copilot resolves the server's tools dynamically at runtime by default, so the available tool surface can change without the agent being repackaged or republished. Institutions with formal change control should assess whether to pin a fixed tool set in the plugin manifest, and should evaluate the same dynamic-surface consideration for federated connectors that use MCP.
Custom Development Security: Custom-developed connectors and plugins must undergo the institution's software development security review process (SDLC security), including code review, vulnerability assessment, and penetration testing. Custom connectors are supported for synced connectors only; federated connectors are limited to Microsoft-provided defaults.
On-Premises Connector Agents: Where the Microsoft Graph connector agent is used to index on-premises content, include the agent host in the institution's infrastructure hardening, patching, and monitoring scope.
Data Sovereignty for Connectors: Copilot connectors may ingest or query data from systems hosted in different geographic locations. Verify that connector data flows comply with data sovereignty and data residency requirements, noting that federated connectors query the source system live rather than indexing content into Microsoft 365.
Information Barrier Interaction: Assess how connector data and plugin responses interact with Microsoft Purview information barriers. External data brought into the Graph may not be segmented by information barrier policies.
Agent Approval Workflows: The Microsoft 365 admin center provides a request and approval workflow for agents — administrators review agent requests in the Agent Registry and decide whether to publish the agent to the agent store or reject the submission. FSI organizations should configure these workflows to require formal approval before agents are deployed to production user populations. This supports examination readiness by creating an audit trail of agent deployment decisions.
Power Platform Inventory: Power Platform inventory provides tenant administrators a unified view of agents, apps, and flows built on Power Platform, with connector usage mapping. For organizations using the companion FSI-AgentGov framework for Copilot Studio governance, Power Platform inventory serves as an operational governance surface for cross-platform agent discovery and management.

Verification Criteria

Inventory of all active Copilot connectors has been completed with data source, connector mode (synced or federated), sensitivity classification, and permission model documented
Agent settings in the Microsoft 365 admin center have been reviewed, and agent types and plugins that have not been assessed are restricted
Agent exposure in SharePoint has been reviewed, and Restricted Content Discovery (or restricted access control) has been applied to sites containing sensitive data (unless specifically approved)
Agent and plugin approval process has been established with risk classification criteria (Recommended and Regulated levels)
Security review has been conducted for all active Copilot connectors (Recommended and Regulated levels)
Data flow assessment has been completed for each active connector and plugin, documenting what data enters and leaves M365 across both indexed and live federated paths (Recommended and Regulated levels)
Compliance sign-off has been obtained for plugins with create, update, or delete access to external systems (Regulated level)
Third-party extension providers are included in the vendor risk inventory (Regulated level)
Extensibility change management process is documented and being followed
Extensibility governance documentation is maintained and accessible for regulatory examination (Regulated level)

Additional Resources

FSI Copilot Governance Framework v1.8.0 - July 2026