Plan identity strategy

A maker publishes an agent to the company intranet, watches it greet everyone by name in the test pane, and then finds that in production it greets nobody and its Dataverse tool returns nothing. Nothing is broken. The agent was left on Authenticate with Microsoft, which covers the Microsoft-identity channels and not a custom website, so on that intranet page there is no signed-in user for the agent to know about, and a tool that runs on the caller's credentials has no caller to run as.

That failure comes from treating identity as one switch. In Microsoft Copilot Studio it is three controls, configured in three different places, and each answers a different question.

Agent authentication is the setting under Settings > Security > Authentication. It answers how the agent learns who the caller is, and it offers three options: No authentication, Authenticate with Microsoft, and Authenticate manually (Configure user authentication in Copilot Studio^[1]). This is the setting most people mean when they say "the agent needs authentication".

Tool authentication is set per tool, on the tool's configuration page under Details > Additional details > Authentication. It answers whose credentials the agent presents when that tool calls out, and it offers two values: End user credentials and Maker-provided credentials, with user credentials applying by default (Add tools to custom agents^[2]). The second value is the deliberate choice to put one shared identity, the maker's own, behind every caller. The two names are worth pinning down now, because Microsoft's guidance article for the same control labels the pair User authentication and Agent author authentication (Configure user authentication for tools^[3]). One control, two published labels; this page uses End user credentials and Maker-provided credentials throughout.

Data policy is the Power Platform admin center policy that classifies Copilot Studio connectors as Business, Non-business, or Blocked. It answers which of the above a maker is allowed to publish, and a builder does not author it. What a builder does need is to recognise its effect on an agent, which the last section of this page covers.

The figure below stacks the three controls in that order and shows the data policy reaching back up to constrain the first one.

Because the three are independent, the common planning mistakes are all mismatches rather than outright errors. Agent authentication set correctly but every tool left on the default credential mode is a shared-access design nobody chose. Tool credentials set to End user while agent authentication is No authentication is a tool that cannot run at all, since tools always execute in the user context and cannot run unless authentication is enabled. A perfect configuration in an environment whose data policy blocks it is an agent that will not publish.

What this page covers, and what it does not

Three sibling pages in this domain sit close enough to this one to be worth separating. Plan integration with enterprise systems decides which mechanism reaches an external system, a connector, an agent flow, a REST API tool, or an MCP server; this page decides who the agent thinks the caller is and whose credentials travel outward once that mechanism is chosen. Plan channels and deployment covers Direct Line channel security, the secrets and tokens that decide which hosts may embed the agent; that is a control on connecting clients, never on user identity, and the difference is sharp enough that this page restates it once in the tool-credentials section rather than teaching it twice. Evaluate security and governance considerations covers data policies as a governance discipline; this page describes only the single policy that forces agents to authenticate, and only from the maker's seat.

One piece of fluency is assumed and never re-taught here: Microsoft Entra ID app registrations and delegated OAuth 2.0 scopes. The manual authentication path below is a single-tenant app registration with openid and profile granted as delegated Microsoft Graph permissions, and it is described in exactly those terms. What it buys is a defensible identity plan for one specific deployment: which of the three authentication options that deployment gets and why, how the registration behind it is wired, where in the conversation the sign-in fires, and which of those choices the environment's data policy will refuse at publish time.

Pick the agent authentication option from the channel the agent will be published to, not from whether the audience holds Microsoft Entra ID accounts. It is worth stating before the options themselves because it is counterintuitive: an audience of badge-carrying employees does not by itself justify Authenticate with Microsoft, because that option is scoped to a specific set of channels rather than to a specific kind of user.

No authentication

An agent set to No authentication does not require users to sign in, and can only access public information and resources. Microsoft's own caution on the setting is blunt: selecting it "allows anyone who has the link to chat and interact with your bot or agent" (Configure user authentication in Copilot Studio^[1]). Two consequences follow that makers routinely miss. No authentication variables exist at all, so a topic cannot greet a user or branch on who they are. And because tools run in the user context and cannot run unless authentication is enabled, an agent with tools configured to require user credentials will see those tools stop working if you turn authentication off at the agent level. Reserve the option for genuinely anonymous audiences where no capability depends on caller identity.

