Microsoft Foundry Agent Endpoints: Stable URLs, Version Pinning, and No Traffic Splitting

Stable endpoints and immutable versions

• Each agent gets a stable endpoint at creation, with no separate publish step required to make it reachable.
• The endpoint URL stays fixed even as the underlying agent configuration changes.
• Each agent version is an immutable snapshot; any change, even editing a single prompt, produces a new version.
• The agent itself is the stable entity with a consistent identity, endpoint, and authorization surface. Administrators choose which version receives traffic through a version_selector.

Routing policies

• The default policy is "always use latest," which immediately serves any newly created version.
• The alternative pins traffic to a specific version, useful once an agent is in production or published to Teams or Microsoft 365.
• There is no traffic splitting: exactly one version can be active at a time, so canary rollouts and gradual migrations are not possible with this mechanism.

Protocols and authorization

• Each endpoint can expose several protocols simultaneously: Responses, the Activity Protocol, Invocations, A2A (v1.0 GA, v0.3 in preview), and MCP (preview).
• Authorization is Entra ID–based only; API key authentication is not supported. Callers must hold a Foundry role on the project or agent scope.
• Publishing to Microsoft 365 or Teams automatically configures the BotServiceRbac and BotServiceTenant schemes and requires the Activity Protocol to be enabled.

M365 private-network workaround

• Microsoft 365 does not support private connectivity for agents.
• The enable_m365_public_endpoint option in the Activity Protocol configuration opens only that route to public traffic, filtered by service-managed source IP checks.
• The documentation is explicit that this does not replace authorization: BotServiceRbac or BotServiceTenant must remain in place.

Operational caveats

• Role names were recently renamed: Foundry User, Foundry Owner, and so on replace the Azure AI–prefixed names, though role IDs and permissions are unchanged.
• The documented code uses packages in preview, provided without a service-level agreement and not recommended for production workloads.
• Troubleshooting guidance covers predictable failure modes: 403s from missing roles, 401s from stale tokens, tool-call failures from under-scoped agent identities, and M365 publish failures when an agent lacks a unique identity (the latter requiring migration from the older Agent Applications model).

Omissions and risk

• The endpoint model has no traffic splitting, so version rollback is all-or-nothing.
• The "always use latest" default means an untested version can go live the moment it is created.
• Pinning is the documented remedy, but it requires an operator to remember to update the selector when a version is actually meant to ship.
• For teams running agents in production, the default is arguably the riskiest setting in the system.