Where Should a Partner Build Our Copilot Agent? A Dev-to-Production Tenant Guide

By Michael Branson

The Partner Has Asked Where They Should Work

A business unit has picked a partner to build a Copilot Studio agent, and the first real question is not the agent’s design. It is where the partner sits while they build it. The partner’s own tenant is the fastest way to start: no new accounts to provision, no access request to route through security. But the security team has already said no guests in production, and this reader owns the answer either way. Get it wrong toward speed, and controlled data sits in a tenant nobody here can audit or revoke. Get it wrong toward caution with no plan for handoff, and go-live turns into a rebuild, by hand, of everything the partner already built somewhere else. The question this page answers: can a partner build a Copilot agent in a workspace inside your own tenant, and then move it into production?

Quick answer. As of September 2026, the build belongs in your tenant. A partner works in a Power Platform Developer environment inside your own tenant, and the finished agent reaches production as a managed solution through Power Platform pipelines. Microsoft’s own pipelines documentation states plainly: “Can pipelines deploy to a different tenant? No. We recommend using Azure DevOps or GitHub for this scenario.” An agent built in the partner’s own tenant instead arrives as a manual import, with every connection, connection reference and environment variable rebuilt on your side. Keep a partner-owned tenant only for pre-contract demos with no customer data in scope. If your policy keeps every external identity out of the production tenant, a separate development tenant your organization owns works too, and promotion then runs through Azure DevOps or GitHub instead of pipelines, matching what your own vendor-governance page already recommends.

Three Places a Partner Could Build, and Why Two of Them Are Live Options

There are three places this workspace can sit, and only two of them are workable for anything beyond a demo.

The partner’s own tenant is the fastest to stand up and the one a partner will usually ask for first, because it costs them nothing to configure. It is also the option that puts your data somewhere your own security team cannot see, log, or revoke on your own schedule. This is the right choice for exactly one situation: a pre-contract or early-stage demo that uses no real customer data. The moment real data or a production-bound artifact is in scope, this option is closed.

A Power Platform Developer environment inside your own tenant is the default answer for everything else. It is a single-user environment, licensed under the Power Apps Developer Plan, that lives inside your tenant’s own boundary from the first day of work. The partner’s engineers reach it as guests in your directory, not as employees of a tenant you cannot see into, and it is created and destroyed on your own schedule, not theirs.

The third option is a separate development tenant your organization owns, promoted through Azure DevOps or GitHub instead of Power Platform pipelines, for one specific policy position: an organization whose security posture keeps every external identity, full stop, out of anything that touches production. This is not a workaround this page invented. It is the same shape your own Microsoft Vendor Risk Management for Embedded Teams page already recommends for embedded external teams generally: “dedicated development tenants” with “network-level isolation” so external teams “work productively without touching production systems.” The cost of this option is that it gives up Power Platform pipelines entirely for this agent, because pipelines cannot cross a tenant boundary, and the promotion work moves onto a general-purpose CI/CD tool instead of a native one.

Which of the two workable options fits is a policy call this page does not make for you: it is a question about how your organization treats external identity, not a question about Copilot Studio.

What Crosses the Tenant Boundary at Handoff, and What Has to Be Rebuilt

Whichever tenant the build happens in, promotion to production is a solution moving between environments, and only the solution moves. Microsoft’s pipelines FAQ is specific about the payload: “Pipelines deploy solutions as well as configuration for the target environment such as connections, connection references, and environment variables… Pipelines, or solutions in general, don’t contain data stored within Dataverse tables.” Read that twice if the plan on the table assumes test conversations, transcripts or any Dataverse-held content travels with the agent. It does not. Every connection, connection reference and environment variable is validated against the target environment before the deployment runs, which is what catches a missing dependency before it becomes a production incident rather than after.

The practical consequence for a first agent: build inside a solution from the start, not inside whatever the environment hands you by default. The Power Platform ALM basics documentation is explicit that “a single default environment is automatically created for each tenant and shared by all users in that tenant,” and that solutions, not the environment itself, are “used to transport apps and components from one environment to another.” A shared default environment is not where a production-bound Copilot agent belongs even during the build; the agent’s solution is created before the agent is, so the first version already has a home a pipeline can move.

