Article 22/50 — User-Provided vs Maker-Provided Credentials in Microsoft Copilot Studio

Enterprise AI Agents | Runtime Identity | Connection Security | SharePoint Online | Power Automate | Microsoft Entra ID | Governance

1. Introduction

One of the most consequential architectural decisions in Microsoft Copilot Studio is determining which credentials an Agent uses when executing a Tool.

An Agent can be configured to interact with authenticated users, retrieve enterprise information, invoke Power Platform Connectors, execute Agent Flows, and communicate with external business systems.

However, authenticating the person interacting with an Agent does not automatically establish which identity will execute every downstream operation.

This distinction becomes particularly important when the Agent accesses SharePoint Online, Dataverse, Microsoft Graph, or other protected enterprise resources.

Consider a simple request:

“Create a new access request in the SharePoint IT Support list.”

The Agent may correctly interpret the user’s intent, select a Tool, collect the necessary information, and execute the operation.

But an important security question remains:

Whose credentials were used to create the SharePoint item?

Was the operation executed using the employee’s own SharePoint permissions?

Or did it use a connection configured by the Agent maker?

The answer affects authorization, auditing, information disclosure, governance, and the overall security posture of the solution.

Microsoft Copilot Studio provides authentication options for supported Tools, including End user credentials and Maker-provided credentials.

These models serve different business requirements and introduce different security boundaries.

This article examines how they work, how to evaluate them, and how to design enterprise Agents that preserve appropriate authorization controls.

2. Understanding the Credential Problem

Traditional enterprise applications commonly separate user authentication from backend execution.

A user may authenticate to a web application through Microsoft Entra ID, while the application accesses its database through a separate service identity.

This is a legitimate architectural pattern when the application implements appropriate authorization controls.

AI Agents introduce a conversational interface into the same security model.

The user expresses an intention in natural language.

The Agent determines which Tool should execute.

The Tool accesses an external service.

That external service receives credentials associated with a particular identity.

The execution identity may differ from the conversational identity.

Identity Layers

The security of the overall solution depends on how these layers interact.

A valid user session does not automatically imply that the Tool uses that user’s credentials.

3. What Are User-Provided Credentials?

User-Provided Credentials, also referred to in Microsoft documentation and interfaces as End user credentials, allow a supported Tool to authenticate to an external service using the individual user’s connection.

For example, an employee interacts with an Agent that retrieves information from a SharePoint list.

If the SharePoint Connector Tool uses End user credentials, the employee must have a valid connection and sufficient SharePoint permissions for the requested operation.

The resource evaluates the permissions associated with that connection.

Conceptual Architecture

Employee → Copilot Studio Agent → SharePoint Connector → Employee Connection → SharePoint Online

The Agent orchestrates the operation.

The connection establishes the identity used by the connector.

SharePoint enforces the corresponding permissions.

Principal Characteristics

• Users authenticate to the relevant connected service.
• Each user can have an individual connection.
• Resource access follows the permissions associated with that connection.
• Users may need to establish or refresh connections.
• Unauthorized operations should be rejected by the resource.
• Connection availability depends on supported channels and integration mechanisms.

This model is generally appropriate when the business operation must respect individual user permissions.

4. What Are Maker-Provided Credentials?

Maker-Provided Credentials allow supported Tools to authenticate using a connection supplied by the Agent maker.

Instead of requiring each user to establish an individual connection, the Agent uses the configured connection when invoking the external service.

Conceptual Architecture

Employee → Copilot Studio Agent → SharePoint Connector → Maker Connection → SharePoint Online

The employee initiates the operation.

However, SharePoint evaluates the permissions associated with the maker-provided connection.

This creates a different security boundary.

The user may not possess direct access to the underlying SharePoint resource.

Nevertheless, the Tool may be able to perform an operation through the configured connection.

Whether this is acceptable depends on the business design and the authorization controls protecting the operation.

Typical Use Cases

• Shared information services.
• Low-risk operations.
• Controlled business request submission.
• Centralized service integrations.
• Operations where users should not require direct access to the backend resource.

Maker-provided credentials should not be interpreted as a general-purpose mechanism for bypassing user permissions.

5. Direct Comparison

Neither model is universally superior.

The correct choice depends on the business operation and the required security semantics.

6. Microsoft-Documented Behavior

Microsoft documents the two credential approaches for supported Copilot Studio Tools.

