Authenticate Copilot Studio and publish to Teams or websites

Configure Copilot Studio authentication before the channel

Copilot Studio authentication determines who can use an agent and whose context data or tools are called. This decision should be made before publishing to Teams or a website. An agent that works in the test window may have different identity and session conditions in the target channel.

First, the target audience, data sources, and allowed actions are described. Internal employees, guests, partners, and anonymous website visitors require different trust models. A single agent should serve these groups only if data and functional boundaries remain technically clear.

Distinguish creator, agent, and user identity

The creator edits the agent in a Power Platform environment. The agent has its own technical identity for channels and services. The end user logs in to the published experience. These three identities must not be confused in architecture and support.

Connections can also have their own owner. Successful access in the author account may rely on its far-reaching connection. Production tests therefore use normal user accounts and check the actually used identity flow.

Microsoft authentication for internal agents

For internal use in Teams, Power Apps, or Microsoft 365 Copilot, Microsoft authentication is typically the appropriate starting point. Users are recognized via Entra ID. The agent can use data sources and tools in the user context or via defined technical connections.

Login alone does not guarantee correct authorization. Every source and action requires its own permission check. The agent does not show sensitive information just because the user exists in the tenant.

Assess Entra Agent Identity

Newer Copilot Studio agents can use Entra Agent Identities. The agent receives a service identity recognizable as an agent, which improves management and visibility compared to classic app registrations. Older agents can continue to rely on existing app registrations.

The identity is treated as a technical security object. Permissions, owners, and lifecycle are documented. Unused or replaced identities are controlled removed after dependencies are checked.

Weigh user context against technical connection

When accessing in user context, the rights of the logged-in user apply. This suits personal or permission-trimmed data. A technical connection enables central processes but must not generally output results to unauthorized users.

For each action, it is decided which model is domain-specific correct. A ticket in the user's name may need their identity, while a central notification can run via a service account. Audit data must later show who triggered the action and which identity executed it.

Limit app permissions

Agents and tools may need app permissions or delegated permissions. The scope follows the Least-Privilege principle. Broad read rights to all sites are not chosen if a narrower access or an API with domain-specific authorization is possible.

Admin Consent is documented and regularly checked. The existing contribution Check App Permissions and Admin Consent describes roles, inventory, and review. Secrets and certificates additionally receive expiry monitoring.

Provide Teams as an internal channel

Teams offers a familiar access point for internal agents. Before deployment, app policies, target groups, installation, and availability are checked. The agent is first provided to a pilot group and not automatically made tenant-wide visible.

Tests include personal chats, optionally team contexts, and various device types. Links, adaptive cards, and authentication dialogs can differ between desktop, web, and mobile device. Support documents name the expected entry point.

Use Microsoft 365 Copilot as a channel

A Copilot Studio agent can extend Microsoft 365 Copilot and provide knowledge or tools there. Sharing, licensing, and contained usage depend on the specific agent and user scenario. Administrators control which agents are available.

The agent receives a unique name and description so users can distinguish it from the general Copilot. Responsibility, data scope, and possible actions are explained already in the introduction. The guide Create Copilot Studio Agent provides the complete development framework.

Secure website channels separately

A website can reach internal users, partner users, or public users. Anonymous publishing is suitable only for content and actions that are allowed without identity verification. A chat window on a public page must not provide indirect access to internal knowledge sources.

For authenticated websites, design sign-in, token flow, session duration, sign-out, and error handling. The web application additionally checks authorization and protects tokens. Configure CORS, Content Security Policy, and embedding according to the target architecture.

Limit sessions and context

Conversation context can include information from previous messages. On shared devices, expired sign-in, or channel changes, no session must be assigned to the wrong user. Test sign-out and session expiration.

The agent stores only the required state. Sensitive values are not kept unnecessarily in variables or logs. When escalating to a human, clearly define which conversation context is transferred.

Manage sharing and target audiences

