Identity Strategy for Agents
Plan how agents authenticate users and access enterprise data — SSO, OAuth, delegated vs application permissions, and channel-specific identity behaviour.
Why identity strategy is a planning decision
Think of your agent as a receptionist at a secure office building.
When someone walks in, the receptionist needs to know: Are you an employee? (SSO — you already swiped your badge at the front door.) Are you a visitor who needs to sign in? (Manual OAuth — show your ID, get a temporary pass.) Or are you just asking a question at the information desk? (No auth — anyone can ask general questions.)
The receptionist also has their own access card for the building’s back offices. Sometimes they use YOUR badge to open doors on your behalf (delegated permissions). Other times they use their own master key that works 24/7 (application permissions). Choosing wrong means either employees cannot access what they need, or the receptionist has too much power.
Authentication models
Copilot Studio agents support three authentication configurations. The right choice depends on the channel, the data sensitivity, and the user experience you want.
| Feature | How it works | Supported channels | User experience | Best for |
|---|---|---|---|---|
| SSO (Single Sign-On) | Agent inherits the user's Entra ID token from the host app — no sign-in prompt | Teams and M365 Copilot only | Seamless — user never sees an auth prompt | Internal agents where users are already signed into Teams/M365 |
| Manual OAuth 2.0 | Agent displays a sign-in card. User clicks, authenticates with the IdP, and returns a token | All channels (Teams, website, Direct Line, Facebook, etc.) | One-time sign-in card — friction but works everywhere | Multi-channel agents or external-facing agents with authenticated features |
| No authentication | Agent does not authenticate the user. All users are anonymous | All channels | Zero friction — anyone can chat immediately | Public FAQ agents, lead capture, general information bots |
Exam tip: SSO is channel-restricted
SSO only works in Teams and M365 Copilot. If the exam gives you a scenario where an agent runs on a website or Direct Line and asks about SSO, the answer is “not supported” — you must use manual OAuth 2.0 instead. This is one of the most commonly tested distinctions.
Delegated vs application permissions
After authentication, the next decision is how the agent accesses backend resources. This is where delegated and application permissions diverge.
| Feature | Access scope | Token type | Requires user sign-in? | Use case |
|---|---|---|---|---|
| Delegated permissions | Agent acts as the signed-in user — sees only what that user can see | User token (on-behalf-of flow) | Yes — user must be authenticated | Accessing user-specific data: their emails, their calendar, their claims history |
| Application permissions | Agent acts as itself with its own identity — access is not scoped to a user | App-only token (client credentials flow) | No — works without any user context | Background tasks, cross-user data, system-level operations (e.g., searching all policy documents) |
The critical distinction: delegated permissions respect the user’s access boundaries. Application permissions bypass user context — the agent has whatever its app registration grants.
Security implication: application permissions
Application permissions are powerful and dangerous. An agent with Mail.Read application permission can read every user’s email in the tenant. In production, scope application permissions as tightly as possible and monitor usage through audit logs. The exam tests whether you understand this risk.
Configuring manual authentication
When SSO is not available (any channel outside Teams/M365 Copilot), you configure manual authentication. Here is the developer workflow:
- Register an app in Entra ID — set redirect URI to
https://token.botframework.com/.auth/web/redirect - Configure OAuth scopes — request only the permissions the agent needs (principle of least privilege)
- Add the authentication setting in Copilot Studio — enter the client ID, client secret, and token endpoint
- Use the Authenticate topic — Copilot Studio provides a system topic that triggers the sign-in card and stores the token in
System.User.AccessToken - Pass the token to connectors or HTTP actions — use the token variable in Authorization headers
# Conceptual flow — not actual YAML, but illustrates the token lifecycle
User sends message
-> Agent triggers Authenticate topic
-> Sign-in card displayed
-> User authenticates with Entra ID
-> Token stored in System.User.AccessToken
-> Topic uses token to call Graph API via HTTP action
-> Response returned to userScenario: Kai plans identity for Pacific Mutual
Kai is building two agents for Pacific Mutual Insurance:
Agent 1 — Claims Assistant (internal, Teams only)
- Users: 15,000 employees in Teams
- Data: User-specific claims records via internal API, personal calendar via Graph
- Decision: SSO + delegated permissions. Users are already in Teams, so SSO gives seamless auth. Delegated permissions ensure each adjuster only sees their own assigned claims.
Agent 2 — Policy Document Search (internal, Teams + SharePoint embedded)
- Users: Same employees, but the agent also runs as a web part in SharePoint
- Data: 200,000 policy documents in Azure AI Search (not user-specific)
- Decision: SSO in Teams, manual OAuth in SharePoint + application permissions for document search. The documents are not user-scoped — any authenticated employee can search them, so application permissions with a read-only scope are appropriate.
Kai documents both identity strategies before building any topics, because changing auth models mid-project means reconfiguring every connector and flow.
Channel-specific identity behaviour
Different channels handle identity differently. This table captures what the exam expects you to know:
| Channel | SSO available? | User identity source | Notes |
|---|---|---|---|
| Teams | Yes | Entra ID (from Teams session) | Richest identity context — UPN, display name, Entra object ID |
| M365 Copilot | Yes | Entra ID (from M365 session) | Same as Teams — SSO works seamlessly |
| Website (embedded) | No | Manual OAuth or anonymous | Must configure manual auth for user-specific features |
| Direct Line | No | Custom token from your app | Your host app handles auth, passes token via Direct Line secret |
| No | Facebook user ID (not Entra) | Cannot use Entra SSO — different identity provider entirely |
Kai's Claims Assistant runs in Teams and needs to show each adjuster only their own assigned claims. Which identity configuration should he use?
Priya is building an AgentForge recruitment agent that runs on a client's website and needs to access candidate data. Which auth model should she configure?
An agent with Mail.Read application permission is deployed. What can it access?
🎬 Video coming soon
Identity Strategy for Copilot Studio Agents