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.
This article answers common security and privacy questions about Microsoft 365 Agents SDK agents that connect to Azure Bot Service.
Do agents registered with Azure Bot Service collect personal information?
Each agent is its own service. Developers of these services are responsible for providing terms of service and privacy statements and for protecting the data that their agents collect.
Can I host my agent on my own servers?
Yes. You can host your agent anywhere on the internet, including on your own servers, in Azure, or in another data center. The agent must expose a publicly accessible HTTPS endpoint.
How are agents banned or removed from the service?
Users can report a misbehaving agent through the agent's contact card in the directory. Developers must follow Azure terms of service to participate in the service.
Which URLs do I need to allow in my corporate firewall to access Azure Bot Service?
If an outbound firewall blocks traffic from your agent to the internet, add the following URLs to your allow list:
login.botframework.azure.cn(agent authentication)login.partner.microsoftonline.cn(agent authentication)*.botframework.azure.cn(channels)login.chinacloudapi.cn(Windows sign-in)login.windows.com(Windows sign-in)sts.chinacloudapi.cn(Windows sign-in)- Other URLs required by the specific Azure Bot Service channels that your agent uses
Note
If you prefer not to add a URL that contains an asterisk to your allow list, add <channel>.botframework.azure.cn for every channel that your agent uses. Examples include directline.botframework.azure.cn, and webchat.botframework.azure.cn. Monitor your firewall traffic while you test the agent to identify other blocked traffic.
Can I block all traffic to my agent except traffic from Azure Bot Service?
Azure Bot Service is hosted in Azure data centers worldwide, and the list of Azure IP addresses changes regularly. Adding individual IP addresses to your allow list might work temporarily and then stop working when the addresses change.
Which Azure RBAC role is required to create and deploy an agent?
Creating an Azure Bot resource in the Azure portal requires the Contributor role for either the subscription or a specific resource group. A user with the Contributor role for a resource group can create a resource in that group. A user with the Contributor role for a subscription can create a resource in a new or existing resource group.
By using Azure CLI, you can use a custom Azure Role‑Based Access Control (RBAC) role with more restricted permissions. The following permissions allow a user to create and deploy an agent with an Azure Bot resource, storage, and Application Insights:
"Microsoft.Web/*",
"Microsoft.BotService/*",
"Microsoft.Storage/*",
"Microsoft.Resources/deployments/*",
"Microsoft.Insights/*",
"Microsoft.Insights/components/*"
Inherited deny assignments take precedence over these allowed permissions.
What protects my agent from clients that impersonate Azure Bot Service?
Azure Bot Service and the Agents SDK use the following protections:
- Authentic Azure Bot Service requests include a JSON Web Token (JWT) with a cryptographic signature that the agent can verify. This validation prevents an attacker from impersonating a trusted service.
- The security token that accompanies each request includes the service URL. An attacker who obtains a token can't redirect the conversation to another service URL.
- If an incoming token is missing or malformed, the Agents SDK doesn't generate a token in response. This behavior limits the potential impact of an incorrectly configured agent.
- You can manually check the service URL in the token. This approach can make the agent more fragile if the service topology changes, so it isn't recommended.
Note
These protections apply to outbound connections from the agent to the internet. Azure Bot Service doesn't publish a fixed list of IP addresses or DNS names that it uses for inbound connections to an agent. Adding inbound IP addresses to an allow list isn't supported.
What is the purpose of the magic code during user authorization?
The Web Chat control supports two mechanisms to verify that the correct user signs in:
- Magic code: At the end of the sign-in process, the user receives a randomly generated six-digit code. The user enters this code in the conversation to complete sign-in. This approach interrupts the user experience and is susceptible to phishing attacks because a malicious user can trick another user into signing in and sharing the code.
- Direct Line enhanced authentication: Azure Bot Service can ensure that the sign-in process completes only in the same browser session as Web Chat. To use this protection, start Web Chat with a Direct Line token that contains a list of trusted origins, also known as trusted domains, that can host the agent's Web Chat client. You can specify the list of trusted origins on the Direct Line configuration page. Learn more in Direct Line enhanced authentication.
Because of the security and user experience limitations of magic codes, use Direct Line enhanced authentication when possible.
How does Azure Bot Service handle identity and access management?
Identity and access management (IAM) is a framework of policies and technologies that gives the appropriate people access to technology resources. Azure Bot Service and the Agents SDK provide the following mechanisms:
- Agent authentication: Determines whether a request came from a legitimate source. Azure Bot Service controls this process to support secure communication between an agent and a channel. Learn more in Configure authentication in your agent.
- User authorization: Allows an agent to access secured online resources on behalf of a user. OAuth authenticates the user and authorizes the agent to access the resources. Learn more in Configure your agent to use OAuth.
Azure Bot Service handles service-to-service authentication by validating that a request came from an expected channel. The agent is responsible for user authorization and other application-level access controls.