Skip to main content
Every agent in Microsoft Foundry has a stable endpoint from the moment you create it. Behind each endpoint, a Foundry model processes user input according to the agent’s instructions and tools. When end users interact with your agent through Microsoft Copilot, Teams, your existing application, or other surfaces, they interact with the agent’s stable endpoint. Before you share your agent, verify these settings:
  • Active agent version — Confirm the version that receives traffic is the one you want end users to interact with. By default, the agent automatically updates to the latest version, which means a newly created version is immediately served. If that behavior isn’t what you want, pin traffic to a specific version.
  • Protocols and authorization schemes — Ensure they match where and how your users interact with the agent. For example, an agent published to Microsoft 365 or Teams must have the Activity protocol enabled and use a BotServiceRbac or BotServiceTenant authorization scheme.
This article shows you how to select the active version, enable protocols, set authorization schemes, and add an agent card. After you configure the endpoint, you can:
If you’re migrating from the previous publishing model, see Migrate from Agent Applications to the new agent model.

Prerequisites

The Foundry RBAC roles were recently renamed. Foundry User, Foundry Owner, Foundry Account Owner, and Foundry Project Manager were previously named Azure AI User, Azure AI Owner, Azure AI Account Owner, and Azure AI Project Manager. You might still see the previous names in some places while the rename rolls out. The role IDs and core permissions are unchanged by the rename.
Code in this article uses packages that are currently in preview. This preview is provided without a service-level agreement, and we don’t recommend it for production workloads. Certain features might not be supported or might have constrained capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.

Understand the agent object model

Before you configure the endpoint, understand how projects, agents, agent versions, and the stable endpoint relate to each other.
Diagram illustrating how Foundry projects organize agent versions and agents.
Foundry project: A folder that groups related resources such as agents, files, and tools. Agent version: An immutable snapshot of the agent’s configuration. Any change, even a single prompt edit, creates a new version. Agent: The stable, consumer-facing representation of an agent. The agent’s identity, endpoint, and authorization surface stay consistent as its underlying versions evolve, so consumers always interact with the same entity. Agent endpoint: The URL consumers call to invoke the agent. It’s live the moment you create the agent, with no separate publish step, and the URL doesn’t change as you roll out new versions. You configure which version it serves, which protocols it speaks, and how callers authenticate. For the full list of agent object properties, see the reference section at the end of this article.

Traffic routing

The agent’s version_selector determines how traffic routes to agent versions. Two routing policies are available:
  • Always use latest (default): 100% of traffic routes to the most recently created agent version. When the agent is published to Teams or Microsoft 365, creating a new version automatically updates what’s served in those channels.
  • Pinned to a specific version: 100% of traffic routes to the agent version you select, called the active agent version. New versions don’t change what’s served until you update the selector.
Pin to a specific version when you need stability across new versions, such as when an agent is in production or published to end users in Teams or Microsoft 365.

Protocols

An agent can expose multiple protocols simultaneously: To enable the A2A protocol on your agent, see Enable incoming A2A on a Foundry agent.

Authorization schemes

You can configure inbound authentication on the agent endpoint: API key authentication isn’t supported. Use Microsoft Entra ID (Azure RBAC) to authorize callers.

Configure the agent properties

By default, the version selector routes 100% of traffic to the latest agent version, the Responses protocol is enabled, and authorization is set to Entra. You can change the version routing, enable more protocols, set authorization schemes, and add an agent card.

Select the active agent version

By default, the routing policy is Always use latest. To pin traffic to a specific version, update the version_selector.
  1. In the Foundry portal, create an agent or open an existing agent.
  2. Expand the Publish dropdown to see endpoint configuration options. Expected result: You see the available endpoints for your agent and the current version routing configuration. The endpoints are live from agent creation; no publish step is required to activate them.
  3. Select the version selector arrow and choose a specific version. Expected result: The stable endpoint routes 100% of traffic to the selected version. When pinned, creating new versions doesn’t change what’s served.

Enable protocols and authorization schemes

An agent can expose multiple protocols simultaneously. Configure protocols and inbound authorization on the agent endpoint.
Updating protocols and authorization schemes isn’t yet configurable in the Foundry portal. Use the REST API or Python SDK.

Allow Microsoft 365 traffic to a private-network agent

If your project disables public network access, set enable_m365_public_endpoint to true inside the activity protocol configuration before you publish the agent to Microsoft Copilot or Teams.
This setting lets the agent’s Activity Protocol endpoint receive Microsoft 365 channel traffic, including Teams, while public network access remains disabled for the Foundry account. Foundry applies this network exception only to the Activity Protocol route. Service-managed source IP filtering allows requests delivered through Azure Bot Service or Microsoft 365 infrastructure and blocks requests from other public networks. You don’t need to change the Foundry account’s network settings or configure public ingress in your virtual network. Other agent protocols and project APIs remain private. Microsoft 365 doesn’t support private network connectivity for agents and requires the agent endpoints it invokes to be routable over the public internet. Enabling this setting meets that requirement for the Activity Protocol route. Network restrictions don’t replace authorization. Keep BotServiceRbac or BotServiceTenant configured in authorization_schemes so that requests must also pass token validation, tenant checks, and RBAC where applicable. If the setting is omitted or set to false, private-network controls continue to block all public Activity Protocol requests. This PATCH replaces protocol_configuration and authorization_schemes, so include every protocol and authorization scheme that the endpoint must retain. For the complete publishing flow, see Publish agents to Microsoft Copilot and Microsoft Teams by using the REST API.

Add an agent card

An agent card surfaces details and capabilities to consumers, including for agent-to-agent (A2A) discovery.
You can’t yet configure adding an agent card in the Foundry portal. Use the REST API or SDK.

Get your agent properties

To view your agent’s current properties - identity, protocols, authorization, and endpoint configuration - run:

Security and privacy considerations

  • Use least privilege. Grant users the minimum role they need. For example, create custom roles that separate agent creation permissions from agent invocation permissions.
  • Don’t embed access tokens in source code, scripts, or client applications. Use the Microsoft Entra authentication flow appropriate for your app.

Limitations

Troubleshooting

Reference: Agent object properties