In the current Tool configuration experience, the maker can select the authentication model where the Tool supports that choice.

The documentation describes End user credentials as the model in which the user’s credentials authenticate with the connected service.

Maker-provided credentials use the author’s configured credentials.

Microsoft also documents administrative controls that can restrict the use of maker-provided credentials.

These controls are particularly important because shared connections can expose capabilities beyond an individual user’s permissions.

Important Scope Limitation

The availability and exact behavior of credential options depend on:

• Tool type.
• Connector capabilities.
• Agent authentication configuration.
• Channel support.
• Environment governance.
• Connection configuration.
• Current platform limitations.

Do not assume that every Copilot Studio Tool implements identical authentication behavior.

Official documentation:

7. Agent Authentication Is Not Tool Authentication

This is the most important conceptual distinction in the article.

An Agent may require users to authenticate with Microsoft Entra ID before starting a conversation.

This establishes the conversational user’s identity.

However, a Tool may independently require authentication to SharePoint Online, Dataverse, or an external API.

The Agent authentication configuration and Tool connection configuration solve different problems.

Example

An employee signs in to Microsoft Teams.

The employee opens a Copilot Studio Agent.

The Agent invokes a SharePoint Connector.

The SharePoint Connector uses a maker-provided connection.

The employee is authenticated, but the SharePoint operation uses the maker connection.

Authentication Boundary Matrix

These questions must be answered separately.

8. Runtime Identity

Runtime identity refers to the identity effectively used when an operation executes.

An Agent interaction can involve multiple runtime identities.

For example:

User Identity → Agent Context → Tool Connection Identity → Backend Service Identity

The identities may be identical in some configurations.

They may also differ.

Runtime Identity Example

The final audit representation depends on the operation and underlying service.

The essential point is that the original conversational user and the resource execution identity are not necessarily the same.

9. Why Runtime Identity Matters

Runtime identity determines which permissions the downstream system evaluates.

Suppose an Agent accesses a restricted SharePoint library.

The employee does not have access to the library.

The maker does.

If the Tool uses maker-provided credentials, the Tool may retrieve information that the employee could not retrieve directly.

This creates an information disclosure risk.

Similarly, a maker connection may be able to update records, delete content, or change permissions beyond the employee’s own authority.

Therefore the architecture must consider both data retrieval and state-changing operations.

Risk Categories

These risks must be evaluated before production deployment.

10. SharePoint Online Scenario: Reading a Restricted List

Consider a SharePoint site:

The site contains a list named:

FinancialApprovals

Only Finance employees have permission to read its contents.

An Agent exposes a Tool called:

GetFinancialApprovalStatus

Scenario A: End User Credentials

The user authenticates through their SharePoint connection.

SharePoint evaluates that user’s permissions.

An unauthorized employee cannot retrieve protected records merely because the Agent exposes the Tool.

Scenario B: Maker-Provided Credentials

The Tool uses the maker’s SharePoint connection.

If the maker can read the list, the Tool may retrieve the requested records.

Without additional authorization controls, the Agent may expose protected information to users who lack direct SharePoint access.

Security Comparison

Architectural recommendation: Prefer user-context access for sensitive SharePoint information when the supported integration can preserve the intended permission boundary.

11. SharePoint Online Scenario: Creating a Request

Not every operation requires the user to have direct access to the underlying SharePoint list.

Consider an internal access-request system.

Employees must submit access requests, but they should not browse or modify other employees’ requests.

A maker-provided connection may be useful for creating records in a protected SharePoint list.

Proposed Architecture

Employee → Agent → CreateAccessRequest Tool → Controlled Connection → SharePoint Requests List

The Tool accepts only a narrow set of parameters:

• Target site.
• Requested role.
• Business justification.

The Tool creates a request record.

It does not grant SharePoint permissions.

Security Requirements

The solution should ensure that:

• Only authenticated users can submit requests.
• The requester identity is obtained through a trusted mechanism.
• Users cannot arbitrarily impersonate other employees.
• The Tool cannot perform unrelated SharePoint operations.
• Business validation is enforced.
• Request creation is audited.

Maker-provided credentials may be appropriate because the operation exposes a controlled business capability rather than unrestricted access to the underlying list.

12. The Confused Deputy Problem

The confused deputy problem occurs when a privileged component performs an unauthorized operation because a less-privileged caller influences its behavior.

