A custom agent's background service calls a published Copilot Studio agent through the Copilot Studio client library. The service obtains its token with the client credentials flow from an app registration that has a client secret, and every call is rejected as unauthorized. The Copilot Studio agent uses Authenticate with Microsoft. What is the most likely fix?
Select an answer to reveal the explanation.
Short Explanation
Picture a building that only lets in badge holders who are people, and you keep showing up with a delivery robot's badge. The client library wants a user's delegated token with the Copilot Studio invoke permission, and an app-only token from client credentials won't get through. Ownership tweaks and channel settings don't change who the token represents.
Full Explanation
The Copilot Studio client library authenticates with a Microsoft Entra ID token issued for a signed-in user. The app registration needs the delegated CopilotStudio.Copilots.Invoke permission from the Power Platform API, and the token must be acquired through a user flow such as interactive sign-in or on-behalf-of. A client credentials token represents the application itself, and service-to-service authentication is not supported for this path, so the agent rejects the call no matter how the agent is configured. Adding the app registration as a co-owner changes who can edit the agent, not which token types the runtime accepts. The Dataverse user_impersonation permission targets the Dataverse API, a different resource from the one that invokes Copilot Studio agents, so the token would still be wrong. Web channel secured access protects Direct Line traffic with channel secrets and has no effect on client library calls. Exam caveat: when a scenario truly has no user, Microsoft points to Direct Line as the alternative integration path. Operational check: decode the token, confirm it contains a user identity and the Copilot Studio invoke scope rather than an application role claim, and retry the conversation start.