Control 4.13: Copilot Extensibility and Agent Operations Governance
Control ID: 4.13 Pillar: Operations & Monitoring Regulatory Reference: GLBA §501(b), FFIEC IT Examination Handbook, Sarbanes-Oxley §§302/404, OCC Bulletin 2023-17 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 ongoing operational governance for Copilot extensibility components and agents, including plugins, Microsoft Graph connectors, shared agents, published agents, and the Microsoft Agent 365 control plane. This control addresses the post-deployment lifecycle: inventory, monitoring, ownership, reassessment, exception handling, and decommissioning.
Why This Matters for FSI
Extensibility and agents expand what Copilot can access and do. In financial services, that means governance cannot stop at initial approval. Organizations should continue to monitor who owns each agent, what data it touches, whether usage is growing in higher-risk functions, and whether third-party or partner integrations still meet policy.
This control helps cover:
- GLBA §501(b) safeguard monitoring for connected data sources and agent behavior
- FFIEC operational governance for third-party dependencies and lifecycle oversight
- Sarbanes-Oxley §§302/404 evidence where extensibility or agents support finance or control-related workflows
- OCC third-party risk expectations for plugins, partner agents, and connected services
Disclaimer
This control is provided for informational purposes only and does not constitute legal, regulatory, or compliance advice. See full disclaimer.
Control Description
Operational governance now spans both traditional Copilot extensibility surfaces and the newer Microsoft Agent 365 control plane.
Copilot Studio lifecycle scope: Copilot Studio agent lifecycle (authoring → testing → publishing → versioning → deprecation evidence) is governed by Control 4.14 — Copilot Studio Agent Lifecycle, which complements this control's extensibility focus with Studio-specific lifecycle artifacts.
Core Operational Surfaces
| Surface | Primary Path | Governance Purpose |
|---|---|---|
| Integrated apps | Settings > Integrated apps | App and plugin inventory, deployment, and approvals |
| Graph connectors | Search / data sources administration | External knowledge ingestion and connector health |
| Agent Overview | Agents > Overview | Adoption, runtime, exception rate, and governance action cards |
| Agent Registry / All agents | Agents > All agents / Registry | Inventory, publishing state, blocked agents, ownerless agents |
| Agent settings | Agents > Settings | Allowed types, sharing, templates, and user access |
What Should Be Inventory Tracked
| Component Type | Minimum Inventory Fields |
|---|---|
| Plugins / integrated apps | Name, publisher, access scope, owner, approval date, last review |
| Graph connectors | Name, data source, authentication method, owner, state, last review |
| Shared or published agents | Name, publisher type, owner, audience, knowledge sources, approval status |
| Agents with embedded file knowledge | File source, sensitivity label, storage container reference, owner |
Agent 365 Operational Signals
The Agent Overview surface introduces operational signals that should be reviewed as part of the same governance program:
| Signal | Why It Matters |
|---|---|
| Agent Registry count | Tracks inventory growth across Microsoft, partner, and org-created agents |
| Active users | Shows where agent usage is material enough to require deeper review |
| Total sessions | Indicates scale and growth of agent dependence |
| Exception rate | Helps identify unstable or poorly governed agents |
| Agent runtime | Highlights higher-intensity or more consequential agent use |
| Pending requests / ownerless agents | Indicates governance gaps that need operational follow-up |
Agent 365 Operational Governance Procedures
Agent 365 introduces centralized operational governance capabilities that extend beyond the signals above:
| Procedure | Description | Recommended Cadence |
|---|---|---|
| Consolidated inventory review | Review the full Agent 365 registry for new, modified, blocked, and ownerless agents across M365, Copilot Studio, and third-party sources | Monthly (Baseline), Bi-weekly (Regulated) |
| Usage reporting and telemetry | Export and review agent usage telemetry — sessions, active users, runtime, and exception trends — to identify material dependencies and operational risk | Monthly |
| Cross-platform policy reconciliation | Verify that allowed types, sharing, and user access policies in Agent 365 are consistent with policies applied in individual admin centers (M365, Copilot Studio) | Quarterly |
| Third-party agent reassessment | Review partner and third-party agents visible in Agent 365 against current vendor risk and data handling requirements | Quarterly (Recommended), Monthly (Regulated) |
| Agent identity audit | Cross-reference Entra Agent ID sign-in and audit logs with the Agent 365 registry to identify unauthorized or unregistered agent activity | Monthly (Regulated) |
| Governance action card triage | Review and resolve governance action cards surfaced in the Agent 365 Overview — ownerless agents, pending requests, and policy gaps | Weekly (Regulated), Monthly (Recommended) |
Lifecycle Management Stages
| Stage | Operational Activity |
|---|---|
| Request / identify | Capture business need, publisher, and data scope |
| Approve / publish | Record owner, approver, and audience |
| Deploy | Assign user access, sharing, and connected services |
| Monitor | Review usage, exceptions, ownership, and connector health |
| Reassess | Recheck risk, scope, and third-party posture on a recurring cadence |
| Block / remove | Retire stale, risky, or noncompliant components |
Researcher and Analyst Note
Researcher and Analyst should be included in governance reporting because they affect Copilot usage and risk posture. However, they are part of the core Copilot chat experience and are not managed as installable Registry agents in the same way as published or shared agents.
Copilot Surface Coverage
| Surface | Extensibility / Agent Governance Priority | Notes |
|---|---|---|
| Microsoft 365 Copilot Chat | Critical | Main entry point for many agents and extensions |
| Teams | High | Collaboration context and possible plugin or agent exposure |
| SharePoint-backed agents | Critical | Strong dependence on source-site security and ownership |
| Outlook / Word / Excel / PowerPoint | Medium | Governed by access, plugin, and connected-data controls |
| Partner / external agents | High | Third-party risk and data-handling review required |
Governance Levels
Baseline
- Maintain a current inventory of plugins, connectors, and governed agents
- Assign an owner to each published or broadly shared agent
- Review Agent Overview and Registry at least monthly
- Block or remove components that lack a clear owner or approval basis
Recommended
- Review exception rate, adoption growth, and pending requests regularly
- Track embedded-file agents and connector data sources explicitly
- Reassess third-party and partner components on a recurring schedule
- Integrate agent and extensibility changes into formal change management
Regulated
- Include high-risk extensibility and agent components in examination evidence packages
- Maintain formal exception approvals for partner or high-risk components
- Review ownerless agents, blocked agents, and material agent metrics monthly
- Retain approval, review, and decommission evidence in accordance with the firm's records policy
Setup & Configuration
Step 1: Build the Operational Inventory
- Review Settings > Integrated apps for plugins and deployed apps.
- Review connector inventory through the appropriate search / connector administration surface.
- Review Agents > All agents / Registry for shared, published, blocked, and ownerless agents.
- Consolidate the data into one governance inventory.
Step 2: Review Agent Overview
- Open Agents > Overview.
- Review hero metrics and governance action cards.
- Investigate ownerless agents, pending requests, and unusual exception rates.
Step 3: Review Settings and Access
- Open Agents > Settings.
- Confirm allowed types, sharing, templates, and user access align with policy.
- Reconcile settings changes with the formal change log.
Step 4: Reassess Connected Data Sources
- Review Graph connectors and embedded-file agents for sensitivity, permissions, and ownership.
- Confirm the current data scope still matches the approved business case.
- Reassess partner or external publishers against current third-party requirements.
Step 5: Decommission or Block Stale Components
- Identify stale or high-risk plugins, connectors, or agents.
- Block first, then verify business impact.
- Remove or retire components when no longer justified.
- Preserve approval and retirement records.
Financial Sector Considerations
Third-party risk: Partner agents and plugins should be treated as ongoing third-party relationships, not one-time approvals.
Owner accountability: Ownerless agents are a material governance gap because they prevent effective remediation, review, and accountability.
Agent runtime and exception trends: Operational instability can indicate unreliable automations or poorly governed business-critical use cases.
Power Platform Inventory (GA March 2026): The Power Platform Inventory now provides a unified view across agents, apps, flows, and environments. For organizations using the companion FSI-AgentGov framework, Power Platform Inventory serves as an operational governance surface for cross-platform agent discovery. Organizations should include Power Platform Inventory data in their extensibility governance reviews alongside the M365 Admin Center Agent 365 dashboard.
SharePoint-backed knowledge: Any extensibility or agent component that relies on overshared SharePoint content remains risky even if the agent itself is well configured.
Advisory: Multi-Agent Orchestration and Agent-to-Agent (A2A) Security
GA — April 2026
Multi-agent orchestration is now generally available. Copilot Studio agents can orchestrate with other agents — including Microsoft Fabric agents — via agent-to-agent (A2A) protocols. Agents can call other agents as tools, creating chained execution flows.
FSI governance implications:
- Cross-agent data flows: When Agent A calls Agent B as a tool, data from Agent A's context (including potentially sensitive financial data) flows to Agent B. If Agent B has different DLP policies, sensitivity label handling, or data residency requirements, the chain may create an unintended data exposure path. Organizations should map agent-to-agent data flows and apply the most restrictive policy to the entire chain.
- Auditability and lineage: Multi-agent chains may obscure the origin and transformation of data in Copilot responses. For FSI environments subject to model risk management (SR 26-2 / OCC Bulletin 2026-13, applying SR 11-7 / OCC Bulletin 2011-12 principles to generative AI per Control 3.8), organizations should verify that Purview audit logs capture the full execution chain including which agents participated.
- DLP policy applicability: Organizations should verify whether DLP policies apply at each agent boundary or only at the initial orchestration point. A DLP policy that blocks sensitive data in the primary agent may not prevent that data from reaching a sub-agent if policies are evaluated only at the entry point.
- Agent identity and permissions: Each agent in a chain may execute with different permissions via Entra Agent ID. Organizations should verify that chained agents follow least-privilege principles and that no agent in the chain escalates data access beyond what the initiating user is authorized to see.
- Third-party agent risk: If an orchestration chain includes third-party or partner-built agents, the data governance and residency implications extend to the third party's execution environment. This should be reflected in vendor risk assessments (Control 1.10).
Recommended actions:
- Inventory all agents that participate in multi-agent orchestration chains
- Map data flow paths across agent-to-agent calls and identify DLP boundary gaps
- Verify Purview audit log coverage for chained agent executions
- Apply the most restrictive governance policy to the full orchestration chain
- Update agent approval workflows to require A2A orchestration disclosure
Verification Criteria
| # | Verification Step | Expected Result |
|---|---|---|
| 1 | Review consolidated inventory | Plugins, connectors, and governed agents are documented |
| 2 | Verify ownership | All published or broadly shared agents have owners |
| 3 | Review Agent Overview | Metrics and governance action cards are monitored |
| 4 | Confirm settings baseline | Allowed types, sharing, templates, and user access match policy |
| 5 | Review third-party or partner components | Reassessment evidence exists for higher-risk components |
| 6 | Confirm stale component handling | Blocked or retired items are documented |
Additional Resources
- Manage agents in the Microsoft 365 admin center
- Agent 365 Overview in the Microsoft 365 admin center
- Agent Registry in the Microsoft 365 admin center
- Agent settings in Microsoft 365 admin center
- Microsoft 365 Copilot Extensibility
- Implementation Playbooks: Portal Walkthrough · PowerShell Setup · Verification · Troubleshooting
- Related Controls: 2.13 Plugin and Connector Security, 2.14 Declarative Agents Governance, 4.1 Admin Settings, 4.12 Change Management