Edit rights on the agent, usage permission, and channel publishing are different permissions. Makers can change an agent without automatically determining production sharing. User groups receive only the required usage.

Group-based assignment simplifies pilot and rollout. Guests and external accounts are checked separately. Managing guest users helps with ownership, expiration, and reviews.

Verify access with a test matrix

A test matrix connects identity, channel, data source, and action. It includes authorized and unauthorized cases. Tests are not performed only with administrators because their broad rights can hide errors.

For each case, check sign-in, visible functions, source access, tool permission, and sign-out. A successful response without permission is a critical error. An expected denied access must be explained clearly and without internal details.

• internal standard user in Teams
• business team member with additional data permission
• internal user without source access
• guest account with limited access
• authenticated website user
• anonymous website visitor without internal functions

Diagnose errors along the identity flow

On an access error, check which user is signed in, which agent identity is used, which connection applies, and which target system rejects. Republishing does not fix incorrectly granted permission.

Correlation and audit data are secured. Users see a concise error message and a support path. Technical details remain in the operations log and are accessible only to authorized roles.

Keep the agent controlled in every channel

Copilot Studio authentication is an end-to-end decision involving user, agent, connection, and target system. Teams and Microsoft 365 simplify internal sign-in, while websites require their own security architecture. Therefore, channel selection and data access are tested together.

A regulated model separates creating, publishing, and using. Identities have limited rights, sessions run under control, and negative access tests belong to sharing. This keeps the same agent traceable across multiple channels.

Check session and sign-out behavior

Authentication does not end with the first login. To test, verify expired tokens, account switches, inactivity, browser changes, and sign-outs. A shared device must not pass on a previous session or its conversation context.

The channel must respond clearly when re-login is required. Endless loops between the website and identity service become visible through tests with different browser and cookie settings. Session duration follows the risk of the use case.

Organize Teams deployment and release for sharing

For Teams, define the app package, policies, target audiences, and update path. A technical release does not automatically make the agent discoverable for all users. Pilot groups and approved catalogs allow controlled expansion.

Tests include desktop, web, and mobile usage, as far as the target process requires them. Deep links, notifications, and tenant switches can also differ. Support receives the exact app version and the deployment channel.

Secure websites against direct abuse

An embedded agent must not be protected only by the visible website. The endpoint, token output, allowed origins, and API calls require their own controls. An attacker can send requests outside the user interface.

Input limits, rate limits, and security monitoring limit automated abuse. For external audiences, consent, privacy, and retention texts are integrated into the actual conversation flow. The responsible parties also check accessibility and mobile display.

Maintain channel tests as a repeatable acceptance set

A shared test core checks login, allowed questions, prohibited data, tool actions, cancellation, and handoff. Channel-specific cases supplement display, sessions, and identity handoff. Every release goes through at least the critical paths.

Results are documented with channel, agent version, user role, and timestamp. This allows assigning a failure to a configuration change. A passed test in the authoring interface does not replace this end-to-end check.

Trace identity changes between channel and tool

The user can be logged in to the channel while a tool works via a different connection or technical identity. These transitions are documented per action: Who authenticates the user, which token reaches the agent, with which identity does the tool call the target system, and where is the authorization checked? Only then can Least Privilege be assessed end to end.

In the test, users with different roles are guided through the same conversation path. The visible answer, the tool call, and the audit proof must match the respective access. If a channel switches to an application-based identity, the system instruction must not replace missing authorization. The business action then requires its own filters, sharing for document permissions, approval for authorization, and clear responsibility.

Decide separately for guest and external users

An internal Teams agent is not automatically suitable for guests. The team checks tenant membership, Conditional Access, license prerequisites, data sources, and tool permissions for each external audience. On a public website, the agent needs a different identity and abuse model than in the logged-in employee channel. Instead of opening the same release for everyone, separate agents or channel configurations can be sensible. The decision is supported by negative access tests and rechecked when guest rules or audiences change.