Maker-provided credentials can introduce this risk.

Consider an Agent whose maker has SharePoint Site Owner permissions.

The Agent exposes a Tool capable of modifying permissions.

A regular employee asks:

“Grant me Owner access to the Finance site.”

If the Agent invokes the Tool without backend authorization, the maker connection may execute the operation.

The user has indirectly exercised privileges they do not possess.

Architectural Controls

• Restrict the operations exposed to the Agent.
• Avoid unnecessary Site Owner connections.
• Validate the authenticated requester.
• Enforce business authorization.
• Require approvals for privileged operations.
• Separate request submission from provisioning.
• Maintain audit records.

The Agent’s conversational Instructions are not a sufficient authorization boundary.

13. Tool Descriptions Do Not Enforce Security

Copilot Studio uses Tool descriptions to help Generative Orchestration select capabilities.

A Tool description might say:

“Use this Tool only when a Finance manager requests approval.”

This can influence Tool selection.

However, it does not verify that the caller is a Finance manager.

The backend must independently enforce that restriction.

Control Comparison

The distinction between orchestration guidance and authorization enforcement is essential.

14. End User Credentials and SharePoint Permissions

End User Credentials are particularly useful when the intended business behavior is:

The Agent should access only what the user can access directly.

For example:

“Show my assigned training documents.”

If the Tool uses the user’s SharePoint connection, SharePoint can enforce the user’s permissions.

The Agent may interpret the request and present the results conversationally.

However, the resource remains responsible for deciding which content is accessible.

This approach aligns naturally with SharePoint’s existing permission model.

It is often preferable to implementing a separate authorization system inside the Agent.

15. Maker-Provided Credentials and Shared Services

Maker-provided credentials can be useful for operations where users should not directly access the underlying service.

Consider a corporate Agent that retrieves the current support team’s public telephone number.

The external service may require authentication, but the returned information is not confidential.

Requiring every employee to configure an individual connection may create unnecessary friction.

A shared connection can simplify the experience.

Suitable Characteristics

Maker-provided credentials are not inherently inappropriate.

The security concern arises when shared credentials expose broader capabilities than the business process requires.

16. Connection Ownership

A connection represents an authenticated relationship with an external service.

Connection ownership affects lifecycle management.

A connection may depend on:

• The associated account.
• Authentication tokens.
• Granted permissions.
• Tenant policies.
• Connection sharing.
• Credential renewal.
• Account status.

A production Agent should not depend casually on a personal maker account with broad administrative privileges.

If the maker leaves the organization or loses access, the integration may stop working.

Operational Risks

Connection ownership is an ALM and operational governance concern, not merely an authoring convenience.

17. Maker Account vs Service Account

A maker-provided connection may use the maker’s personal identity.

This is different from a deliberately managed service identity.

Personal Maker Account

A human account used during development.

Dedicated Service Account

An organizational account managed for a specific integration purpose.

Application Identity

A service principal or managed identity used by an appropriately designed application integration.

These are different identity models.

Comparison

Do not assume that every Copilot Studio Tool can directly authenticate using every identity type.

The available methods depend on the integration mechanism.

18. User Connections and Consent

When a Tool requires End user credentials, users may need to establish a connection to the external service.

This can involve authentication and consent experiences, depending on the connector and identity provider.

The user should understand which service is being accessed and why.

For example, an Agent that retrieves the user’s SharePoint files may require an appropriate SharePoint connection.

The user may need to authenticate before the Tool can execute.

User Experience Considerations

• Connection prompts.
• Token expiration.
• Consent requirements.
• Connection renewal.
• Supported channels.
• Authentication failures.
• User guidance.

A secure configuration must also provide an understandable user experience.

Repeated connection failures can make an otherwise well-designed Agent unusable.

19. Single Sign-On Is Not Universal

Single Sign-On can reduce authentication friction.

However, an authenticated Microsoft Teams session does not automatically guarantee seamless authentication for every connector or external service.

The behavior depends on:

• Channel.
• Agent authentication mode.
• Connector.
• Identity provider.
• Supported SSO configuration.
• Tenant policies.

Microsoft documents limitations for certain connector authentication scenarios.

Therefore SSO behavior must be validated in the intended publication channel.

A successful test inside the Copilot Studio authoring environment does not guarantee identical behavior in Teams or another channel.

20. Authentication Support by Channel