Authenticate with Microsoft

Authenticate with Microsoft is the option a new agent starts on: "When you create a new agent, the Authenticate with Microsoft authentication option is on by default. The agent automatically uses Microsoft Entra ID authentication without requiring any manual setup" (Configure data policies for agents^[4]). It configures Microsoft Entra ID for you, and because the channel itself identifies the user, callers are not prompted to sign in unless the agent needs an expanded scope.

Its channel reach is the part to state carefully, because Microsoft's own pages phrase it three different ways and one of those phrasings is narrower than the others. The data policy article, revised more recently, says you "can only chat with your agent in Microsoft Teams, SharePoint, Power Apps, or Microsoft 365 Copilot". Shorter three-item versions of that same set circulate, dropping SharePoint; those four are what the most recently revised page publishes. The user-authentication article says selecting the option gives you access to the Teams + Microsoft 365 channel and that you "can also use native app and custom app channels", and then, further down its own page, that the agent "works only on the Teams channel". Do not key a plan on any single one of those sentences. Every version agrees on the part that actually drives the decision: Authenticate with Microsoft covers the Microsoft-identity surfaces and gives you no manual configuration for anything else, so as Microsoft puts it, "If you need to publish your agent to channels other than Teams + Microsoft 365 but still want authentication for your agent, choose Authenticate manually."

Two further boundaries are stated unambiguously and are fair game. The option is not available for agents that integrate with Dynamics 365 Customer Service. And agents using Microsoft authentication cannot be embedded in Power BI reports that use iframe-based visuals.

Authenticate manually

Authenticate manually is where you choose a service provider, meaning the identity provider Copilot Studio will send users to, and supply its configuration. The published list is: Microsoft Entra ID V2 with federated credentials, Microsoft Entra ID V2 with certificates, Microsoft Entra ID V2 with client secrets, Microsoft Entra ID, and Generic OAuth 2, the last being "any identity provider that complies with the OAuth2 standard".

The choice between those splits cleanly. If access must be restricted to people in your organization's Microsoft Entra tenant, use one of the Microsoft Entra ID service providers. Use Generic OAuth 2 only when the identity provider genuinely is not Microsoft Entra ID, for example a customer community whose members hold accounts with your own OAuth 2.0 provider and none in your tenant. That distinction has a governance consequence covered two paragraphs down.

Manual authentication is also the only option that makes User.AccessToken (the token the agent holds for the signed-in user) and User.IsLoggedIn (a Boolean sign-in status) available in the authoring canvas; the authentication variables section below covers both in full. If any topic must call a back-end system on the signed-in user's behalf, that requirement alone selects Authenticate manually, whatever the channel.

Require users to sign in, and who can chat

Require users to sign in determines whether a user must sign in before talking with the agent, and it is offered only for Authenticate manually. Turn it on for agents that reach sensitive or restricted information. Turn it off and "your agent doesn't ask users to sign in until it encounters a topic that requires them to", which is the deferred-sign-in design the next section but one covers in full.

The combination of option and setting also decides whether agent sharing can control who in your organization may chat with the agent. Under No authentication it cannot: anyone with a link can chat. Under Authenticate with Microsoft the user is always signed in, Require users to sign in is on and cannot be turned off, and sharing does control who can chat. Under Authenticate manually it depends on the service provider: with Microsoft Entra ID you can turn the setting on and use sharing; with Generic OAuth 2 anyone who signs in can chat, and sharing cannot narrow that to named users. So "restrict this agent to a named security group" is a requirement that rules Generic OAuth 2 out even when the audience's provider would otherwise fit.

The comparison table at the top of this page lays the three options side by side across the criteria that decide between them; treat this section as the reasoning behind those cells rather than a second copy of them. The takeaway to carry forward: channel selects the option, a token requirement forces the manual one, and the service provider you pick inside it decides whether you can still control who chats.

