Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Controlling the use of maker-provided credentials is a governance feature in Microsoft Copilot Studio that allows administrators to determine how makers can authenticate tools they add to agents.
When configuring an agent, a maker could add a tool that requires authentication to another service (like a connector or Power Automate flow) using their personal credentials. When someone uses the agent, the agent uses the maker's credentials, not the end user's credentials, to authenticate with connected services. Using maker credentials could lead to oversharing of data or capabilities - for example, an end user might retrieve information or perform actions that only the maker's account is permitted to do.
By configuring how makers can authenticate tools, you can help prevent damaging actions because each end user only has access to what their own account allows.
The Control maker credential options feature enables this by letting you control how a maker can authenticate tools in an agent. You choose whether makers can select to use their own credentials for authenticating tool connections, to use the end-user's credentials, or to have access to both.
Enforcing the use of end-user credentials prompts the end user to sign in (to the relevant service or connector) when needed. No stored maker credentials are used at run time, aligning the agent's behavior with the end user's actual permissions.
Admins can enable and disable the selection of maker-provided credentials in the Power Platform admin center, as described in this article.
Caution
By default, both End-user and Maker-provided credentials are enabled.
Getting Started
Warning
When configured as instructed, the feature immediately turns off the maker's ability to select their credentials for authenticating tools within the environment or environment group. All tools for all agents in the impacted environments instantly change to require end-user credentials at runtime.
You should prepare your makers and users for this change, as any new conversations with the impacted agents prompts the agent user for their sign-in details for the connected service.
Prerequisites
- Power Platform admin permissions (Environment Admin for a single environment, or Power Platform Administrator/Global Admin for environment groups).
Prevent the use of maker-provided credentials
Choose whether end-user or maker credentials (or both) can be selected by makers for agents in an environment, or for all agents in all environments in an environment group.
Tip
If the environment you want to configure is part of an environment group, you must be a tenant admin with access to the group.
You can't configure this feature on the individual details page for environments that are in a group, you must use the group's details page.
Go to the Power Platform admin center and sign in with an admin account.
On the side navigation, select Manage.
Select Environments or Environment groups. In the list that appears, select the name of the environment or environment group you want to configure. The details page for the environment or environment group opens.
In the environment's details page, select Settings on the top menu bar. Expand the Product section, and select Features.
Scroll to the Copilot Studio agents section.
Under Control maker credential options, select End-user credentials or Maker-provided credentials, or both.
Tip
If the environment is in a group, the options are unavailable and a message directs you to configure the setting for the group, not the individual environment.
Click Save.
The update might take a minute to propagate. Once active, all existing and new agents in that environment adhere to this rule, and the types of authentication options for makers change in Copilot Studio.
Scope of enforcement and experience
Caution
Impact on autonomous agents
When maker-provided credentials are prevented from being used, agents require real-time user interaction because each tool call must be authenticated with a live user sign-in. As a result, agents triggered by scheduled or autonomous events, or that attempt to run in the background, fail due to missing credentials.
All agent triggers must involve an active user.
Maker experience
The Copilot Studio authoring UI automatically reflects this policy. Any toggle or dropdown for authentication methods have maker-provided credentials disabled or hidden. The maker sees that only end-user (or maker) authentication can be chosen. This notification might be labeled simply as "End user credentials" in the UI. If the maker previously had a tool configured with their credentials, they might be prompted to change it before publishing the agent.
End-user experience
When an end user interacts with an agent (for example, in Teams or on a website) and triggers a tool action, the agent prompts that user to sign in if they haven't already. The prompt could be a login card or link. Once the user signs in with their own account for the required service, the agent proceeds with the action using the user's credentials. If the user is already signed in (for example, their Microsoft 365 or Teams account is also authorized for the needed service), the agent might use that existing authentication session. The action runs under the end-user's identity. If the user lacks permission for something, the agent is unable to do it on their behalf - by design.
Power Automate flows
The control over the authentication type covers connectors, built-in actions, and embedded Power Automate flows equally. A Power Automate flow as a tool in the agent also requires each user to sign in for any connections that flow uses.
Scope of enforcement
The policy is applied per environment (or environment group). If an environment is part of a managed group where the policy is enabled, you can't individually disable it for one environment in that group - environment group settings override any environment settings.
Next steps
As with all security features, this feature should form part of your defense-in-depth strategy. For example, you could:
Use credential restriction in sensitive or production environments where agents are shared with other end users and data security is paramount - for example, production agents that access your organization's internal systems, like Microsoft 365. Using credential restriction in these environments ensures that only authorized users (by virtue of their own credentials) can execute sensitive operations via the agent.
Combine credential restriction with agent sharing controls for even tighter security. By also preventing makers from freely sharing agents (or by limiting who can use certain agents), you reduce the risk that a maker could, for example, share an agent to someone who shouldn't have access. Control Maker Credential Options ensures credentials aren't inappropriately shared, and also prevents any type of stored credentials, including API keys.