What this section does not cover, because it belongs to a sibling page, is how solution versioning, rollback, and the upgrade-without-overwrite behavior actually work once an agent has shipped more than once, which Power Platform ALM: Maker Solution to Managed Production owns in full; this page assumes the general mechanics and states only what is specific to a Copilot Studio agent’s first promotion.

How Partner Engineers Get Into Your Tenant, and How You Switch Them Off

Inside the workable options, a partner’s engineers typically work in your tenant as B2B guests, and are switched off at handoff. That access is scoped, not blanket. Microsoft Entra’s cross-tenant access settings let you configure organization-specific settings that “take precedence over default settings,” and within those settings you can “scope access to specific users, groups, and applications” rather than trusting an entire partner organization by default. Scoping this way to named users and named applications requires a Microsoft Entra ID P1 license, which the same documentation states directly: “you need a Microsoft Entra ID P1 license. The license is required on the tenant that you configure.”

Revocation is a directory action, not a Copilot Studio setting: remove the guest accounts, or narrow the organizational settings for that partner, and the access that settings scoping granted is gone. Inside the Developer environment itself, a Dataverse security role scoped to that one environment is what actually lets a partner’s engineer build anything at all; that role is assigned when the engagement starts and removed when it ends, independent of whatever the directory-level guest status is doing.

This is an access decision, not a governance program. What auditors expect to see, how approval workflows are tiered, and what a vendor contract has to specify are covered in full on Microsoft Vendor Risk Management for Embedded Teams, and are not repeated here. Guest access for people who will use a finished app, as opposed to engineers building one, is a different question with its own answer on Power Apps for External Users: Architecture and Governance.

What Has to Be True Before the First Agent Is Built

A handful of tenant-level conditions have to be set before the first Copilot Studio agent is worth building, and missing one of them is what turns a planned promotion into a support ticket.

Pipeline target environments have to be managed environments. Microsoft’s pipelines documentation states that “all other environments used in pipelines must be enabled as managed environments” beyond the development and pipelines-host environments, and that “licenses granting premium use rights are required for all managed environments,” which is a licensing consequence worth budgeting for before the first agent, not after. The same page carries a dated change worth planning around now: “Starting February 2026, Microsoft will start enabling managed environments for any pipeline target environments that aren’t already enabled,” with tenants notified through the Microsoft 365 Message center; Microsoft’s own recommendation is to review and enable this ahead of that date rather than let it happen automatically.

Whoever manages the promotion path needs the right role. The pipelines documentation names it directly: “If the user has the ‘Deployment Pipeline Administrator’ security role the ‘Manage pipelines’ button will be enabled.” Assign this role deliberately, to a named admin, rather than discovering after the fact that nobody on the team can open the pipeline configuration app.

What this page does not cover, rollback behavior, solution versioning, and the general managed-environment premium licensing model beyond this one pipeline-target consequence, lives on Power Platform ALM: Maker Solution to Managed Production and Power Platform Environment Strategy: The Four Decisions, linked here rather than restated.

How the Finished Agent Reaches Your Users Once It Is in Production

Getting an agent into a production environment is not the same as getting it in front of the people who are supposed to use it, and Copilot Studio treats those as separate steps. Microsoft’s own publishing documentation describes publishing an agent to channels such as Teams, Microsoft 365 Copilot, a custom website, or SharePoint, and notes that “the latest published content only becomes available after a new session starts,” or after up to an hour otherwise.

For an agent meant to reach the whole organization rather than a small shared group, the documented path is to submit it “for admin approval to be featured in the Built for your org section of the Teams app store,” which also reaches the Microsoft 365 Agent Store’s equivalent section. This is an admin approval workflow, not an automatic rollout: Microsoft’s documentation does not publish a fixed timeline for how long that approval or the resulting org-wide propagation takes, so this is a step to plan into a go-live date with your own admin, not a number this page will invent for you. A smaller, informally shared agent (the “Built with Power Platform” section, available only to explicitly shared users) is a different, narrower distribution path and is not the same as an enterprise-wide release.