Choosing Authenticate manually with a Microsoft Entra ID service provider commits you to an app registration you own, and the configuration alternates between two surfaces: some steps happen in the Azure portal, some in Copilot Studio, and one Copilot Studio step produces values you must carry back to the portal. The order matters: two of the values you paste into the app registration do not exist until the Copilot Studio step has been saved.

The Microsoft Entra ID configuration article documents two ways to prove the agent is entitled to that app registration, and names a preference: "use Microsoft Entra ID V2 with federated credentials. You can also use client secrets if you're unable to use federated credentials" (Configure user authentication with Microsoft Entra ID^[5]). Federated credentials remove the stored secret, using short-lived OpenID Connect tokens instead. Enumerate that pair before you start, because the two paths diverge in the middle of the sequence: the federated path round-trips values from Copilot Studio back into the app registration, while the client-secret path generates its value in the portal and carries it forward once.

The federated-credential sequence

The figure below traces the seven steps across the two surfaces, and the numbering matches the list here.

1. Register the app. In the Azure portal, create a new app registration, and under Supported account types choose Accounts in this organizational directory only (Single tenant). Copy the Application (client) ID. Microsoft's instruction to not alter existing registrations is worth honouring: the redirect URI you add next is agent-specific.
2. Add the redirect URL. Under Authentication > Platform configurations, add a platform of type Web, and enter https://token.botframework.com/.auth/web/redirect (or https://europe.token.botframework.com/.auth/web/redirect for Europe). The same URI can be copied from the Redirect URL textbox on the Copilot Studio Security page under Authenticate manually, which is the safer habit because it never goes stale. Select both Access tokens and ID tokens.
3. Grant the permissions. Under API permissions, add Microsoft Graph > Delegated permissions, and turn on openid and profile. openid is what makes this an OpenID Connect sign-in at all; profile is what populates the name claim that Copilot Studio reads into User.DisplayName, which is why omitting it produces the blank-display-name symptom the variables section describes. Grant admin consent for the tenant so users are not prompted to consent individually.
4. Select the provider in Copilot Studio. Under Settings > Security > Authentication, select Authenticate manually, leave Require users to sign in on, set Service provider to Microsoft Entra ID V2 with federated credentials, paste the client ID, and select Save.
5. Read back the federated credential values. Saving reveals a Federated credential issuer and a Federated credential value. Copy both.
6. Register the credential in Entra. Back in the app registration, under Certificates & secrets > Federated credentials, add a credential with the scenario Other issuer, and paste the issuer and value from step 5.
7. Publish and test. Publish the agent, then send a message in the test panel and complete the sign-in, which opens a browser tab and returns a validation code you paste into the chat.

The client-secret variant replaces steps 5 and 6 with a single earlier step: generate a client secret under Certificates & secrets, copy its Value immediately because it is obfuscated once you leave the page, choose the shortest expiry that fits the agent's life, and in step 4 select Microsoft Entra ID V2 with client secrets and paste both the client ID and the secret.

Scopes: openid and profile, plus what the agent actually reaches

openid and profile get you a signed-in user. They do not get you data. Any resource the agent reads on the user's behalf needs its own delegated scope added alongside them, and Microsoft's guidance is to "only set necessary scopes and follow the least privilege access control principle". The documented examples are Sites.Read.All Files.Read.All for SharePoint, ExternalItem.Read.All for a Graph connection, and https://[OrgURL]/user_impersonation for Dataverse structured data, so a Dataverse-reading agent ends up with something like profile openid Sites.Read.All Files.Read.All https://myorg123.com/user_impersonation. That list is the documented set of examples rather than a complete catalogue; the generating rule is that each downstream resource contributes the delegated scope its own API requires.

The Scope list delimiter field deserves one line because it has a non-obvious constraint: empty spaces are not supported in that field, so if your provider requires space-separated scopes you enter a comma as the delimiter and put the spaces in the Scopes field itself.

Generic OAuth 2 and the manual field set

