# Control 1.28: Policy-Based Agent Publishing Restrictions

**Control ID:** 1.28<br>
**Pillar:** Security<br>
**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)<br>
**Last UI Verified:** April 2026<br>
**Governance Levels:** Baseline / Recommended / Regulated<br>

---

!!! note "DLP Enforcement Now Mandatory for Published Agents"
    As of February 2025, Microsoft removed the DLP "Soft-Enabled" exemption for published Microsoft 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 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

---

!!! info "No companion solution by design"
    Not all controls have a companion solution in [FSI-AgentGov-Solutions](https://github.com/judeper/FSI-AgentGov-Solutions); solution mapping is selective by design. This control is operated via native Microsoft admin surfaces and verified by the framework's assessment-engine collectors. See the [Solutions Index](../../reference/solutions-index.md#coverage-scope) for the 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)** — 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)
2. **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
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 surface pre-publish security warnings; agent authors may publish after acknowledging warnings. Zone 2 environments require DLP compliance, passing pre-publish security checks, 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.

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** — Implement publish-time approval as a Power Automate flow (triggered on Dataverse `bot` table create/update events) or as a Power Platform Pipelines stage gate; Copilot Studio does not currently provide a built-in "require approval to publish" admin toggle, so approval is enforced through surrounding workflow tooling and audit review
- **Environment groups and pipelines** — Implement environment separation (dev/test/prod) using Power Platform environment groups and Power Platform Pipelines (or ALM Accelerator); pipeline stages help prevent direct-to-production publishing by requiring solution promotion through lower environments (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; 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 |

---

## Related Controls

| Control | Relationship |
|---------|--------------|
| [2.3 - Change Management and Release Planning](../pillar-2-management/2.3-change-management-and-release-planning.md) | Broader deployment lifecycle framework that includes publishing restrictions as a validation gate |
| [1.1 - Restrict Agent Publishing by Authorization](1.1-restrict-agent-publishing-by-authorization.md) | Role-based publishing permissions that complement policy-based restrictions |
| [2.2 - Environment Groups and Tier Classification](../pillar-2-management/2.2-environment-groups-and-tier-classification.md) | Environment separation framework that enables dev→test→prod promotion pipelines |
| [2.12 - Supervision and Oversight FINRA 3110](../pillar-2-management/2.12-supervision-and-oversight-finra-rule-3110.md) | Supervisory review framework that includes agent publishing oversight for customer-facing agents |

---

## Implementation Playbooks

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

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

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

---

## 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. Security scans are enabled and triggered automatically before publishing; Zone 2+ agents cannot be published with failing security scans
3. Approval workflows are configured and operational for Zone 2+ environments (via Power Automate flow on Dataverse `bot` events, Power Platform Pipelines stage gate, or documented change-ticket process); publishing requests have documented approval before proceeding
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

- [Microsoft Learn: Data loss prevention policies (Power Platform)](https://learn.microsoft.com/en-us/power-platform/admin/wp-data-loss-prevention)
- [Microsoft Learn: DLP for Copilot Studio agents (troubleshooting)](https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-dlp-troubleshooting)
- [Microsoft Learn: Copilot Studio security and governance](https://learn.microsoft.com/en-us/microsoft-copilot-studio/security-and-governance)
- [Microsoft Learn: Power Platform Pipelines (ALM)](https://learn.microsoft.com/en-us/power-platform/alm/pipelines)
- [Microsoft Learn: Power Platform environment groups](https://learn.microsoft.com/en-us/power-platform/admin/environment-groups)
- [Microsoft Learn: Microsoft Purview audit logging](https://learn.microsoft.com/en-us/purview/audit-solutions-overview)

### 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.

!!! tip "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: May 2026 | Version: v1.6.2 | UI Verification Status: Current*
