Direct‑to‑Engine blocked by tenant permissions – alternatives and PME option

(2) Share

Report

Posted on by RaghuBose Microsoft Employee

I need to use Direct‑to‑Engine (Agents SDK / Power Platform API) for backend integration. This requires acquiring an Entra ID token with the scope: CopilotStudio.Copilots.Invoke.

Our Copilot Studio environment is hosted in the CORP tenant. Admin consent for CopilotStudio.Copilots.Invoke is not allowed in CORP.

What are the recommended alternatives when Direct‑to‑Engine is blocked due to tenant‑level permission restrictions?

Is it recommended to create or migrate the MCS environment into the PME tenant?

Are there any known limitations, governance constraints, or licensing requirements when creating Copilot Studio environments in PME?

Categories:

General topics

I have the same question (0)

All responses (4)

Answers (0)

Sort by

Suggested answer

Valantis 4,819 on at

Like (2)

Report
Copy link

Link copied!

Hi @RaghuBose,

When admin consent for CopilotStudio.Copilots.Invoke is blocked at the tenant level, there are confirmed alternatives for backend integration.

Alternative 1: Direct Line channel (no CopilotStudio.Copilots.Invoke required)
Instead of the Agents SDK / Direct-to-Engine approach, use the Direct Line channel. You get a Direct Line secret from Copilot Studio (Channels > Direct Line), then call the Bot Framework Direct Line REST API from your backend using that secret. No Entra admin consent is required for the backend-to-agent communication. The tradeoff is that you lose the user identity propagation that the Agents SDK provides — messages come in under the Direct Line bot identity rather than the end user's identity.

Alternative 2: Iframe embed (for portal scenarios)
If the use case allows rendering the agent in a browser context, the iframe embed approach doesn't require CopilotStudio.Copilots.Invoke at all. The token exchange for authentication happens on the client side.
Alternative 3: Power Automate intermediary
For server-side integrations, a Power Automate flow can invoke agent flows or run topics via the Copilot Studio API without requiring the user-delegated CopilotStudio.Copilots.Invoke scope.
On the PME tenant question — can you clarify what PME refers to in your context? The answer on whether creating a Copilot Studio environment in a PME tenant is advisable depends on what governance, licensing, and data residency constraints apply there. Once you clarify I can give a direct answer on that part.

Was this reply helpful? Yes No
Suggested answer

11manish 1,953 on at

Like (1)

Report
Copy link

Link copied!

When Direct-to-Engine is blocked due to tenant-level permission restrictions, the recommended approach is to avoid external agent invocation

entirely and instead use Copilot Studio as the orchestration layer, delegating backend operations to Power Automate, custom APIs, or external

services.

Migrating Copilot Studio to a PME tenant is only recommended if you need full control over Entra app consent and governance, but it

introduces licensing, identity separation, and compliance considerations that must be carefully evaluated.

Was this reply helpful? Yes No
Suggested answer

Haque 2,404 on at

Like (2)

Report
Copy link

Link copied!
Hi@RaghuBose,

The big part is "admin consent for the CopilotStudio.Copilots.Invoke permission is not allowed" in your CORP tenant, this creates a significant challenge for using Direct-to-Engine (Agents SDK / Power Platform API) integration from that environment. However, some alternative approache we can try:

Approach-1: If admin consent cannot be granted, consider alternative integration approaches that do not require this permission, such as:

Using Copilot Studio’s built-in connectors and flows without Direct-to-Engine API calls.

Leveraging Power Automate flows triggered by Copilot Studio agents as intermediaries.

Approach-2: Engage your tenant administrators or security team to request an exception or review of the policy blocking admin consent for this permission, explaining the business need and security controls.

Approach-3: If you have access to another tenant (Cross tenant or Multi Tenant) where admin consent can be granted, you might consider registering and consenting the app there, then using that tenant’s identity and tokens to call the API. This requires cross-tenant trust and careful security design.

Approach-4: In parallel, contact Microsoft support or your Microsoft partner to explore if there are any upcoming changes, workarounds, or recommended patterns for this scenario in restricted tenants.

References:

https://www.linkedin.com/pulse/exploring-direct-to-engine-copilot-studio-multi-agent-giorgio-ughini-tmbqf/

https://community.powerplatform.com/forums/thread/details/?threadid=1d271419-a9d5-f011-8544-000d3a53009f

https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/overview-custom-engine-agent

I am sure some clues I tried to give. If these clues help to resolve the issue brought you by here, please don't forget to check the box Does this answer your question? At the same time, I am pretty sure you have liked the response!

Was this reply helpful? Yes No
RaghuBose Microsoft Employee on at

Like (0)

Report
Copy link

Link copied!
Thanks everyone for the detailed responses — this was very helpful. I’m sharing a consolidated view along with a few clarifications from our scenario that might help others facing the same constraint.

Key Constraint : In our case, Direct‑to‑Engine (Agents SDK / Power Platform API) requires: CopilotStudio.Copilots.Invoke (Entra ID delegated permission)

Since admin consent is blocked in the CORP tenant, this prevents using Direct‑to‑Engine entirely.

Also, an important clarification:

Agents SDK supports only Entra ID token-based authentication

It does not support Direct Line–style authentication as a fallback.

Evaluation of Alternatives :

1. Direct Line Channel

Does not require Entra admin consent, which makes it a viable workaround in restricted tenants.

However, in our scenario:

It is not a strong fit for server-side integration

Primarily designed for channel/client interaction patterns

Lacks:

User identity propagation

Enterprise-grade per-request auth context

This is useful as a fallback, but not ideal for backend orchestration scenarios.

2. Copilot Studio as Orchestrator

Keep Copilot Studio as the primary orchestration layer

Delegate backend execution to:

Power Automate

Custom APIs

External services

This aligns well with enterprise governance and avoids restricted permissions.

3. Power Automate / Connector-Based Integration

Use flows or connectors as intermediaries

Enables backend invocation without requiring CopilotStudio.Copilots.Invoke

This is good fit for governed enterprise workflows and standard integration patterns.

4. Tenant Exception / Cross-Tenant Option

Requesting admin consent or using a different tenant where consent is allowed is theoretically possible.

However this introduces governance and security complexity and needs strong justification and approval.

5. PME Tenant Consideration (Clarification from Our Scenario)

In our case:

We are already using the PME tenant to host backend / connector APIs

This provides a controlled surface for server-side integration

However:

Moving Copilot Studio itself to PME is not necessarily required

Should only be considered if:

Direct‑to‑Engine is a hard requirement

Full tenant-level control over Entra permissions is needed

Otherwise, maintaining MCS in CORP and backend services in PME is a more balanced and governance-aligned architecture.

Was this reply helpful? Yes No