Choosing Generic OAuth 2 exposes the raw OAuth 2.0 fields, which you fill from your provider's documentation rather than from a Microsoft default: an authorization URL template and its query string template, a token URL template and its query string template, a token body template, refresh URL and refresh body templates, client ID and client secret, grant type, resource URL, and the scopes and delimiter above. That is not a fixed form. Microsoft introduces the field table as "fields you might encounter when configuring manual authentication" and says "The specific fields you see depend on your selection for service provider", so the certificate and federated-credential providers surface fields of their own that this list does not name. The templates are literal, with named placeholders such as {ClientId}, {RedirectUrl}, {Scopes} and {Code} that Copilot Studio substitutes at runtime; the example authorization template Microsoft shows is ?client_id={ClientId}&response_type=code&redirect_uri={RedirectUrl}&scope={Scopes}&state={State}. There is nothing to guess here: every value comes from the identity provider's own OAuth 2.0 documentation.

One field on that page belongs to a different feature and is easy to fill in by mistake. Token exchange URL is used only when you are configuring single sign-on, where a custom canvas obtains an on-behalf-of token and Copilot Studio exchanges it for the access token (Configure single sign-on with Microsoft Entra ID^[6]). SSO is a further build on top of manual Microsoft Entra ID authentication, needing a second, separate app registration for the canvas, and it is out of this page's scope beyond knowing that the field is not part of ordinary manual authentication.

The pattern to remember from this section: single-tenant registration, the Bot Framework redirect URI on a Web platform, delegated openid and profile plus exactly the resource scopes the agent needs, federated credentials in preference to a secret, and a publish before anything is real.

Once Authenticate manually is selected there is a second, separate decision: does the sign-in happen before the conversation starts, or at the moment a topic first needs an identity? Copilot Studio documents a design for each, and the choice is expressed through a single checkbox plus, in one of the two cases, a node you add yourself.

Sign in up front

Turning on Require users to sign in creates a read-only sign-in system topic that triggers automatically for any user who talks to the agent without being authenticated, and redirects to the Escalate system topic if the user fails to sign in (Configure user authentication in Copilot Studio^[1]). That is the whole design: you do not author anything.

Two details about that topic are worth flagging rather than asserting. It appears in the documentation under two names, Require users to sign in on the security article and Sign in on the topic-authoring article, and the two articles disagree on whether it can be edited: the security article says the topic "is read-only and can't be customized", while the topic article says "You can customize the Sign in topic as appropriate for your agent" (Add user authentication to topics^[7]). The security article carries the more recent revision date, so prefer its reading, and in any case both articles push the same way in practice: Microsoft recommends the topic be used only to provide the authentication method Copilot Studio supplies, and not modified to call other actions, flows, or authentication methods. A plan that depends on rewriting that topic is a plan built on contested ground.

Sign in on demand

Clearing Require users to sign in defers the prompt. The supported way to trigger it deliberately is the Authenticate node: in the topic that needs identity, add a node under Advanced > Authenticate (equivalently, Call an action > Authenticate). Adding it generates a parent Authenticate node plus two child paths, and the paths are the reason to use the node at all:

• The success path corresponds to User.IsLoggedIn = True. Any logic that uses User.AccessToken, such as a flow that calls a back-end API as the user, belongs here.
• The failure path corresponds to any condition other than IsLoggedIn = True, most often a wrong password or a cancelled sign-in. Retry logic or a handoff to a live agent belongs here.

The node has a placement constraint that will bite during authoring: it "is only available in the action picker at the end of a dialog tree (as a leaf node). You can't add it in the middle of a dialog", though you can add further nodes below it once it exists.

The figure below traces both designs from the shared starting point, including the third path that opens up when the node is omitted.

The shortcut that looks equivalent and is not

User.IsLoggedIn and User.AccessToken are available whether or not you used the Authenticate node template, and passing User.AccessToken without having sent the user through the node prompts them to sign in at that step. It is genuinely supported: Microsoft describes it as useful "if you always expect the user to be signed in, or if your user is being redirected from a different topic".

