# Control 1.4: Advanced Connector Policies (ACP)

**Control ID:** 1.4<br>
**Pillar:** Security<br>
**Regulatory Reference:** FINRA 3110, FINRA 4511, FINRA RN 24-09, SEC Reg S-P (2024 amendments), SEC Rule 17a-4(f), GLBA Safeguards Rule (16 CFR 314), SOX 404, OCC Bulletin 2026-13 (formerly OCC Bulletin 2011-12) / Fed SR 26-2 (formerly SR 11-7), NIST SP 800-53 Rev. 5 SA-9 / AC-4<br>
**Last UI Verified:** April 2026<br>
**Governance Levels:** Baseline / Recommended / Regulated<br>

---

## Objective

Control which connectors and actions AI agents can use by implementing Advanced Connector Policies (ACP) and DLP boundaries. This control restricts agent access to approved data sources and services with appropriate action-level restrictions.

---

## Why This Matters for FSI

- **FINRA Rule 3110 (Supervision) and Regulatory Notice 24-09 (Generative AI / LLM Guidance):** Require supervisory systems and Written Supervisory Procedures (WSPs) covering associated-person use of AI tools. A default-deny ACP allowlist with named approvers and published-rule evidence helps meet the technical-supervisory expectation regulators look for during examination.
- **FINRA Rule 4511 (Books and Records):** Requires firms to preserve books and records of business activities. Power Platform DLP and ACP policy changes are captured in Microsoft Purview Audit (Control 1.7) and aid in producing the connector-governance audit trail examiners request.
- **SEC Regulation S-P, as amended 2024 (17 CFR 248.30):** Customer NPI safeguarding plus a written incident-response program with 30-day notification for unauthorized access. Blocking consumer-cloud and external-egress connectors via ACP helps reduce the data-exfiltration attack surface that would trigger notification.
- **SEC Rule 17a-4(f) (Electronic Records):** Requires non-rewriteable, non-erasable preservation of required records. ACP itself does not produce 17a-4 records, but it constrains which connectors can write or transmit firm records, and policy changes themselves are auditable.
- **GLBA Safeguards Rule (16 CFR Part 314, FTC 2023 update):** Requires access controls and monitoring of authorized users and system activity. ACP is the access-control layer for agent-to-system data flows.
- **SOX Section 404 (Internal Control over Financial Reporting):** Connectors that touch financial systems (Dataverse finance tables, ERP APIs, GL exports) are in-scope ITGCs. Action-level restrictions (read vs. write) and change-controlled allowlists support the "appropriate authorization" assertion.
- **OCC Bulletin 2026-13 (formerly OCC Bulletin 2011-12) / Fed SR 26-2 (formerly SR 11-7) (Model Risk Management):** Treat agent-accessible connectors as model inputs/outputs — restricting them through ACP supports the input-data-quality and change-control expectations of MRM.
- **NIST SP 800-53 Rev. 5 SA-9 (External System Services) and AC-4 (Information Flow Enforcement):** ACP is the implementation mechanism that catalogs approved external services and enforces information-flow policy between connectors of differing trust classifications.

---

## Control Description

Advanced Connector Policies (ACP) provide granular control over which connectors and specific actions are available to AI agents in Power Platform. Combined with DLP policies, this control establishes data boundaries that prevent unauthorized data flows.

| Capability | Description |
|------------|-------------|
| Connector Allowlisting | Explicitly approve connectors for regulated environments |
| Action-Level Control | Restrict to read-only actions by default; require approval for write/update/delete |
| DLP Integration | Business/Non-Business/Blocked classifications prevent cross-boundary data flows |
| Environment Groups | Apply consistent policies across multiple regulated environments |

---

## Key Configuration Points

