Skip to content

Portal Walkthrough: Control 1.28 - Policy-Based Agent Publishing Restrictions

Last Updated: April 2026
Portals: Power Platform Admin Center (PPAC), Microsoft Copilot Studio, Microsoft Purview, Power Automate
Estimated Time: 45–60 minutes (initial setup); 10–15 minutes per environment thereafter

Hedging note: This walkthrough describes how to implement publishing restrictions using the controls Microsoft currently exposes in the portal. Microsoft does not ship a single tenant toggle that "requires approval before publishing a Copilot Studio agent." Approval gates are implemented through Power Automate flows, Power Platform Pipelines, or documented change-control processes. The steps below reflect that reality.

Prerequisites

  • Power Platform Admin role for DLP policy and environment configuration
  • AI Administrator role for tenant-level Copilot Studio governance settings
  • Entra Global Admin required only for initial environment routing setup or broad Graph API consent
  • Approved DLP policy design (connector classification, by zone)
  • Microsoft Purview Audit (Standard or Premium) enabled in the tenant — see Control 3.1
  • Knowledge of which environments are classified as Zone 1, Zone 2, Zone 3 — see Control 2.2

Step 1 — Confirm DLP Enforcement Mode for Copilot Studio Agents

Effective February 2025, Microsoft removed the "Soft-Enabled" DLP exemption for published Copilot Studio agents. All published agents are now evaluated against tenant DLP policy at runtime and at publish/update time. There is no portal toggle to revert this — it is the platform default.

  1. Open Power Platform Admin Center.
  2. Confirm you can see the Policies → Data policies node (requires Power Platform Admin).
  3. Document in your change record that DLP enforcement mode is Enabled (the only supported mode as of February 2025).

FSI Note: For organizations with existing published agents created before February 2025, conduct a DLP compliance review immediately. Agents whose connector usage no longer aligns with the current DLP policy are blocked from update operations until the violation is resolved or the policy is amended.

Step 2 — Create a Zone-Specific Data Policy

Repeat this step once per zone (Zone 1, Zone 2, Zone 3). The escalating restriction profile is described in the parent control.

  1. In PPAC, go to Policies → Data policies.
  2. Select + New policy.
  3. Name: Use a clear, zone-aligned name (e.g., FSI - Zone 3 Enterprise Restricted).
  4. On the Prebuilt connectors tab, classify connectors into Business, Non-Business, and Blocked groups. Recommended starting baseline:
Zone Business (allow) Non-Business Blocked
Zone 1 SharePoint, OneDrive, Office 365 Outlook, Teams, Dataverse Approved productivity connectors Public-channel and consumer connectors (Telegram, Facebook Messenger, public-website connector)
Zone 2 Same as Zone 1 plus business systems (e.g., SQL Server, Salesforce per risk review) (intentionally empty) All Zone 1 blocked + Twitter/X, RSS, generic HTTP unless allowlisted via custom connector
Zone 3 Read-only or scoped variants of Zone 2 business systems only, gated by data risk review (intentionally empty) Everything else, including premium connectors not on the approved list
  1. On the Custom connectors tab, set the default action (typically Block) and add explicit URL patterns for any allowlisted custom connectors (e.g., https://api.contoso.com/*).
  2. On the Scope tab, choose Add multiple environments and select the environments classified to this zone. Avoid Add all environments for production-bearing zones; explicit selection is auditable.
  3. Review and Create policy.

Tip: Because there is no native concept of a "wildcard" connector identifier in DLP policies, do not attempt to block "all unknown connectors" via wildcard. Use the Custom connectors → Default behavior = Block setting plus the Non-Business group as your allowlist boundary.

Step 3 — Verify the Pre-Publish Behavior in Copilot Studio

Copilot Studio runs a pre-publish check that surfaces DLP violations and configuration findings before the agent is published. This is the platform's primary inline enforcement signal.

  1. Open Microsoft Copilot Studio and select an agent in a target environment.
  2. Click Publish.
  3. Review any pre-publish messages. Typical findings include:
  4. DLP violation (connector used by the agent is in the Blocked group for this environment).
  5. Channel configuration that conflicts with policy (e.g., a public channel enabled in a Zone 2/3 environment).
  6. If findings appear, follow the in-product remediation links or address each finding in the agent topics, channels, or DLP policy before retrying publish.

UI variability: The exact wording, severity icons, and finding categories shown in the Copilot Studio publish dialog change as Microsoft ships product updates. Treat the in-product messages as authoritative; this playbook describes the categories of finding rather than fixed colors or labels.

Step 4 — Restrict Channels in Copilot Studio (Zone 2 and Zone 3)

For Zone 2+ agents, disable channels that are not on your approved list before publishing.

  1. In Copilot Studio, open the target agent.
  2. Go to Settings → Channels (or Channels in the left rail, depending on the current build).
  3. Disable any channel not on your approved list — at minimum, disable Facebook, Telegram, and the public Website (anonymous) channel for Zone 2+.
  4. For Zone 3 customer-facing agents, restrict to authenticated channels only (e.g., Microsoft Teams, authenticated web channel).
  5. Save channel settings.

Step 5 — Implement an Approval Gate (Power Automate Approach)

Because Copilot Studio does not surface a built-in "require approval" toggle, model the approval gate using a Power Automate flow that watches for changes to the Dataverse bot table (Copilot Studio agents are stored as bot rows) or that is triggered from a custom intake form.

  1. Open Power Automate.
  2. Create a new automated cloud flow.
  3. Trigger: Dataverse — When a row is added, modified, or deleted on the Bots table; scope to the target environment(s).
  4. Add a Get a row by ID action to retrieve the bot record.
  5. Add a Condition to check whether Publish Status indicates a publish or republish event.
  6. Add Start and wait for an approval (Approval type: Approve/Reject — First to respond).
  7. Route the approval to the designated approver group (Power Platform Admin or, for Zone 3, Power Platform Admin and Compliance Officer in sequential approvals).
  8. On rejection, post a Teams message to the agent author and write an event to a Dataverse Publish Approval Log table for audit.
  9. On approval, write the approval record (approver, timestamp, justification) to the same log table.

Important: A Power Automate approval flow does not technically prevent the publish action itself — it provides documented review and an audit trail. To prevent unauthorized publishes outright, combine the flow with one of: (a) restricting prvPublishBot privileges via Dataverse security roles (see Control 1.1), (b) using Power Platform Pipelines so authoring happens in a non-production environment, or (c) Conditional Access policies that block the Copilot Studio app for non-approver personas.

Step 6 — Implement a Solution Promotion Pipeline (Zone 3)

For Zone 3 environments, use Power Platform Pipelines (or ALM Accelerator) so that Copilot Studio agents are authored in a development environment, validated in a test environment, and deployed to production via solution import — not by publishing directly into production.

  1. In PPAC, go to Resources → Pipelines and create a host environment if you do not yet have one.
  2. Create a pipeline with Development → Test → Production stages mapped to your Zone 3 environments.
  3. On the Test → Production stage, configure pre-deployment approvals (this is a built-in Pipelines feature) and route to the Compliance Officer.
  4. Train Zone 3 agent authors to package the agent in a solution and submit a deployment request through the pipeline rather than clicking Publish in the production environment.
  5. Combine with Control 2.2 (Environment Groups and Tier Classification) to restrict who can author or publish directly in the production environment.

Hedging note: Power Platform Pipelines provides solution-promotion approval gates. It does not prevent a user with sufficient privileges in the production environment from publishing an agent in place. Pair pipelines with the role restrictions in Control 1.1 to make direct production publish operationally infeasible.

Step 7 — Confirm Audit Logging in Microsoft Purview

  1. Open Microsoft Purview → Audit.
  2. Confirm auditing is enabled (it is on by default for new tenants since 2023).
  3. Run a search for activities related to Copilot Studio publishing. Useful filters:
  4. Workload: PowerPlatformAdmin and Dataverse.
  5. Activities: bot create/update events, DLP policy change events, Power Automate approval events.
  6. Confirm that the events captured include the actor UPN, environment, timestamp, and the bot identifier.
  7. Validate that retention policies for audit data meet your firm's requirements (e.g., 7-year retention for FINRA 4511 / SEC 17a-4 alignment — see Control 3.1).

Configuration by Governance Level

Setting Baseline (Zone 1) Recommended (Zone 2) Regulated (Zone 3)
DLP policy assignment Light restrictions Restrictive (no Non-Business group) Strict allowlist only
Pre-publish findings Acknowledged Must be cleared Must be cleared + reviewer sign-off
Approval gate Optional Power Automate flow or change ticket Multi-stage (Power Automate or Pipelines)
Channel restrictions Recommended Public channels disabled Authenticated channels only
Environment separation Single environment OK Dev + Prod recommended Dev + Test + Prod with Pipelines
Publishing documentation Recommended Required (lightweight) Required with formal sign-off

Validation

After completing these steps, confirm:

  • At least one DLP policy exists per zone, with environments explicitly assigned.
  • The Copilot Studio pre-publish check produces a finding when an agent uses a Blocked connector (test in a non-production environment — see the verification playbook).
  • Public channels are disabled for all Zone 2+ agents.
  • A Power Automate approval flow is active for Zone 2+ environments, or an equivalent process control is documented.
  • Power Platform Pipelines stages exist for Zone 3 environments with pre-deployment approval configured.
  • Purview audit captures bot create/update events and DLP policy changes for the relevant environments.

Visual Reference (where to find each setting)

Setting Location
DLP data policies PPAC → Policies → Data policies
Environment assignment to a policy PPAC → Policies → Data policies → [Policy] → Scope
Custom connector default behavior PPAC → Policies → Data policies → [Policy] → Custom connectors
Copilot Studio pre-publish dialog Copilot Studio → [Agent] → Publish
Channel configuration Copilot Studio → [Agent] → Settings → Channels
Power Platform Pipelines PPAC → Resources → Pipelines
Audit search Microsoft Purview → Audit

Back to Control 1.28 | PowerShell Setup | Verification & Testing | Troubleshooting

Updated: April 2026 | Version: v1.4.0 | UI Verification Status: Current