What it does not do is give you the failure branch. The same paragraph directs you to "use the template provided by the Call an action entry to handle cases where the user fails to sign in". So the implicit prompt is a convenience for a path where sign-in is effectively assured, and the Authenticate node is what you use when a failed or cancelled sign-in needs its own handling. Choosing the shortcut and then discovering there is nowhere to put the retry is the predictable outcome of treating the two as interchangeable.

One related behaviour rounds this out. Users who sign in once are not prompted again even if they reach another Authenticate node; but if a user signs out mid-conversation, they are prompted again when the topic reaches a node that uses User.AccessToken. Sign-in state is not permanent, and it can be revoked from under you.

Reading SignInReason

The SignInReason variable is a choice-type variable that tells a topic why the sign-in is happening, and its two values map exactly onto the two designs above. SignInRequired means the user must sign in at the beginning of the conversation through the sign-in system topic, which requires Require users to sign in to be on. Initializer means an unsigned-in user reached a point in the conversation that uses authentication variables and is being prompted there. If a topic needs to word its message differently depending on which design triggered it, this is the variable that tells it.

The rule to carry out of this section: Require users to sign in on gives you a system-managed sign-in with no failure branch of your own, and off plus an Authenticate node gives you a sign-in you place and whose failure you handle.

Which authentication variables exist is decided entirely by the agent authentication option, and the mapping is published as a table. Reproduced in full, because the empty cells are as load-bearing as the filled ones:

Authentication variable	No authentication	Authenticate with Microsoft	Authenticate manually
User.DisplayName	Not available	Available	Available
User.FirstName	Not available	Available	Available
User.LastName	Not available	Available	Available
User.PrincipalName	Not available	Available	Available
User.Email	Not available	Available	Available
User.Id	Not available	Available	Available
User.IsLoggedIn	Not available	Available	Available
User.AccessToken	Not available	Not available	Available
SignInReason	Not available	Available	Available

Source: Add user authentication to topics^[7].

One row differs from all the others, and it is the row that drives architecture. User.AccessToken exists only under Authenticate manually, which is why a delegated call to a back-end system forces that option regardless of what the channel would have allowed. The user-authentication article states the consequence directly: "User.AccessToken and User.IsLoggedIn variables aren't available with this option. If you need an authentication token, use the Authenticate manually option." That quotation disagrees with the table above on one cell. The table marks User.IsLoggedIn available under Authenticate with Microsoft, while the user-authentication article names it unavailable there and lists only User.Id and User.DisplayName for that option; of the two pages it carries the more recent revision date. Treat User.AccessToken as settled and that one User.IsLoggedIn cell as contested, and do not build a design on it.

Where the values come from, and why they go missing

User.DisplayName carries the display name stored in the identity provider, and Copilot Studio fills it from the name claim, the OpenID Connect claim that carries a human-readable name, "as long as the profile scope is defined when manual authentication is configured". User.Id carries the user ID stored in the identity provider, taken from the sub claim, the OpenID Connect subject identifier that uniquely identifies the user to that provider.

Both carry an explicit warning: "This variable might not contain a value. Test with a user from your identity provider to ensure your topic works correctly." The extended wording is more specific about why: the variables "might be empty strings depending on the user configuration in the identity provider". So a blank display name is not necessarily a broken configuration, it is a documented possibility whose causes on the Microsoft Entra ID path include a missing profile scope, and whose other causes live in how the user object is populated in the provider. Either way the design rule is the same: a topic that formats a greeting or keys a lookup on User.Id needs an explicit branch for the empty case, and that branch needs to be exercised before release.

Testing the empty case

The Test bot pane populates User.DisplayName and User.Id from the account you are signed in with, which is exactly the account least likely to reproduce the blank case. Two /debug commands override that, and they apply only to the test pane, not to a published agent on a channel:

Variable	Custom value command	Empty (blank) value command
User.DisplayName	/debug set bot.UserDisplayName "Value"	/debug set bot.UserDisplayName ""
User.Id	Not available	/debug set bot.UserID ""