- **Prerequisite — Managed Environments:** Required to block nonblockable connectors. On non-Managed Environments, ACP can run but the platform's nonblockable connectors remain unblockable. See Control 2.1.
- **Prerequisite — Environment Groups (recommended for scale):** Define group membership in Control 2.2 before publishing ACP at the group level. Single-environment ACP is the targeted alternative for high-risk or pilot environments.
- **Default-deny posture:** ACP is a strict allowlist — every certified connector and every connector action is blocked unless explicitly allowed. New connectors added to the platform are automatically blocked.
- **Action-level governance:** Allow only the specific triggers/actions required for the agent use case. Default to read/list/get; require change control to enable create/update/delete. ACP exposes deprecated and internal actions so they can be explicitly turned off.
- **Status verification:** After save, confirm the policy panel shows **Status: Applied** at both the group and environment scope. Publishing performs an environment lifecycle operation that appears in environment history as **Update Managed Environment Settings**.
- **Mixed mode vs. ACP-only mode:** Mixed mode (default) evaluates the most restrictive of classic DLP + ACP and is the safer posture during migration. ACP-only mode bypasses classic DLP evaluation entirely. FSI organizations should keep mixed mode until custom connector and HTTP connector support land in ACP and a documented migration of all virtual-connector and endpoint-filtering rules to native equivalents has been completed.
- **Coverage gaps that still require classic DLP:** ACP currently applies only to certified connectors (and MCP servers at server-level). **Custom connectors, HTTP / HTTP with Microsoft Entra ID connectors, and connector endpoint filtering** must continue to be governed by classic DLP data policies. Microsoft Copilot Studio virtual connectors (knowledge sources, channels, skills) are out of scope for ACP and will receive their own dedicated rules.
- **Design-time vs. runtime enforcement:** Design-time enforcement is rolling out maker-portal-by-maker-portal (Power Automate first, then Copilot Studio, then Power Apps). Until design-time is GA in a portal, ACP enforces at runtime only for that workload — plan maker communications accordingly.
- **Block consumer egress connectors:** Social media, public cloud storage (Dropbox, Box, Google Drive), consumer file-sharing, and any connector whose terms permit training on customer data should remain unallowed in Zone 2 and Zone 3.
- **MCP server inventory:** Each approved Model Context Protocol server is listed in ACP alongside connectors and can be blocked at server level. Granular tool-level ACP control is not yet available — combine ACP server-level blocking with the maker-side Copilot Studio tool toggles for defense in depth.
- **Govern plugins and extensions per the terminology table below.**

