Skip to content

Control 1.28: Policy-Based Agent Publishing Restrictions

Control ID: 1.28
Pillar: Security
Regulatory Reference: SOX 302/404, FINRA 3110, FINRA RN 24-09, OCC Bulletin 2026-13 (formerly OCC 2011-12), Fed SR 26-2 (formerly SR 11-7)
Last UI Verified: May 2026
Governance Levels: Baseline / Recommended / Regulated

DLP Enforcement Now Mandatory for Published Agents

Microsoft documents removal of agent DLP exemptions since March 2025. Data policies apply to draft and published Microsoft Copilot Studio agents; violations can block publishing and disrupt runtime with DataLossPreventionViolation errors. See Microsoft Learn: troubleshooting data policy enforcement. 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 and using configured release gates when security findings or approval requirements are unresolved based on governance zone classification.

Why This Matters for FSI

Regulation How this control supports it
SOX 302/404 Publishing restrictions help meet internal control requirements by enforcing documented change management and helping prevent...
FINRA 3110 Policy-based publishing aids in meeting supervisory obligations by requiring approval and review before customer-facing agents...
OCC Bulletin 2026-13 (formerly OCC 2011-12) Publishing enforcement supports third-party risk management principles by ensuring agents using external connectors undergo...
Fed SR 26-2 (formerly SR 11-7) Publishing controls help meet model risk management requirements by establishing a validation gate that confirms agents meet...
Regulatory mapping — click to expand
  • 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 Bulletin 2026-13 (formerly 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 26-2 (formerly 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

No companion solution for this control — see the Solutions Index for the full companion-solution catalog and coverage scope.

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:

  1. DLP policy enforcement (mandatory) — Data policies apply during authoring, publishing, and runtime. Published agents with violations can fail at runtime as well as be blocked from republishing; exemptions are no longer supported since March 2025.
  2. Security scan review — Copilot Studio automatically warns makers before publishing when an agent uses No authentication, connector/flow Maker-provided credentials, or organization-wide sharing. These documented security scan warnings are distinct from DLP enforcement; Zone 2+ release processes require findings to be resolved or formally reviewed. Do not assume a native zone-specific pass/fail gate or acknowledgment checkbox. For agents or agent flows powered by the standard harness, individual channels can appear disabled when governance policies or authentication configuration block them. See Publish and deploy agents.
  3. Approval workflow gates (process control) — Copilot Studio does not currently expose a built-in tenant toggle that requires admin approval before an agent is published. Zone 2+ environments should implement approval gates as a process control using Power Automate approval flows triggered on agent publish/update events, Power Platform Pipelines for solution promotion, or Microsoft Purview audit rules that surface unauthorized publishes for after-the-fact remediation. Approval records (approver identity, timestamp, justification) are captured in the supporting workflow tooling, not in the Copilot Studio publish dialog itself

The enforcement model escalates by governance zone. Zone 1 environments enforce DLP policies and require authors to review pre-publish security warnings. Zone 2 environments require DLP compliance, review of pre-publish security findings, and documented approval (via Power Automate flow, Power Platform Pipelines, or change-ticket evidence) before publishing. Zone 3 environments add multi-level approval, formal security review sign-off, and an enforced solution promotion pipeline (dev→test→prod) using Power Platform Pipelines or ALM Accelerator to help prevent agents from being published directly to production environments. A flow triggered after a publish/update event is detective, not preventive; production access restrictions and configured pipeline gates provide the release boundary.

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 review (organization's release process) Review warnings Resolve/review findings Resolve/review findings + formal sign-off
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 review — Review automatic warnings about unauthenticated access, maker-provided credentials, and organization-wide sharing; enforce the organization's review decision through the release process, not an assumed scan-enablement toggle
  • Approval workflow configuration — Use an explicit intake flow/change ticket or a configured Power Platform Pipelines gate for pre-release approval. A Dataverse bot create/update trigger is not a documented publish-status trigger and does not prevent publishing. Copilot Studio's documented Publish flow does not include a native admin-approval toggle
  • Environment groups and pipelines — Use environment groups to organize governance rules and Power Platform Pipelines to promote solutions between dev/test/prod. In a custom host, configure stage extensions and approval/status-update logic; restrict direct production authoring separately
  • Channel restrictions — Use the exact Copilot Studio DLP connector names, including Direct Line channels in Copilot Studio for website/Direct Line channels and Facebook channel in Copilot Studio for Facebook. Telegram uses Azure Bot Service channels; do not assume blocking a Telegram service connector enforces a standalone Copilot Studio channel restriction
  • Publishing audit logs — Capture BotUpdateOperation-BotPublish in Microsoft Purview; preserve DLP violation workbooks, security warnings, and approval records separately in the supporting evidence stores; retain logs per regulatory requirements

Zone-Specific Requirements

Zone cross-reference

Baseline = Zone 1 (Personal Productivity) · Recommended = Zone 2 (Team Collaboration) · Regulated = Zone 3 (Enterprise Managed). Zone requirements below correspond to the Governance Level in the control header.

Zone Requirement Rationale
Zone 1 (Personal) DLP policies enforced; security scan warnings reviewed through the release process; 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; pre-publish security checks must pass; documented approval (via Power Automate flow, pipeline gate, or change ticket) before publishing; channel restrictions enforced; monthly publishing review Shared team agents may be used in workflows involving customer data; approval gates help reduce the risk of unauthorized deployments
Zone 3 (Enterprise) DLP compliance mandatory; security review sign-off required; multi-level approval (Power Automate or pipeline approvals); solution promotion pipeline (dev→test→prod) using Power Platform Pipelines or ALM Accelerator; channel allowlist only; formal publishing documentation; per-deployment review Customer-facing and regulated agents require maximum oversight; pipeline-based promotion helps prevent untested agents from reaching production

Roles & Responsibilities

Role Responsibility
Power Platform Admin Configure tenant DLP policies; assign DLP policies to environments by zone; configure environment groups and Power Platform Pipelines; review and approve publishing requests for Zone 2+ agents; monitor DLP compliance across environments
AI Administrator Configure tenant-level Copilot Studio governance settings; coordinate Copilot agent feature rollouts; review pre-publish security findings escalated by agent authors
Entra Global Admin Establish initial environment routing and tier classification; delegate ongoing administration to Power Platform Admin and AI Administrator following least-privilege principles
Copilot Studio Agent Author Submit agents for approval; resolve DLP violations before publishing; document agent purpose and connector usage; respond to pre-publish security findings
Compliance Officer Review and approve publishing requests for Zone 3 agents; verify alignment with regulatory requirements; validate connector usage against the documented risk assessment
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:

Verification Criteria

Confirm control effectiveness by verifying:

  1. DLP policies are configured and assigned to all environments based on zone classification; DLP violations prevent agent publishing
  2. Automatic security scan warnings are reviewed; Zone 2+ release gates require documented resolution or review before publishing, independently of mandatory DLP blocks
  3. Approval workflows are operational for Zone 2+ environments (explicit intake, configured Power Platform Pipelines gate, or change-ticket process), with production access restrictions; publishing requests have documented approval before proceeding, not only after a bot row changes
  4. Environment separation (dev/test/prod) is implemented for Zone 3 environments with Power Platform Pipelines or ALM Accelerator promoting solutions between stages
  5. Channel restrictions are enforced via DLP policies for Zone 2+ environments; public channels are blocked or whitelisted
  6. Publishing audit logs are captured in Microsoft Purview and retained per regulatory requirements
  7. An up-to-date inventory of published agents exists with publishing approval records, DLP compliance status, and last deployment date

Additional Resources

FSI Scope Note

DLP Enforcement for Published Agents (March 2025): Microsoft documents removal of agent exemptions since March 2025. 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 or disrupted at runtime due to DLP violations. Enforcement applies to 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: October 2026 | Version: v1.6.2 | UI Verification Status: Current (Microsoft Learn claims verified 2026-10-14; tenant UI last verified May 2026)