What Changes When Your Tenant Is GCC High or DoD

The tenant rule above does not change in a sovereign cloud: the build still belongs in your own tenant, or in a separate development tenant you own, for the same reasons. What changes is the cross-tenant mechanics if a partner’s identities sit in a commercial tenant while yours sits in a government cloud. Microsoft’s own documentation states that “Microsoft cloud settings let you collaborate with organizations from different Microsoft Azure clouds,” naming “Microsoft Azure commercial cloud and Microsoft Azure Government, which includes the Office GCC-High and DoD clouds” as one supported pairing, while also noting plainly that “B2B direct connect isn’t supported for collaboration with Microsoft Entra tenants in a different Microsoft cloud.” Cross-cloud B2B collaboration has to be enabled on both sides before a commercial-tenant partner can be invited into a GCC High or DoD tenant at all, and Copilot Studio agent availability in a given sovereign cloud is its own separate question, confirmed with your Microsoft account team before scoping any of this work.

Whether a given CUI, ITAR, or export-controlled data set may sit in this Developer environment at all is a determination your own contracting officer and your contract’s own clauses make, not a determination this page or Microsoft’s product documentation makes for you.

When You Should Not Let a Partner Build in Your Tenant at All

A partner-owned tenant is the right call, not a compromise, in one situation: a pre-contract or early-stage demo with no customer data in scope. Loading controlled data into a partner’s tenant to save a week of setup time is the trade this page warns against directly, and it is never worth making.

If your organization’s policy keeps every external identity out of anything that touches production, full stop, that is a legitimate position, and the answer is the separate development tenant your organization owns, promoted through Azure DevOps or GitHub, not a forced exception to let a partner into your production tenant’s directory. Accept that trade with its eyes open: you give up the native Power Platform pipelines path for this agent, and someone on your side owns a CI/CD pipeline instead of a built-in one.

Key Takeaways

  • Build the agent in a Power Platform Developer environment inside your own tenant, and promote it to production as a managed solution through Power Platform pipelines; Microsoft’s own documentation states plainly that pipelines cannot deploy to a different tenant.
  • A separate development tenant your organization owns is a real third option when policy forbids any external identity in the production tenant, at the cost of moving promotion onto Azure DevOps or GitHub instead of pipelines.
  • Only the solution and its configuration cross the boundary: connections, connection references and environment variables move and are validated first, and Dataverse table data never travels.
  • A partner’s engineers typically work in your tenant as B2B guests, scoped to specific users and applications under Microsoft Entra ID P1 licensing, and are switched off at handoff by removing that access.
  • Microsoft’s pipelines documentation says “all other environments used in pipelines must be enabled as managed environments” and “licenses granting premium use rights are required for all managed environments”, and that “Starting February 2026, Microsoft will start enabling managed environments for any pipeline target environments that aren’t already enabled”.
  • Reaching the whole organization, not just a shared group, runs through admin approval into the Teams and Microsoft 365 Agent Store “Built for your org” section, on a timeline Microsoft does not publish a fixed number for.
  • The tenant rule does not change in GCC High or DoD, but cross-cloud B2B has to be enabled on both sides first, and Copilot Studio’s availability in a sovereign cloud is confirmed with your Microsoft account team before scoping.
  • Never load controlled data into a partner-owned tenant to save setup time; that tenant is for pre-contract demos only.

Frequently Asked Questions

Is there a smarter way with Microsoft 365 to give a partner an environment in our tenant as their workplace, and then deploy the agent back into our primary organizational tenant?

Yes. The workplace is a Power Platform Developer environment created inside your own tenant, where the partner’s engineers work as scoped Microsoft Entra B2B guests. Deployment back into your primary tenant runs through Power Platform pipelines as a managed solution, because that promotion never has to cross a tenant boundary in the first place; the build and the production environment share the same tenant from day one.

Contact a senior architect once your organization’s tenant-isolation policy is settled and you know which of the two workable options fits it. Bring the policy position, not a product list; the promotion path follows from where the build happens, not the reverse.