Different Copilot Studio channels support different authentication capabilities.

For example, Microsoft documentation identifies supported and unsupported channels for user authentication with Tools.

The support matrix can change as the platform evolves.

Architectural Implication

A solution requiring individual user connections must verify channel compatibility before publication.

The architect should test:

• User sign-in.
• Connection creation.
• Token renewal.
• Tool execution.
• Permission enforcement.
• Error handling.

Do not design a security architecture around an assumed authentication capability that the target channel does not support.

Official reference:

21. Power Automate and Connection References

Power Automate introduces additional identity considerations.

A flow can use connector connections that are configured independently of the Agent’s conversational identity.

In solution-aware development, Connection References help associate flows with connections across environments.

However, a Connection Reference is not itself an authorization policy.

It identifies a connection dependency.

The actual connector action executes according to the configured connection and applicable flow runtime model.

Example

Agent → Agent Flow → SharePoint Create Item

The SharePoint action may use a connection associated with a configured account.

The Agent’s user identity is not automatically the SharePoint execution identity.

Important Questions

22. Agent Flows and Credential Boundaries

Agent Flows allow Copilot Studio Agents to execute deterministic business processes.

However, the flow’s internal connector actions may introduce additional connection boundaries.

For example:

Agent → Flow → SharePoint → Outlook

The SharePoint and Outlook actions may use different connections.

Therefore the flow should not be treated as having one universal execution identity for every downstream service.

Flow Identity Matrix

The effective identities must be verified in the deployed environment.

23. Example: SharePoint Training Request Agent

Consider a training request Agent.

Employees can ask:

“Register me for the Power Platform security workshop.”

The Agent invokes an Agent Flow.

The flow creates an item in a SharePoint list.

Proposed Data Contract

{
  "trainingId": "PP-SEC-101",
  "requestReason": "Required for my current project",
  "correlationId": "illustrative-correlation-id"
}

The requester identity should be derived from trusted authenticated context, not accepted blindly as a user-editable input.

Example Result

{
  "success": true,
  "requestId": 1055,
  "status": "Submitted"
}

The Agent should respond:

“Your training request 1055 was submitted successfully.”

It should not claim that the employee is already enrolled unless the backend confirms enrollment.

24. Identity Spoofing Through Tool Parameters

A common mistake is accepting an email address from the conversation and treating it as verified identity.

For example:

{
  "requestedBy": "finance.director@contoso.com",
  "action": "ApproveAccess"
}

If the Agent allows the user to supply this value, an attacker may impersonate another employee.

The backend should not authorize sensitive operations based solely on such a field.

Safer Approach

Use an authenticated identity established through a supported mechanism.

For a custom API, validate the access token and derive identity from trusted claims.

For a connector-based integration, understand which authenticated connection identity is available.

If the business operation requires the original conversational user’s identity, design a trustworthy way to establish and propagate it.

25. Authentication vs Authorization in Shared Connections

Maker-provided credentials solve the authentication problem for the connected service.

They do not automatically solve user-specific authorization.

Consider:

User A → Agent → Shared Connection → SharePoint

The shared connection may have permission to read a list.

However, User A may only be authorized to view their own records.

SharePoint evaluates the shared connection’s permissions, not User A’s permissions, unless the integration implements an additional supported authorization mechanism.

The business service must therefore enforce the intended user-level restriction.

Security Layers

The fourth layer is especially important when using shared connections.

26. Resource-Level Authorization

Enterprise authorization frequently depends on the specific resource.

For example, a manager may approve requests for one department but not another.

A user may have access to one SharePoint site but not another.

A service account may have access to multiple sites.

Therefore authorization should consider both the caller and the target resource.

Example Policy

A request may be approved only when:

• The caller is authenticated.
• The caller has an appropriate role.
• The request belongs to an authorized department.
• The request is in Pending status.
• The caller is not prohibited from approving their own request.

These rules should be enforced by the backend.

They should not depend solely on the Agent’s interpretation.

27. Least Privilege for Maker Connections

If maker-provided credentials are necessary, the connection should have minimal permissions.

Consider a Tool that creates SharePoint access requests.

The connection should not require tenant administrator permissions.

It should only have access to the specific resource and operation needed.

Permission Design

The objective is to reduce the impact of incorrect Tool selection, malicious input, or connection compromise.

28. Least Capability

