Control 1.28: Policy-Based Agent Publishing Restrictions
Control ID: 1.28 Pillar: Security Regulatory Reference: SOX 302/404, FINRA 3110, OCC 2011-12, Fed SR 11-7 Last UI Verified: February 2026 Governance Levels: Baseline / Recommended / Regulated Last Verified: 2026-02-12
DLP Enforcement Now Mandatory for Published Agents
As of February 2025, Microsoft removed the DLP "Soft-Enabled" exemption for published Copilot Studio agents. All published agents must comply with tenant DLP policies—agents with DLP violations are blocked from updates until violations are resolved. This control establishes a policy-based publishing enforcement model that helps prevent agents from reaching production without meeting security, compliance, and approval requirements. It complements Control 1.1 (Restrict Agent Publishing by Authorization) which focuses on role-based publishing permissions, and Control 2.3 (Change Management and Release Planning) which governs the broader deployment lifecycle.
Objective
Enforce policy-based restrictions on agent publishing to support compliance with FSI change management and security requirements by blocking publication when DLP violations exist, security scans fail, or approval workflows are not completed based on governance zone classification.
Why This Matters for FSI
- SOX 302/404: Publishing restrictions help meet internal control requirements by enforcing documented change management and helping prevent unauthorized deployment of agents that could impact financial reporting or disclosure controls
- FINRA 3110: Policy-based publishing aids in meeting supervisory obligations by requiring approval and review before customer-facing agents enter production, supporting oversight of AI-generated communications
- OCC 2011-12: Publishing enforcement supports third-party risk management principles by ensuring agents using external connectors undergo security review before deployment in regulated environments
- Fed SR 11-7: Publishing controls help meet model risk management requirements by establishing a validation gate that confirms agents meet testing, documentation, and approval standards before production deployment
Control Description
Policy-based agent publishing restrictions provide a multi-layered enforcement model that helps prevent Copilot Studio agents from being published when governance, security, or compliance conditions are not met. This control operates at three enforcement layers that escalate by governance zone:
- DLP policy enforcement (mandatory) — All agents must comply with tenant Data Loss Prevention (DLP) policies before publishing; published agents with DLP violations are blocked from updates until violations are resolved; no exemptions exist for legacy or production agents (enforced since February 2025)
- Security scan validation — Copilot Studio automatically triggers security scans before publishing; scans check for insecure connector usage, blocked channels (public websites, Telegram, Facebook), and configuration vulnerabilities; Zone 2+ requires passing scans before publishing
- Approval workflow gates — Zone 2+ environments require explicit approval from Power Platform Admin or designated approvers before agents can be published; approval workflows capture approver identity, timestamp, and justification for audit trails
The enforcement model escalates by governance zone. Zone 1 environments enforce DLP policies and display security scan warnings, but allow agent authors to publish after acknowledging warnings. Zone 2 environments require DLP compliance, passing security scans, and documented approval from a Power Platform Admin or designated reviewer before publishing is permitted. Zone 3 environments mandate DLP compliance, security review sign-off, multi-level approval workflows, and environment promotion pipelines (dev→test→prod) that enforce separation between development and production publishing.
Organizations should implement this control when Copilot Studio agents transition from development to production use, when agents handle customer data or regulated workflows, or when regulatory requirements mandate change control processes for AI deployments.
Capability Comparison by Zone
| Capability | Zone 1 (Personal) | Zone 2 (Team) | Zone 3 (Enterprise) |
|---|---|---|---|
| DLP enforcement | Mandatory | Mandatory | Mandatory |
| Security scan requirement | Warning only | Must pass | Must pass + formal review |
| Approval workflow | Not required | Required (single approver) | Required (multi-level) |
| Environment promotion | Not required | Recommended | Required (dev→test→prod) |
| Channel restrictions | Recommended | Enforced (block public) | Enforced (whitelist only) |
| Publishing documentation | Recommended | Required | Required with sign-off |
| Rollback capability | Recommended | Required | Required with audit trail |
| Publishing review cadence | Quarterly | Monthly | Per-deployment |
Key Configuration Points
- Tenant DLP policies — Configure DLP policies in Power Platform Admin Center to group connectors by Business/Non-Business/Blocked categories; DLP violations prevent agent publishing and block updates to published agents
- Environment DLP policy assignment — Assign DLP policies to specific environments based on zone classification; Zone 3 environments require the strictest DLP policy with minimal allowed connectors
- Security scan enablement — Ensure security scans are enabled in Copilot Studio (default behavior); scans automatically check for blocked channels, insecure connectors, and configuration issues before publishing
- Approval workflow configuration — Configure environment-level approval workflows using Power Platform Admin Center or Power Automate; require approval for agent publishing operations in Zone 2+ environments
- Environment groups and routing — Implement environment separation (dev/test/prod) with environment groups; enforce promotion pipelines that require re-approval for production publishing (Zone 3)
- Channel restrictions — Configure DLP policies to block public channels (public websites, Telegram, Facebook) in Zone 2+ environments; whitelist only approved channels for Zone 3 customer-facing agents
- Publishing audit logs — Enable audit logging in Microsoft Purview to capture publishing events, approvals, DLP violations, and security scan results; retain logs per regulatory requirements
Zone-Specific Requirements
| Zone | Requirement | Rationale |
|---|---|---|
| Zone 1 (Personal) | DLP policies enforced; security scan warnings displayed; publishing allowed after acknowledgment; quarterly publishing review | Personal productivity agents present lower compliance risk; DLP enforcement helps prevent data exfiltration while allowing experimentation |
| Zone 2 (Team) | DLP compliance required; security scans must pass; documented approval workflow required before publishing; channel restrictions enforced; monthly publishing review | Shared team agents may be used in workflows involving customer data; approval gates reduce risk of unauthorized deployments |
| Zone 3 (Enterprise) | DLP compliance mandatory; security review sign-off required; multi-level approval workflow; environment promotion pipeline (dev→test→prod) enforced; channel whitelist only; formal publishing documentation; per-deployment review | Customer-facing and regulated agents require maximum control over deployment; environment separation helps prevent untested agents from reaching production |
Roles & Responsibilities
| Role | Responsibility |
|---|---|
| Power Platform Admin | Configure tenant DLP policies; assign DLP policies to environments; review and approve publishing requests for Zone 2+ agents; monitor DLP compliance across environments |
| Entra Global Admin | Configure environment routing and tier classification; establish approval workflows for Zone 3 environments; enforce environment separation policies |
| Copilot Studio Agent Author | Submit agents for approval; resolve DLP violations before publishing; document agent purpose and connector usage; respond to security scan findings |
| Compliance Officer | Review and approve publishing requests for Zone 3 agents; verify compliance with regulatory requirements; validate connector usage against risk assessment |
Related Controls
| Control | Relationship |
|---|---|
| 2.3 - Change Management and Release Planning | Broader deployment lifecycle framework that includes publishing restrictions as a validation gate |
| 1.1 - Restrict Agent Publishing by Authorization | Role-based publishing permissions that complement policy-based restrictions |
| 2.2 - Environment Groups and Tier Classification | Environment separation framework that enables dev→test→prod promotion pipelines |
| 2.12 - Supervision and Oversight FINRA 3110 | Supervisory review framework that includes agent publishing oversight for customer-facing agents |
Implementation Playbooks
Step-by-Step Implementation
This control has detailed playbooks for implementation, automation, testing, and troubleshooting:
- Portal Walkthrough — Step-by-step portal configuration
- PowerShell Setup — Automation scripts
- Verification & Testing — Test cases and evidence collection
- Troubleshooting — Common issues and resolutions
Verification Criteria
Confirm control effectiveness by verifying:
- DLP policies are configured and assigned to all environments based on zone classification; DLP violations prevent agent publishing
- Security scans are enabled and triggered automatically before publishing; Zone 2+ agents cannot be published with failing security scans
- Approval workflows are configured and enforced for Zone 2+ environments; publishing requests require documented approval before proceeding
- Environment separation (dev/test/prod) is implemented for Zone 3 environments with promotion pipelines enforced
- Channel restrictions are enforced via DLP policies for Zone 2+ environments; public channels are blocked or whitelisted
- Publishing audit logs are captured in Microsoft Purview and retained per regulatory requirements
- An up-to-date inventory of published agents exists with publishing approval records, DLP compliance status, and last deployment date
Additional Resources
- Microsoft Learn: Data loss prevention policies
- Microsoft Learn: Copilot Studio security and governance
- Microsoft Learn: Power Platform environments overview
- Microsoft Learn: Microsoft Purview audit logging
FSI Scope Note
DLP Enforcement for Published Agents (February 2025): This control became significantly more stringent with Microsoft's removal of the "Soft-Enabled" DLP exemption for published agents. Organizations should implement this control when:
- Copilot Studio agents are being published to production environments for the first time
- Existing published agents need to be updated (DLP violations will block updates until resolved)
- Agents use external connectors or channels that may pose data exfiltration risks
- Regulatory requirements mandate change control, approval, or security review before AI deployment
For organizations with existing published agents, conduct a DLP compliance audit immediately to identify agents that may be blocked from future updates due to DLP violations. The February 2025 enforcement change applies retroactively to all published agents—there are no legacy exemptions.
Complement with Environment Strategy
Publishing restrictions are most effective when paired with a robust environment separation strategy. Implement Control 2.2 (Environment Groups and Tier Classification) to establish dev/test/prod environments, then use this control to enforce approval gates between tiers. This layered approach helps ensure agents undergo testing, security review, and approval before reaching production users.
Updated: February 2026 | Version: v1.2 | UI Verification Status: Current