Read that table's second row carefully, because it is asymmetric on purpose: User.Id has no custom-value command at all. "For security reasons, you can't populate the User.Id variable with a custom value (other than an empty or blank value)." So /debug set bot.UserID "some-other-user" is not a way to impersonate an arbitrary identity in testing; the only thing you can drive User.Id to is blank. Resetting the test pane, or a topic edit that resets it automatically, clears these overrides and you must send the commands again.

Even with the commands, Microsoft's instruction for a real test stands: test the topic "by using a real user configured in your identity provider" and exercise both the sign-in success and failure paths. The /debug commands cover the empty-value branch; they do not cover the sign-in experience itself.

Treat the token as sensitive runtime data

User.AccessToken holds the user's token obtained after sign-in, and Microsoft's guidance is unambiguous about where it may go: pass it "only to trusted sources. It contains user authentication information, which, if compromised, could harm the user", and "Don't use User.AccessToken in Message nodes or in flows that you don't trust." A Message node is user-visible chat output, so writing the token there displays a live delegated credential to whoever is in the conversation, and to anyone who can read the transcript afterwards. The legitimate destination is a flow or tool that calls the back-end API on the user's behalf.

The takeaway: the option you picked decides which variables exist, profile and the provider's user configuration decide whether the identity ones are populated, and the token is the one value on the page that must never reach the reader's screen.

Agent authentication tells the agent who the caller is. It says nothing about whose permissions the target system will enforce when the agent calls out, and that is a separate per-tool setting with real authorization consequences.

The control lives on the tool's configuration page under Details > Additional details > Authentication, and offers two values (Add tools to custom agents^[2]):

• End user credentials: "The agent uses the user's credentials to authenticate with the service. This method ensures users only access data they're authorized to see." This applies by default; when a connector tool is added, "the connection uses user credentials" unless you change it (Use connectors in Copilot Studio agents^[8]).
• Maker-provided credentials: "The agent uses the credentials of its author to authenticate with the service. Use this authentication mode for shared resources or when users shouldn't need individual access."

Microsoft's guidance article frames the same choice as a risk question rather than an identity one, and the framing is useful: choose the author's credentials when access to the service is implicit or the use case is low risk, such as looking up a support phone number for a postal code, and choose the user's when you "must restrict data access to specific groups or individuals in the user community" (Configure user authentication for tools^[3]). The decisive question in practice is which system holds the authorization model: if the target already enforces record-level permissions per user, End user credentials is what makes that enforcement mean anything, because Maker-provided credentials collapse every caller onto the maker's own access. The figure below shows the two outbound paths and where the permission decision lands in each.

What a user has to do before an End user tool works

The credential mode has a runtime cost the design has to account for. Users are prompted to sign in when they reach any dialog that uses a tool requiring authentication, and "they're prompted as soon as the conversation begins, and they authenticate with the agent". They may then need to create the specific connection the tool depends on, a connection being the stored Power Platform authorization to one service that a tool runs through: the connections page shows the connection needed for the current dialog plus others the experience will require, and completing it lets the user retry the tool, which then "completes with the customer's data access".

Copilot Studio stores no credentials of its own, and "Agents prompt users for their credentials whenever access tokens expire or are revoked on the service side". So a service-side token revocation shows up as a re-prompt rather than a hard failure, which is worth knowing when you are diagnosing why a tool suddenly asks for a sign-in it did not ask for yesterday.

The authenticated-channel prerequisite for maker-provided credentials

Switching a connector tool to the maker's credentials has a documented first step: "Configure your agent to use an authenticated channel", then add and configure the tool, then set Credentials to use to Maker-provided credentials on the tool's Overview page, then publish and test in the target channel.

That prerequisite is where a specific confusion arises, because the procedure links it to the web and Direct Line channel security article. Direct Line secured access is not user authentication. Turning on Require secured access means "channels need the client to authenticate their requests either by using a secret or by using a token", and "Attempts to access the agent that don't provide this security measure don't work" (Configure web and Direct Line channel security^[9]). That is a control over which clients may connect to the agent, and it never establishes who the person is. The mechanics of secrets, tokens and rotation belong to Plan channels and deployment; the point here is only that enabling it does not sign anyone in and therefore does not on its own satisfy an identity requirement.