Least capability complements least privilege.

An Agent should expose only the Tools necessary for its business purpose.

For example, an access-request Agent may need:

CreateAccessRequest

GetAccessRequestStatus

It probably does not need:

DeleteSharePointSite

GrantSiteCollectionAdministrator

ExportAllEmployeeRecords

Even if the maker connection possesses broader permissions, limiting exposed Tools reduces the Agent’s attack surface.

However, Tool restrictions do not replace backend authorization.

Both controls should be applied.

29. User Confirmation Before Tool Execution

Copilot Studio supports configuration options for asking users to confirm Tool execution in supported experiences.

Confirmation can improve transparency before executing consequential operations.

For example:

“You are about to submit an access request for the Finance site. Continue?”

This may reduce accidental execution.

However, confirmation is not authorization.

A user confirming an unauthorized operation does not make it permissible.

Confirmation vs Authorization

All may be relevant to sensitive enterprise operations.

30. Microsoft Entra ID and Custom APIs

A custom REST API may use Microsoft Entra ID for authentication.

This provides an opportunity to implement explicit backend authorization.

For example:

Agent → Custom Connector → Protected API → SharePoint Integration Service

The API validates an access token.

It then checks the caller’s permissions before performing the operation.

Important Distinction

The token may represent a user or an application, depending on the supported authentication flow.

A maker-provided connection does not automatically provide a delegated token for the conversational user.

If user-specific authorization is required, the architecture must explicitly establish trusted caller context.

31. Delegated Permissions vs Application Permissions

Delegated permissions allow an application to access resources in the context of a signed-in user.

Application permissions allow an application to operate using its own identity.

Comparison

These Microsoft Entra permission models are related to, but not identical to, Copilot Studio’s End user and Maker-provided credential options.

Do not treat the two pairs of concepts as interchangeable.

A Tool connection model describes how credentials are supplied.

Delegated and application permissions describe authorization models for supported APIs.

32. Why Maker-Provided Does Not Mean Application Permissions

This distinction deserves particular attention.

A maker-provided connection may authenticate using the maker’s personal account.

That is not the same as using application permissions.

For example:

A maker configures a SharePoint Connector using their own Microsoft 365 account.

The Tool executes using that connection.

This does not automatically make the operation application-only.

The connection may still represent a human user identity.

Conceptual Comparison

These concepts operate at different architectural layers.

33. Managed Identity as an Alternative

For custom Azure-hosted services, managed identities can reduce dependency on stored application secrets.

Consider:

Copilot Studio → Protected API → Azure Function → Managed Identity → Enterprise Resource

The Azure Function uses its managed identity to access supported downstream resources.

This can be appropriate for controlled backend operations.

However, the API must still authorize the original request.

A managed identity provides authentication for the Azure workload.

It does not automatically prove that the conversational user is permitted to perform the requested business operation.

34. Connection Sharing

Power Platform connections can have sharing capabilities depending on connector and connection type.

Sharing a connection may allow other authorized users or components to use the configured connection.

This must be treated as a security-sensitive operation.

Review Questions

• Who owns the connection?
• Who can use it?
• Who can share it further?
• Which permissions does it possess?
• Which Agents depend on it?
• What happens when it is revoked?
• How is its use audited?

A shared connection should have an explicit owner and operational purpose.

Avoid uncontrolled sharing of highly privileged connections.

35. Environment-Level Governance

Microsoft provides administrative controls for maker-provided credentials in Copilot Studio.

Administrators can configure which credential options are available to makers in supported environments or environment groups.

This allows organizations to restrict or prevent maker-provided credentials.

Governance Options

Microsoft documentation states that both credential options are enabled by default in the documented governance experience.

Organizations should review the actual configuration rather than assuming the environment follows a preferred security baseline.

Official reference:

36. Impact of Disabling Maker-Provided Credentials

Restricting maker-provided credentials is not merely a change to the authoring interface.

Microsoft documents that this governance control can affect existing Agents and their Tool authentication behavior.

Agents may require End user authentication for Tool execution.

This can introduce connection prompts and affect previously functioning integrations.

Operational Considerations

Administrators should evaluate existing dependencies before changing credential policies.

37. Autonomous Agents and Credentials

Autonomous Agents may execute in response to scheduled or event-driven triggers rather than direct user interaction.

This creates a special authentication challenge.

