Skip to content

Control 2.14: Declarative and SharePoint Agents Governance

Control ID: 2.14 Pillar: Security & Protection Regulatory Reference: GLBA §501(b) 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

Govern the creation, sharing, user access, and data boundary enforcement for declarative agents, with specific attention to SharePoint-backed agents and other agents surfaced through Microsoft 365 Copilot. This control focuses on the security guardrails that determine who can use agents, who can share them, and how agent access is limited to approved publishers, audiences, and knowledge sources.


Why This Matters for FSI

  • GLBA §501(b) requires safeguards for customer information. Agents can accelerate access to site content, uploaded knowledge, and external tools, so security boundaries should be explicit.
  • Agent proliferation risk increases when users can create or broadly share agents without governance approval.
  • Data boundary enforcement matters because SharePoint-backed agents can expose sensitive site content to new audiences if permissions and sharing are not reviewed carefully.
  • FFIEC and OCC AI governance expectations support maintaining oversight of who can use AI tools, how those tools are shared, and what data they can access.

Control Description

Microsoft 365 now exposes agent governance through the Agents control plane in the Microsoft 365 admin center. Security decisions for agents are no longer limited to the original SharePoint agent creation flow. Administrators can now review agent inventory, restrict allowed agent types, control sharing, and scope user access through centralized settings.

Agent 365 as a Centralized Governance Surface

In addition to the Agents section in the M365 Admin Center, Agent 365 provides a centralized governance hub that spans agents across M365 apps, Copilot Studio, and third-party integrations. Agent 365 consolidates agent inventory, usage analytics, and lifecycle management into a single platform, providing:

  • Unified registry of all agent types — Microsoft, organization-published, partner, Copilot Studio, and third-party
  • Cross-platform telemetry including session counts, active users, exception rates, and runtime metrics
  • Centralized policy controls for allowed types, sharing, user access, and templates
  • Governance action cards that highlight ownerless agents, pending requests, and policy gaps

For security teams, Agent 365 provides a single evidence source for agent inventory, ownership, and usage that supports FFIEC and OCC examination preparation. Organizations should incorporate Agent 365 review into their agent governance workflow alongside the existing M365 Admin Center Agents controls.

Agent 365 Management Rules

Agent 365 management rules enable organizations to define automated governance policies that apply across the full agent inventory:

Management Rule Description FSI Application
Publisher allowlisting Restrict agent installation to approved publishers only Prevents unapproved third-party agents from entering the environment; supports OCC Bulletin 2023-17 third-party lifecycle management
Ownership requirements Require that all agents have a designated owner; surface ownerless agents for reassignment Ownerless agents lack governance accountability; management rules can block ownerless agents from operating or auto-notify administrators
Lifecycle policies Define inactivity thresholds after which agents are flagged for review or disabled Stale agents that remain active may accumulate permission drift or reference outdated knowledge sources
Sharing scope limits Restrict agents from being shared organization-wide without admin approval Prevents agent sprawl; requires explicit governance review before broad deployment
Security templates Apply baseline security configurations (allowed knowledge sources, action permissions, sharing scope) to new agents via pre-defined templates Security templates provide examination-ready evidence of standardized governance and reduce ad-hoc configuration risk

Agent Map

The Agent Map in Agent 365 provides a visual dependency graph showing cross-agent relationships:

  • Which agents share the same knowledge sources (SharePoint sites, uploaded files)
  • Which agents invoke the same plugins or connectors
  • Which agents are orphaned (no owner, no recent usage, no knowledge-source updates)

FSI application: Agent Map helps institutions identify governance gaps — for example, a sensitive SharePoint site used as a knowledge source by multiple agents from different business units may require information barrier review. Orphaned agents surfaced by Agent Map should be triaged for reassignment or decommissioning.

Ownerless Agent Remediation

When Agent 365 identifies agents without a designated owner (due to owner departure, role change, or agent creation without explicit ownership):

  1. Agent 365 surfaces ownerless agents in the governance action cards dashboard
  2. Administrators should reassign ownership within a defined SLA (recommended: 5 business days for standard agents, 48 hours for agents with access to sensitive data)
  3. Agents that remain ownerless beyond the SLA should be disabled pending reassignment
  4. Document ownership reassignment decisions in the agent governance registry

Stakeholder Oversight Model

For regulated FSI environments, agent governance should follow a stakeholder oversight model:

Stakeholder Responsibility Review Cadence
Agent owner (business line) Maintains agent knowledge sources, validates accuracy, manages user access Continuous
IT security Reviews agent permissions, knowledge-source sensitivity, action capabilities Quarterly or on change
Compliance Validates agent outputs against regulatory requirements (FINRA 2210, supervisory obligations) Quarterly
Internal audit Independent review of agent governance controls and registry completeness Annual

Entra Agent ID

Microsoft Entra ID now assigns unique identities to Copilot agents through Entra Agent ID. Each agent receives a distinct Entra identity object that enables:

Capability Security Benefit
Identity assignment Agents are identifiable as distinct security principals in Entra ID
Audit attribution Agent activity is traceable in Entra sign-in and audit logs
Conditional Access Agents can be scoped by Conditional Access policies to control operational context
Compliance tracking Per-agent compliance attribution in Purview audit trails

Organizations should verify that Entra Agent ID is enabled for governed agents and that Conditional Access policies are reviewed to account for agent identities alongside human user identities.

Purview AI App Taxonomy and Pillar 2 Control Mapping

Microsoft Purview classifies AI applications into categories within the DSPM AI app catalog, enabling governance policies to be applied by app type rather than individually. The following matrix maps Purview AI app categories to Pillar 2 security controls and Agent 365 governance support:

Purview AI App Category Applicable Pillar 2 Controls Agent 365 Support Governance Action
Microsoft 365 Copilot (first-party) 2.1 (DLP), 2.2 (sensitivity labels), 2.9 (Defender/MDCA), 2.10 (insider risk) Full — unified registry, telemetry, policy controls Apply standard Copilot governance stack; monitor via DSPM Activity Explorer
Copilot Studio agents (organizational) 2.13 (plugin security), 2.14 (agent governance), 2.16 (MCP/connectors) Full — visible in Agent 365 registry with ownership, usage analytics Require Agent 365 registry enrollment and security template application
Third-party AI apps (sanctioned) 2.9 (Defender Cloud Apps catalog), 2.7 (data residency), 2.13 (connector security) Partial — visible in inventory, limited policy enforcement Manage via MDCA generative AI app catalog; apply DLP at the response layer
Shadow AI apps (unsanctioned) 2.9 (Defender discovery and blocking) None — not registered in Agent 365 Block via MDCA app governance policies; escalate to compliance
SharePoint agents (auto-created) 2.14 (agent governance), 2.5 (grounding scope) Full — visible in Agent 365 and SharePoint admin center Inherit site permission governance; disable on sensitive sites
External partner agents 2.14 (agent governance), 2.17 (cross-tenant federation), 2.7 (data residency) Partial — visible in registry, limited telemetry Require third-party risk assessment per OCC Bulletin 2023-17

Compliance Manager AI Templates

Microsoft Purview Compliance Manager includes premium AI assessment templates that map AI governance requirements to regulatory frameworks. Organizations should evaluate these templates as an evidence management complement to the controls in this framework:

Template Category Coverage FSI Application
AI Risk Management Maps AI governance controls to NIST AI RMF, ISO 42001, and EU AI Act requirements Provides structured assessment evidence for AI governance readiness
Copilot-specific assessments Maps Copilot data handling, privacy, and security controls to regulatory requirements Supports examination readiness by providing pre-built assessment workflows for Copilot governance
Industry-specific AI Templates customized for financial services AI compliance (where available) Aligns Copilot governance with FSI-specific regulatory expectations

Organizations should review available Compliance Manager AI templates in Microsoft Purview > Compliance Manager > Regulations and assess whether template-based assessments complement or overlap with the controls documented in this framework. Compliance Manager assessment results can serve as examination-ready evidence alongside the verification criteria defined in each control.

Agent Types Relevant to CopilotGov

Agent Type Security Consideration Primary Governance Surface
Published by your organization Broad availability requires approval and ownership Agents > All agents / Registry
Shared by creator Creator-shared agents can spread quickly without central review Agents > All agents / Sharing controls
Microsoft agents First-party experiences require access decisions and usage oversight Agents > Settings > Allowed agent types
External partner agents External publishers may introduce new data handling terms or integrations Agents > Settings > Allowed agent types
SharePoint-backed agents Ground on SharePoint sites and therefore inherit site-permission risk Agents + SharePoint admin center

Central Security Controls

Control Description Admin Configuration
Allowed agent types Controls which classes of agents users can install Agents > Settings > Allowed agent types
Sharing Controls who can share agents broadly in the organization Agents > Settings > Sharing
User access Limits who can use agents at all Agents > Settings > User access
Registry review Tracks published, shared, blocked, or ownerless agents Agents > All agents / Registry
Knowledge source review Validates SharePoint sites, embedded files, and external data sources SharePoint admin center, Agent details, Search / connector review
Agent pinning Pin up to 3 agents per user so they appear prominently in the Copilot experience M365 Admin Center > Copilot > Agents > Manage pinned agents

Agent Pinning Governance

Administrators can pin up to 3 agents per user via the M365 Admin Center, causing those agents to appear prominently in the user's Copilot experience. Pinning is a governance tool for promoting sanctioned agents and guiding users toward approved AI workflows.

Aspect Detail
Portal M365 Admin Center > Copilot > Agents > Manage pinned agents
Maximum pinned agents Up to 3 per user
Pin sources Microsoft-pinned (by Microsoft), admin-pinned (by the organization), user-pinned (by the user)
User removal Users cannot remove Microsoft-pinned or admin-pinned agents from their pinned list
Eligibility Only deployed, non-blocked agents can be pinned
Targeting Pinning can target everyone in the organization, specific Entra ID security groups, or individual users