The concrete, checkable version of "authenticated channel" is the published support table for user authentication in tools:

Channel	Supports user authentication for tools
Azure Bot Service channels	Not supported
Custom Website	Supported
Demo Website	Not supported
Facebook	Not supported
Microsoft Teams	Supported
Mobile App	Not supported
Omnichannel for Customer Service	Supported (live chat only)
SharePoint	Supported

Source: Configure user authentication for tools^[3]. The Demo Website row is the one that costs time: it is the surface makers naturally test in, and it does not support tool user authentication, so a tool that works in the test pane can fail on the demo site for a reason that has nothing to do with its configuration. Use the custom website channel for that validation instead.

The Teams row carries a condition rather than a caveat. If the Teams channel is enabled, you must follow the Teams single sign-on configuration instructions; failing to do so "causes your users to always fail authentication when using the Teams channel".

The Teams limitation with custom Active Directory authentication

One combination is called out as unsupported outright: "Single sign-on (SSO) isn't supported for connectors when an agent uses custom Active Directory authentication and the agent is deployed to Microsoft Teams. In this configuration, connectors can't use SSO, and users must authenticate to each connector manually." The mitigation Microsoft gives is not a workaround for the SSO gap but a way to make the manual path survivable: make sure the necessary connections are set up in Copilot Studio ahead of time. Plan the user experience accordingly, because a Teams audience that expects to be silently signed in will instead meet a connection prompt per connector.

The failure mode worth memorising

Turning agent authentication off breaks user-credential tools. Microsoft states it as an instruction: "If your agent has tools configured to require user credentials, don't turn off authentication at the agent level. This action prevents these tools from working." The underlying reason is that tools "are always run in the agent's runtime in the user context and can't be run unless authentication is enabled". So the agent-level setting is not just a sign-in prompt you can withdraw; it is the precondition for the whole per-tool credential mechanism above.

So: default is End user credentials, and it is usually the right default; Maker-provided is a deliberate decision to make every caller equal, and it needs a channel that supports authenticated tool use before it will work at all.

An authentication change is not a settings edit, it is a release. "Changes to the authentication configuration take effect only after you publish your agent. Plan ahead before you make authentication changes to your agent" (Configure user authentication in Copilot Studio^[1]). Saving alone changes nothing that a user can observe, which means a maker who saves, tests in the published channel, and sees the old behaviour is looking at correct product behaviour rather than a bug.

The practical shape of the change is therefore always the same three moves: configure, publish, retest in the channel the agent actually runs on. The retest half is what catches the residue described next.

Switching between options leaves broken topics behind

Moving between authentication options can invalidate variables that topics already reference, and Copilot Studio surfaces that as errors you must clear before publishing rather than as a silent downgrade.

Going from Authenticate manually to Authenticate with Microsoft is the sharper case, because the manual-only variables disappear: "If you change from Authenticate manually to Authenticate with Microsoft, and your topics contain the variables User.AccessToken or User.IsLoggedIn, they're displayed as Unknown variables after the change. Make sure to correct any topics with errors before you publish your agent." Any delegated call in those topics has lost the token it was built on, so this is a redesign of the affected topics, not a find-and-replace.

Turning authentication off entirely does the same thing to every authentication variable: "If a topic uses authentication variables, they become Unknown variables. Go to the Topics page to see which topics have errors and fix them before publishing." The documented turn-off sequence ends with a publish for the same reason as everything else in this section.

What the retest has to cover

Three things, and only the first is obvious.

First, the sign-in itself, in the intended channel, with a real user configured in the identity provider, exercising both the success and the failure paths so "there are no surprises if your user fails to sign in or there's an error with the identity provider's sign-in experience".

Second, the blank-identity branch, using the /debug commands from the variables section, because the account you test with is the one least likely to have an empty display name.

Third, the tools. Credential mode and agent authentication interact, the channel decides whether tool user authentication is supported at all, and a connection may need to be created by the user before a tool completes. Publishing and testing "in the desired channel" is the documented last step of the maker-provided-credentials procedure for exactly this reason.