If a Tool requires a live user’s connection or interactive authentication, the operation may not be executable in an unattended context.

Microsoft explicitly documents this concern in the governance guidance for maker-provided credentials.

Architectural Implication

Unattended execution requires an authentication model that supports unattended operation.

A design that works during an interactive Teams conversation may not work when executed by an autonomous trigger.

The authentication strategy must be considered before selecting the execution model.

38. Security Scanning

Copilot Studio includes an automatic security scan that can identify certain risky Agent configurations before publication.

Microsoft documents warnings associated with configurations such as:

• Anonymous Agent access.
• Maker-provided credentials for supported Tools.
• Broad Agent sharing.

These warnings help makers recognize potential exposure.

However, automated scanning cannot replace a complete architectural security review.

A Tool may pass configuration checks while still exposing excessive business capabilities through an overprivileged backend.

Security Review Layers

Security requires defense in depth.

39. DLP and Credential Governance

Power Platform Data Loss Prevention policies govern supported connectors and data movement capabilities.

Credential governance determines which authentication models are permitted.

These controls address different risks.

Comparison

An allowed connector may still use an overprivileged connection.

Similarly, a correctly scoped connection may be blocked by DLP policy.

Both dimensions must be reviewed.

40. ALM and Connection References

Enterprise Agents should be deployed through controlled environments.

A typical architecture includes:

DEV → TEST → PROD

Connections should be managed appropriately for each environment.

A development maker’s personal connection should not automatically become the production execution identity.

ALM Considerations

Connection references support deployment management.

They do not eliminate the need to validate the permissions of the actual connections assigned in each environment.

41. Production Connection Ownership

Production connections should have documented operational ownership.

Important questions include:

• Who maintains the connection?
• Who approves permission changes?
• Who monitors authentication failures?
• What happens if the account is disabled?
• How are credentials renewed?
• How is access revoked?
• Who investigates security incidents?

A production Agent that depends on an undocumented personal account creates avoidable operational risk.

A dedicated connection strategy should be part of the solution architecture.

42. Auditing and Identity Attribution

A resource system often records the identity associated with the connection executing an operation.

For example, a SharePoint list item created through a shared connection may record the shared account as the creator.

This does not necessarily identify the employee who initiated the Agent conversation.

Therefore enterprise audit records may need to distinguish:

• Conversational requester.
• Tool execution identity.
• Backend service identity.
• Approver.
• Target resource.
• Operation.
• Result.
• Timestamp.
• Correlation identifier.

Illustrative Audit Record

{
  "requestId": 1055,
  "initiatedBy": "authenticated-user-reference",
  "executedBy": "sharepoint-service-connection",
  "operation": "CreateAccessRequest",
  "targetResource": "Finance",
  "status": "Submitted",
  "correlationId": "transaction-reference"
}

The requester identity must come from a trustworthy source.

A user-editable text field is not sufficient evidence for security-sensitive attribution.

43. Troubleshooting Credential Problems

Authentication and authorization failures should be investigated systematically.

Diagnostic Matrix

The recommended troubleshooting approach is to verify one identity boundary at a time.

Start with the Agent authentication configuration.

Then inspect Tool credentials.

Then inspect the actual connector connection.

Finally, verify downstream resource permissions.

44. Security Test Matrix

Testing must include different user identities.

Testing only with the Agent maker is insufficient because the maker may have broader permissions than ordinary users.

Recommended Test Accounts

• Agent maker.
• Ordinary employee.
• Employee with restricted SharePoint access.
• Authorized manager.
• Unauthorized employee.
• Connection owner.

Test Scenarios

Security testing should verify actual downstream behavior, not merely the Agent’s conversational response.

45. Architecture Decision Matrix

These are architectural recommendations.

The exact implementation depends on supported connector authentication methods and organizational requirements.

46. When Not to Use Maker-Provided Credentials

Maker-provided credentials are generally a poor default when:

• The Tool accesses confidential user-specific information.
• The maker has significantly broader permissions than Agent users.
• The Tool exposes destructive operations.
• The backend lacks user-level authorization.
• The connection uses an administrative account unnecessarily.
• The original requester cannot be reliably identified.
• The organization prohibits shared credentials.
• The operation requires strict per-user audit attribution.

In these situations, prefer user-context access or a carefully designed backend service that enforces authorization independently.

47. When Maker-Provided Credentials May Be Appropriate

