Official documentation checked October 14, 2026.
An “authentication failed” message in a published Copilot Studio agent does not identify one universal cause. User sign-in, a tool’s connection to another service, and the channel configuration are separate layers. Repair the failing layer instead of creating new app registrations, adding broad Graph permissions, or disabling authentication until the error disappears.
These checks are for an authorized agent maker working with the organization’s identity or Power Platform administrator. Keep client secrets, access tokens, connection credentials, and sign-in codes out of tickets, screenshots, support chat messages, and website source code.
1. Identify which authentication step is failing
Record the agent and environment, published version or last publish time, channel, affected account, and timestamp with time zone. Capture the complete error code and correlation or request ID if shown. Do not assume a maker’s successful test proves that another user’s published session has the same permissions.
- Failure before any conversation: investigate channel availability, agent sharing, and the agent’s sign-in configuration.
- Failure after a sign-in card or identity-provider page: inspect the actual identity-provider error and the corresponding app configuration.
- Failure only when a particular tool runs: inspect that tool’s connection, credentials mode, authorization, and supported channel. Agent sign-in alone does not establish access to the tool’s service.
Reproduce with a harmless question that does not invoke a business action, then with an approved read-only tool test if appropriate. Record the transition that fails. Do not test a payment, deletion, or account-reset action simply to check authentication.
2. Match the agent’s authentication mode to its channel
Open the agent’s Settings > Security > Authentication and record the current mode before editing it. Microsoft’s current authentication guidance identifies Authenticate with Microsoft as the supported option for the Teams + Microsoft 365 channels. Authenticated deployment to other channels can require Authenticate manually.
Do not apply a legacy manual OAuth recipe to every Teams agent. Check the actual channel and agent type; Microsoft documentation includes different generations of agent and authentication guidance. If your existing configuration does not match the current channel guidance, have the platform owner confirm the migration path before changing production.
Switching modes can invalidate topics that use authentication variables. For example, User.AccessToken and User.IsLoggedIn are not available with Authenticate with Microsoft. Resolve any affected topic errors before publishing a planned change.
Authentication changes require publication to affect the live agent. Do not select No authentication as a troubleshooting bypass: it changes who can interact with the agent and can break tools requiring user authentication.
3. For manual authentication, inspect the existing registration precisely
Only follow this section if the confirmed channel uses manual authentication. Find the app registration by its actual application/client ID and tenant, not just a familiar display name. Do not create a replacement registration merely because you cannot see the existing one; first check directory selection and your administrative access.
The Entra authentication setup for standard-harness agents documents regional redirect URLs and recommends Microsoft Entra ID V2 with federated credentials where applicable. Compare the registration with the Redirect URL displayed by your agent rather than assuming one global redirect fits every deployment.
- For a redirect mismatch, compare the exact URL and platform registration with the documented configuration for this agent.
- For federated credentials, verify the issuer and value against those generated for the intended agent. Do not substitute values from another environment.
- For an existing client-secret configuration, check whether the secret actually expired or was replaced. Copilot Studio needs the secret’s value, not its identifier. Arrange any necessary rotation securely with the owner; avoid breaking other consumers of the same credential.
- Request only the delegated permissions or scopes needed for the specific source and action. A generic sign-in failure is not justification for adding calendar, file, or tenant-wide permissions.
Use the designated secure configuration fields. An Entra client secret is not a Direct Line channel secret and must not be copied into browser JavaScript, an embed URL, or a channel setting just because both are called “secrets.” A planned authentication redesign deserves its own test and rollback, rather than an unreviewed production conversion.
4. Check tool connections and access policies, then republish and validate
For a tool-specific failure, Microsoft’s tool authentication guidance distinguishes user authentication from author-provided credentials and lists channel limitations. Use the intended user’s supported connection flow and retry after it succeeds. Do not switch a restricted-data tool to a maker’s more privileged connection merely to suppress an error.
A tool that works on a supported custom website may not support the demo website or every other channel. Teams tool authentication can also require the documented SSO configuration. Check this layer separately from the agent-level authentication mode.
If Entra reports a policy block, an authorized administrator can inspect Entra ID > Monitoring & health > Sign-in logs, locate the actual event, and review its resource, authentication details, device information, and Conditional Access result. Microsoft’s sign-in troubleshooting guidance explains this evidence-based route. Meet the intended MFA or device requirement; do not create a broad exception for the agent or treat a redirect URL as a Conditional Access allow rule.
After an approved correction, save and publish the agent, then start a new conversation in the affected published channel. Verify ordinary conversation, the specific read-only tool, an authorized test user, and the expected denial for a user without access. A working authoring test alone is not the acceptance criterion.
If it still fails, send support the sanitized error, environment and channel, publish time, authentication mode, and whether failure occurs before sign-in or at a specific tool. Retain the current configuration for rollback and avoid unrelated secret rotation or permission expansion.