A note on scope while planning the change window: the Require secured access toggle on the web channel behaves differently from everything else here. It can take up to two hours to propagate, and it does not need a publish at all. It is a channel control rather than an identity one, and it is covered on Plan channels and deployment; it is mentioned here only so that its timing is not mistaken for the publish-driven timing of the authentication settings.

The discipline in one line: configure, publish, then retest the sign-in, the blank-identity branch, and every tool, in the channel the agent actually runs on.

Everything above assumes the maker gets to choose. In a governed environment they may not, and the mechanism that removes the choice is worth understanding from the maker's seat even though an administrator configures it.

Data policies in the Power Platform admin center classify Copilot Studio connectors into three data groups, Business, Non-business, and Blocked, and govern how agents connect and interact with data and services (Configure data policies for agents^[4]). The broader governance discipline, including how connector groups interact across an environment, belongs to Evaluate security and governance considerations. This section covers the one policy use case that lands directly on an identity plan.

The connector that forces authentication

To stop makers publishing agents that anyone with a link can chat with, an administrator blocks a specifically named connector: Chat without Microsoft Entra ID authentication in Copilot Studio. Microsoft's instruction is explicit about the verb: "configure a data policy that blocks the connector Chat without Microsoft Entra ID authentication in Copilot Studio."

Block is the operative word, and it is where a plausible-sounding alternative fails. Classifying that connector as Business does not require authentication; a data group is a compatibility classification, since "data can't be shared among connectors that are in different groups", not an on/off switch. Only the Blocked group removes the capability. As it happens the connector's likely starting position works against you too: connectors introduced after 2019, and this one is named as an example, "are likely to be part of the default 'Non-business' group", so an administrator who assumes it is already restricted may find it is merely grouped.

What the maker sees

Once the policy is in place, the No authentication option is not available for selection. The user-authentication article states the same thing from the other direction: "This option isn't available when a data policy in the Power Platform admin center is configured to require authentication." Nor can the maker turn Require users to sign in off, since "You can't turn off this option when the data policy in the Power Platform admin center is set to require authentication."

What remains selectable is the set the policy is designed to force: makers "can only use Authenticate with Microsoft or Authenticate manually", and for the manual route the article naming the remediation narrows it to the Microsoft Entra ID service providers, Microsoft Entra ID or Microsoft Entra ID v2. Note what that excludes. An agent whose audience signs in with a non-Microsoft OAuth 2.0 provider cannot satisfy this policy through Generic OAuth 2, so a community-facing agent and a require-Entra-authentication policy are incompatible requirements that have to be resolved at the environment level, not in the agent.

How a violation shows up

Enforcement is real-time, and a noncompliant agent fails at the release gate rather than at runtime: "When a data policy violation occurs, the Publish button becomes unavailable." Alongside it an error banner appears with a Details button; from the Channels page you expand the error link and select Download to get a file with one row describing each violation. That file is the artifact to send to an administrator, because it names precisely what the policy objected to.

The same mechanism reaches further into the tool inventory than its connector names suggest: blocking Power Platform connectors "also blocks access to tools in connected MCP servers, which rely on Power Platform connectors for connectivity". An identity and access plan that inventories only the connectors named on the agent's Tools page will miss that dependency, and will be surprised when an MCP server's tools go with them.

One more piece of the picture belongs to any identity plan, because it can strand an agent that is otherwise perfectly authenticated. Channel publication is governed by the same policy mechanism, through connectors such as Direct Line channels in Copilot Studio and Microsoft Teams + Microsoft 365 Channel in Copilot Studio. And "If makers don't configure their agents for a channel that isn't blocked (Direct Line channels are allowed by default), or if the administrators don't allow any channel, agents can't be published." Since the whole opening argument of this page is that the channel selects the authentication option, a policy that removes a channel can invalidate an identity decision that was correct when it was made.

The closing rule for the page: verify what the environment's data policy permits before you commit to an authentication option, because the policy can veto the choice, and it does so at publish time, when the design is already built.