Maker-provided credentials may be suitable when:

• The operation is low risk.
• The data is intended for the Agent’s entire authorized audience.
• The backend capability is narrowly scoped.
• Users should not require direct access to the underlying system.
• The connection has minimal permissions.
• Business authorization is enforced where necessary.
• Operational ownership is documented.
• The environment permits the credential model.

For example, creating a request in a protected SharePoint list can be a reasonable use case when the Tool exposes only a controlled request-submission capability.

48. Enterprise Reference Architecture

A mature enterprise design separates user identity, Tool connection identity, and backend authorization.

User-Specific Access

Authenticated User → Copilot Studio → End User Connection → SharePoint Online → Authorized Result

Controlled Shared Capability

Authenticated User → Copilot Studio → Maker-Provided Connection → Restricted Business Service → Authorization and Validation → SharePoint Online

Privileged Backend Operation

Authenticated User → Copilot Studio → Request Submission → Approval → Privileged Provisioning Service → SharePoint Online

These patterns serve different requirements.

They should not be treated as interchangeable.

The architectural decision should be based on the required trust boundary.

49. Enterprise Credential Design Checklist

50. Conclusion

User-Provided and Maker-Provided Credentials represent different approaches to authenticating Copilot Studio Tools.

End user credentials are generally appropriate when operations must respect individual users’ permissions.

Maker-provided credentials can simplify access to shared services and controlled business capabilities, but they introduce an additional trust boundary.

The identity used by a Tool may possess permissions different from those of the person interacting with the Agent.

This difference affects confidentiality, authorization, auditing, operational ownership, and governance.

A secure enterprise architecture must therefore distinguish:

Conversational Identity

Tool Connection Identity

Backend Execution Identity

Resource Authorization

Business Authorization

These responsibilities should be documented and tested independently.

The most important architectural principle is:

An authenticated Agent user does not automatically imply user-authorized Tool execution. The effective security boundary is determined by the credentials, permissions, and authorization controls used throughout the complete execution chain.

For enterprise implementations, credential selection should be a deliberate architectural decision rather than a convenient configuration default.

51. Learning Journey — Where We Are and What’s Next

This article belongs to a structured 50-article series exploring Microsoft Copilot Studio, enterprise AI Agents, SharePoint Online, Microsoft 365, integration architecture, security, governance, and production deployment.

Current Progress

Current progress: 22 of 50 articles drafted — 44% of the planned series.

What’s Next — Article 23/50

Least Privilege and Runtime Identity in Microsoft Copilot Studio

The next article will expand the security architecture beyond credential selection.

It will examine how to design restricted execution identities, minimize Tool permissions, isolate privileged operations, implement authorization boundaries, and validate runtime access across SharePoint Online, Power Automate, Custom Connectors, and enterprise APIs.

The next architectural question: How can an enterprise Agent execute useful business operations without receiving unnecessary privileges or exposing unauthorized capabilities?

52. Official Microsoft Documentation

1. Configure user authentication for tools

Explains authentication options, user connections, permission management, and supported channels.

2. Use connectors in Copilot Studio agents

Documents connector Tools and maker-provided credential configuration.

3. Add tools to custom agents

Explains Tool configuration, authentication options, orchestration, and execution behavior.

4. Control maker-provided credentials for authentication

Documents administrative restrictions on maker-provided credentials and the implications for existing and autonomous Agents.

5. Automatic security scan in Copilot Studio

Describes security warnings associated with risky Agent configurations.

6. Configure data policies for agents

Explains DLP and governance controls for Copilot Studio.

7. Plan and design integration strategies

Discusses architectural choices involving connectors, HTTP requests, and Agent Flows.

8. Configure user authentication

Explains Agent authentication configuration.

9. Microsoft Graph permissions overview

Explains delegated and application permissions.

10. Microsoft identity platform

Provides Microsoft Entra ID authentication and authorization documentation.

11. OAuth 2.0 On-Behalf-Of flow

Documents delegated token exchange for supported middle-tier architectures.

12. SharePoint permission levels

Explains SharePoint permission levels and authorization concepts.

53. Final Technical Summary

Final Architecture

User → Authenticated Agent → Tool → Configured Connection Identity → Backend Authorization → Enterprise Resource → Audited Result

The identity that initiates the conversation and the identity that executes the business operation may be different. Secure Agent architecture must explicitly control that difference.