[Naveen Chatlapalli (1aifanatic)]

Motivation & Context

The M365 Agents SDK sample (python/samples/05-end-to-end/m365-agent) does not start, and once startup is fixed, anonymous mode still cannot answer a message. Details and reproduction in #9595:

1. web.Application(middleware=...) raises TypeError, because aiohttp's keyword is middlewares. The middlewares → middleware rename (Python: [BREAKING]: removed display_name, renamed context_providers, middleware and AggregateContextProvider #3139) appears to have caught it.
2. FoundryChatClient() is created without a credential, and the README still documents OpenAI variables.
3. The current M365 Agents SDK (1.9.0) requires a connection manager for CloudAdapter and AgentApplication. ClaimsIdentity now takes (claims, authentication_type, ...), so the sample's "anonymous" identity was treated as authenticated and the adapter tried to get an MSAL token (TENANT_ID is not set).

Description & Review Guide

• What are the major changes?
  • web.Application(middlewares=[middleware_fn]).
  • FoundryChatClient(credential=AzureCliCredential()). The README now lists FOUNDRY_PROJECT_ENDPOINT / FOUNDRY_MODEL and az login, and the docstring no longer points to a nonexistent .env.example.
  • In anonymous mode, build_connection_manager returns an MsalConnectionManager with an empty SERVICE_CONNECTION, and build_authorization always builds Authorization. Anonymous requests never request tokens, so the placeholder connection is never used.
  • The anonymous middleware injects ClaimsIdentity(authentication_type="Anonymous") with no claims, which ClaimsIdentity.allow_anonymous recognizes.
  • The run-command comment points to samples/05-end-to-end/... instead of samples/demos/....
• What is the impact of these changes? Sample only. Authenticated mode keeps its existing path: MsalConnectionManager(**agents_sdk_config) plus Authorization.
• What do you want reviewers to focus on? Whether an empty SERVICE_CONNECTION is an acceptable way to satisfy the SDK in anonymous mode, or whether you would rather the sample require connection settings even for local runs.

Verified with aiohttp's test client: create_app(load_app_config()) in anonymous mode, with the agent replaced by an echo stub and a local endpoint standing in for the channel service:

	result
main	TypeError at web.Application(middleware=...)
this PR	GET /api/health 200, GET /api/messages 200, POST /api/messages 202, and the reply activity reaches the channel

I also checked that the real build_agent() constructs with only FOUNDRY_* set. I could not test authenticated mode, which needs an Azure Bot registration. ruff format --check passes. ruff check reports one pre-existing E501 (the long approval_mode NOTE comment), which is also on main. Pyright's two remaining errors are pre-existing typing nits (an Optional return type and the sync lambda route handler), and both routes respond correctly at runtime.

Related Issue

Fixes #9595

AI Assistance

• No material AI assistance was used.
• This is an AI-assisted contribution. I reviewed, understood, and verified all submitted content and accept responsibility for it.

AI assistance details: Claude Code helped trace the breakages through aiohttp and the M365 Agents SDK, implement the fix, build the test-client verification, and draft this description and the linked issue.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR links to an agreed issue with no competing open PR, or the Related Issue section documents a trivial-change or repository-automation exception.
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

🤖 Generated with Claude Code

[Copilot]

🔵 Needs a closer look

The anonymous identity and empty MSAL connection depend on external SDK behavior that still needs independent verification before approval.

No open issues 🎉

What changed in this PR

This PR fixes startup and anonymous messaging failures in the Python M365 agent sample reported in #9595.

Changes:

• Corrects aiohttp middleware registration and supplies an Azure CLI credential to FoundryChatClient.
• Adds a placeholder connection manager and claim-less identity for anonymous mode while preserving the authenticated configuration path.
• Updates Foundry setup instructions and corrects the run-command and configuration comments.

File	Description
python/​samples/​05-end-to-end/​m365-agent/​README.md	Replaces OpenAI settings with Foundry configuration and Azure CLI prerequisites.
python/​samples/​05-end-to-end/​m365-agent/​m365_agent_demo/​app.py	Fixes startup, configures anonymous SDK components, and corrects usage comments.

_{Review effort: Balanced}

[Naveen Chatlapalli (1aifanatic)]

Following up on the "needs a closer look" note about relying on M365 Agents SDK behavior, I verified the two anonymous-mode pieces against the SDK source and across releases.

Why the anonymous path never touches the placeholder connection (microsoft-agents-hosting-core 1.9.0):

• ClaimsIdentity.allow_anonymous (authorization/claims_identity.py:47) is true when the authentication type is empty or "Anonymous" and there are no claims. This PR's middleware injects exactly that identity.
• ChannelServiceAdapter.process_activity passes claims_identity.allow_anonymous as use_anonymous (channel_service_adapter.py:417). RestChannelServiceClientFactory then returns an anonymous UserTokenClient / AnonymousTokenProvider without calling connection_manager.get_token_provider (rest_channel_service_client_factory.py:165).
• The empty SERVICE_CONNECTION exists only to satisfy the constructor checks: HttpAdapterBase (_http_adapter_base.py:75), ConnectionManager (authorization/connection_manager.py:98), and AgentApplication building Authorization (app/agent_application.py:209).

Version matrix: the sample's anonymous flow, run end to end with aiohttp's test client (agent stubbed, local channel endpoint capturing the reply):

hosting-core / aiohttp / msal / activity	main	this PR
1.0.0, 1.2.0, 1.3.0	TypeError (aiohttp middleware=)	fails: ClaimsIdentity() still requires claims, is_authenticated
1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0.dev1	TypeError (aiohttp middleware=)	health 200, /api/messages 202, reply delivered

Because the claim-less ClaimsIdentity(authentication_type=...) form starts at 1.4.0, I pushed b6fcdf3, which adds >=1.4.0 to the four microsoft-agents-* entries in the sample's PEP 723 header. An older environment now fails at resolution instead of at the first message.

Authenticated mode, with USE_ANONYMOUS_MODE=false and CONNECTIONS__SERVICE_CONNECTION__SETTINGS__* set, still builds MsalConnectionManager(**agents_sdk_config) and starts cleanly on 1.4.0, 1.9.0 and 1.10.0.dev1. A real token exchange still needs an Azure Bot registration, which I don't have.