!!! tip "Automation Available"
    See [Scope Drift Monitor](https://github.com/judeper/FSI-AgentGov-Solutions/tree/main/scope-drift-monitor) in FSI-AgentGov-Solutions for automated monitoring of connector usage patterns that may indicate agents accessing data beyond declared operational scope.

!!! warning "Service Principal Security Group Bypass"
    DLP connector policies applied via security groups may not cover Service Principal-based connections. Service Principals used by Power Automate flows authenticate as application identities without user group membership, potentially bypassing group-scoped DLP policies.

    **Compensating Control:**

    - Apply DLP policies at **environment level** rather than security group level to ensure Service Principals are subject to connector restrictions
    - Use Environment Groups (Control 2.2) to apply consistent DLP policies across Zone 2/3 environments
    - Audit Service Principal connections quarterly using Power Platform Admin Center > Data policies > Connectors report

### Copilot Plugins and Extensions Terminology

Microsoft 365 Copilot and Copilot Studio support various extension mechanisms. Use consistent terminology for governance:

| Microsoft Term | Also Known As | Governance Scope |
|----------------|---------------|------------------|
| **Copilot Plugins** | M365 Copilot extensions | Third-party capabilities added to M365 Copilot |
| **Copilot Connectors** | Graph connectors for Copilot | Data source integrations for Copilot grounding |
| **Power Platform Connectors** | Custom connectors, Premium connectors | API integrations used by Copilot Studio agents |
| **Copilot Studio Tools** | Agent tools, Agent actions | Specific operations agents can perform via tool integrations |
| **MCP Tools** | Model Context Protocol tools | External tool integrations using MCP standard |
| **Agent Skills** | Copilot Studio skills | Reusable capabilities shared across agents |

> **MCP Clarification:** Model Context Protocol (MCP) is an open protocol for tool integration, not a Microsoft-native capability. Organizations implementing MCP-based integrations must apply vendor risk management (Control 2.7) accordingly. Native Microsoft connectors do not use MCP—this guidance applies only to custom agent implementations.

**Plugin Governance Requirements:**

1. **Copilot Plugins (M365):** Governed via Microsoft 365 Admin Center > Integrated Apps
2. **Power Platform Connectors:** Governed via DLP policies and ACP in PPAC
3. **Custom Connectors:** Require security review before Zone 2/3 deployment
4. **MCP Tools:** Require vendor assessment per Control 2.7 before enablement
5. **Custom MCP Servers:** Govern MCP server access and tool scope with the controls Microsoft exposes as the feature rolls out; approve only named MCP servers for Zone 2 and Zone 3 use cases

---

## Zone-Specific Requirements

| Zone | Requirement | Rationale |
|------|-------------|-----------|
| **Zone 1** (Personal) | Tenant-wide classic DLP policy with consumer/social/external-storage in **Blocked** group; HTTP connectors restricted to internal endpoints. ACP not required (Managed Environments may not be in scope for Zone 1). | Personal-productivity agents must not be a path for NPI exfiltration to consumer services even without Managed Environments licensing. |
| **Zone 2** (Team) | Managed Environments enabled; ACP published at the environment-group level with documented allowlist; classic DLP retained in mixed mode for custom/HTTP connector coverage; quarterly allowlist recertification. | Team agents access shared business data; default-deny ACP plus mixed-mode classic DLP gives defense-in-depth while ACP custom-connector support remains pending. |
| **Zone 3** (Enterprise) | Strict ACP allowlist with action-level restrictions (read-only by default); CAB approval and security/legal review for every new connector or new action; mandatory MCP server inventory with named owner; monthly allowlist recertification; Purview Audit alert on any ACP/DLP policy change (Control 1.7). | Customer-facing and regulated-data agents require the highest data-egress assurance and a continuous-monitoring posture aligned with NIST SA-9 and OCC Bulletin 2026-13 (formerly OCC 2011-12). |

---

## Roles & Responsibilities

| Role | Responsibility |
|------|----------------|
| Power Platform Admin | Primary owner — configure and publish ACP and classic DLP policies, manage environment groups, perform `Publish rules` operations, evidence collection |
| Environment Admin | Monitor connector usage and connection inventory within owned environments; raise allowlist-change requests |
| Entra Security Admin | Review consumer/external connector blocklist alignment with Conditional Access and Defender for Cloud Apps policies |
| Purview Compliance Admin | Configure Purview Audit retention and alert policies for ACP/DLP change events (Control 1.7 dependency) |
| AI Governance Lead | Maintain connector allowlist standard, MCP server inventory, and CAB approval cadence for Zone 3 |

---

## Related Controls

| Control | Relationship |
|---------|--------------|
| [2.1 - Managed Environments](../pillar-2-management/2.1-managed-environments.md) | Required dependency - must enable first |
| [2.2 - Environment Groups](../pillar-2-management/2.2-environment-groups-and-tier-classification.md) | Required dependency - groups needed for ACP |
| [1.5 - DLP and Sensitivity Labels](1.5-data-loss-prevention-dlp-and-sensitivity-labels.md) | Complementary control for data protection |
| [1.7 - Audit Logging](1.7-comprehensive-audit-logging-and-compliance.md) | Logs ACP policy enforcement events |
| [2.7 - Vendor Risk Management](../pillar-2-management/2.7-vendor-and-third-party-risk-management.md) | Third-party connectors require vendor assessment |

---

## Implementation Playbooks

!!! info "Step-by-Step Implementation"

    This control has detailed playbooks for implementation, automation, testing, and troubleshooting:

    - [Portal Walkthrough](../../playbooks/control-implementations/1.4/portal-walkthrough.md) — Step-by-step portal configuration
    - [PowerShell Setup](../../playbooks/control-implementations/1.4/powershell-setup.md) — Automation scripts
    - [Verification & Testing](../../playbooks/control-implementations/1.4/verification-testing.md) — Test cases and evidence collection
    - [Troubleshooting](../../playbooks/control-implementations/1.4/troubleshooting.md) — Common issues and resolutions

---

## MCP Server Governance Updates

### Custom MCP Servers and Advanced Connector Policies

> ⚠️ **GA feature:** Copilot Studio custom MCP server integration entered public preview in **March 2026** and reached general availability in **April 2026**. Configuration options, authentication flows, and administrative controls may continue to evolve after GA — verify capabilities against current Microsoft Learn documentation.

Microsoft's release-plan guidance states that custom MCP servers can be built or cloned from existing MCP servers and can assemble connector actions, tools from other MCP servers, and custom APIs into a reusable governed integration surface. ACP supports **MCP server-level blocking** and **DLP policy enforcement**. Note: granular control over individual MCP tools within ACP is not yet available — only server-level blocking is supported. Copilot Studio allows makers and admins to toggle individual MCP tools at the agent level, which is separate from ACP/DLP enforcement.

| Governance point | Control 1.4 implication |
|------------------|-------------------------|
| One custom MCP server can support many agents and use cases | Maintain an approved MCP server inventory with named owner, business purpose, and supported environments |
| Makers can add connector actions, tools from other MCP servers, and custom APIs | Review each exposed tool and API, not just the server name, before promotion to Zone 2 or Zone 3 |
| DLP and access controls apply at server level | Align ACP allowlists and DLP policies at the MCP server level before publish or activation; granular tool-level ACP blocking is not yet available |
| Servers can be reused across Microsoft Copilot, VS Code, Git, Claude, ChatGPT, and other agents | Extend vendor risk and data flow review to every platform that can invoke the same MCP server |

**FSI implementation guidance:**
- Treat each custom MCP server as a governed integration asset subject to [Control 2.7 - Vendor and Third-Party Risk Management](../pillar-2-management/2.7-vendor-and-third-party-risk-management.md)
- Require change tickets for new custom MCP servers or material tool changes in Zone 2 and Zone 3 environments
- Verify DLP policy scope and MCP server-level access controls during promotion testing rather than assuming all cloned MCP servers inherit acceptable defaults

---

## Verification Criteria

Confirm control effectiveness by verifying:

1. Managed Environment is enabled for all regulated environments
2. Environment Group is created with appropriate tier classification
3. ACP is configured with explicit allowlist (blocked connectors unavailable)
4. Action-level restrictions are enforced (write/delete blocked where configured)
5. DLP boundaries prevent cross-group data flows
6. All policy changes appear in Microsoft Purview Audit logs
7. If custom MCP servers are enabled, approved servers and exposed tools are documented and validated against ACP/DLP policy scope
8. Classic DLP policies are active alongside ACP for custom connector and virtual connector governance
9. Service principal connections are covered by environment-level DLP (not just security-group-scoped policies)
10. All approved connector endpoints process and store data within approved US regions

---

## Additional Resources

- [Microsoft Learn: Advanced connector policies](https://learn.microsoft.com/en-us/power-platform/admin/advanced-connector-policies)
- [Microsoft Learn: Enable Managed Environments](https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-enable)
- [Microsoft Learn: Environment groups](https://learn.microsoft.com/en-us/power-platform/admin/environment-groups)
- [Microsoft Learn: Connector Reference](https://learn.microsoft.com/en-us/connectors/connector-reference/)
- [Microsoft Learn: DLP Strategy](https://learn.microsoft.com/en-us/power-platform/guidance/adoption/dlp-strategy)
- [Microsoft Learn: Copilot Studio Planned Features (2026 Wave 1)](https://learn.microsoft.com/en-us/power-platform/release-plan/2026wave1/microsoft-copilot-studio/planned-features)
- [Microsoft Learn: Copilot Studio security and governance](https://learn.microsoft.com/en-us/microsoft-copilot-studio/security-and-governance)

---

*Updated: May 2026 | Version: v1.6.2 | UI Verification Status: Current*