FSI governance considerations:

  • Promote sanctioned agents: Use pinning to ensure that compliance-approved agents (e.g., policy lookup, trade documentation assistants) are immediately visible to relevant user populations
  • Document pinning decisions: Maintain a record of which agents are pinned, the target audience, and the business justification for each pinning decision
  • Coordinate with agent registry: Pinned agents should appear in the agent governance registry (see Step 3 above) with documented ownership and approval status
  • Review cadence: Include pinned agent assignments in the quarterly agent governance review to verify that pinned agents remain appropriate and actively maintained

Researcher and Analyst Nuance

Microsoft documents Researcher and Analyst as first-party experiences within the core Microsoft 365 Copilot chat experience. They coexist with agents and inherit related governance capabilities, but they do not fall under installable agent settings in the same way as Registry-managed agents. Document them as Copilot Chat capabilities when defining access policy and supervision requirements.

Agent Risk Assessment Matrix

Risk Factor Low Risk Medium Risk High Risk
Publisher Microsoft Internal approved creator External partner or unreviewed creator
Knowledge source Public intranet or non-sensitive content Department knowledge Client data, regulated records, or uploaded files with sensitive content
Sharing scope Creator only or named users Department Organization-wide or cross-functional
Allowed users Approved pilot group Documented business group Broad tenant access without governance review
Web / action capability Disabled or limited Approved business use External or high-impact actions without control evidence
Model provider Microsoft (Azure OpenAI) Microsoft with custom configuration Third-party model provider (external inference, data residency, and model governance considerations)

Copilot Surface Coverage

M365 Surface Agent Access Security Governance Notes
Microsoft 365 Copilot Chat Yes Primary user experience for many agents
Teams Yes Review alongside collaboration and supervision controls
SharePoint Yes Important for SharePoint-backed agent knowledge scope
Copilot Pages Indirect Agent responses can create Pages; align with Control 2.11
Word / Excel / PowerPoint / Outlook Limited / varies Review by scenario and agent type

Governance Levels

Level Requirement Rationale
Baseline Restrict agent user access to approved users or groups; allow only approved agent types; review Registry inventory monthly; review SharePoint knowledge sources before publication Minimum control over who can use and share agents
Recommended All Baseline requirements plus: group-based sharing rules, documented owner for each published agent, quarterly source-site review for SharePoint-backed agents, formal approval workflow for broader publication Balanced production governance for most FSI deployments
Regulated All Recommended requirements plus: compliance review for high-risk or client-data agents, documented exception process for external or broadly shared agents, monthly registry review, evidence retained for examination support Stronger security posture for regulated or segmented environments

Setup & Configuration

Step 1: Configure Agent User Access

Portal: Microsoft 365 Admin Center
Path: Agents > Settings > User access

  1. Choose All users, No users, or Specific users/groups.
  2. For FSI deployments, prefer approved user or group scoping over broad default access.
  3. Document the approved audiences and the associated business justification.

Step 2: Configure Allowed Agent Types and Sharing

Portal: Microsoft 365 Admin Center
Path: Agents > Settings > Allowed agent types / Sharing

  1. Decide whether Microsoft, internal, and external agents are permitted.
  2. Restrict broad sharing to approved groups where required.
  3. Document how creator-shared agents are reviewed before broader use.

Step 3: Review Agent Registry

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

  1. Review published, shared, blocked, and ownerless agents.
  2. Confirm each broadly available agent has an owner and approval record.
  3. Block or remove agents that do not meet policy.

Step 4: Review SharePoint-Backed Knowledge Sources

Portal: SharePoint admin center and agent details

  1. Review source sites or uploaded knowledge used by high-risk agents.
  2. Confirm permissions, labels, and sharing posture are appropriate.
  3. Cross-reference Control 1.2 for oversharing remediation and Control 2.5 for grounding scope decisions.

Step 5: Establish Security Review Workflow

  1. Define who reviews new agents before broader publication.
  2. Require extra review for:
  3. client-data or regulated-content agents
  4. external partner agents
  5. agents with embedded file knowledge
  6. Record approval, owner, and review cadence for each governed agent.

Financial Sector Considerations

  • Client-data agents: Agents grounded on client or account content should undergo stronger review than general knowledge assistants.
  • Publisher trust: External partner agents require review of data handling, privacy terms, and operational dependency.
  • SharePoint oversharing: A well-designed agent still inherits risk from an overshared source site. Security review should include the underlying content boundary.
  • Research and analysis workflows: If Researcher or Analyst are enabled for high-risk business functions, document that decision in Copilot governance even though those tools are not managed like Registry-installed agents.

Verification Criteria

  1. User access scoped: Verify agent access is limited to the approved users or groups.
  2. Allowed types configured: Confirm allowed agent types match the institution's policy.
  3. Sharing rules configured: Verify broad agent sharing is limited or approved.
  4. Registry inventory current: Confirm published and shared agents are inventoried and owned.
  5. SharePoint source review completed: Confirm high-risk agents have documented knowledge-source review.
  6. Exception handling documented: Verify any external or high-risk agent exceptions have approval evidence.

Additional Resources