Before running any tooling, know what objects it creates — every one of them is an Entra object a security or identity administrator will govern later:

Before the SDK can register with the M365 admin center, the Azure tenant must be enabled for Agent 365. This is a separate prerequisite from licensing — a licensed tenant is not automatically an enabled one — and it is done once by the admin:

• ▸The Agent 365 CLI authenticates through the “Agent 365 CLI” public client app, which must exist in the tenant with admin consent for its Graph scopes (agent blueprint, identity, and registration permissions). a365 setup requirements creates and consents it.
• ▸Registration creates standard Entra objects — a blueprint application, an agent identity (a service principal of type ServiceIdentity), and the registration record. The agent’s observability permission is an app role on the Agent 365 observability resource and needs admin consent like any other application permission.

The Agent 365 SDK provides two separate capabilities, plus an optional third:

The SDK’s observability package is vendor-neutral. Microsoft also ships vendor-specific tooling extensions — including one for Anthropic’s Claude (npm: @microsoft/agents-a365-tooling-extensions-claude; Claude Enterprise only, standalone Claude accounts are not supported) — that handle the agent’s tool/MCP integration; telemetry itself comes from the shared observability package.

Notes from the lab build:

• ▸The agent ran on a local machine behind a dev tunnel, with no Azure compute. Registration and identity live in Entra; the runtime only needs a reachable messaging endpoint.
• ▸The tenant settings from Part 1 apply unchanged: an SDK-instrumented agent in an unlicensed tenant, or behind a disconnected Security-for-AI connector, shows nothing.

For new agent code, the Microsoft OpenTelemetry Distro emits the convention by default, and the get-started guide covers the CLI-driven setup.

The SDK does not connect a Claude subscription to Agent 365 by itself. What gets built is one concrete artifact: a small web service — in the lab, a Node.js app of a few hundred lines — that exposes a messaging endpoint. That service is the agent as far as the tenant is concerned: the registration points at its endpoint, Teams delivers user messages to it, and its replies and telemetry come back from it.

Each incoming message follows the same loop: receive the message → authenticate as the agent → call Claude → reply to the user → emit the spans.

Use case 1 — a Teams user chats with the agent instance; the built web service authenticates as the registered agent identity, calls Claude, replies, and emits gen_ai spans to Agent 365.

The building blocks inside that service:

The service can run anywhere its endpoint is reachable; in the lab it ran on a local machine behind a dev tunnel. This is the pattern the lab verified end to end.

The same SDK pattern supports a different job: a collector agent that watches what users do in the Claude application on their Windows devices and feeds that activity into the Microsoft security stack. Here the SDK-built service has no chat surface at all — its input is the local Claude usage/audit logs, and it emits two outputs:

Use case 2 — the collector reads local Claude logs and emits raw events to Sentinel (alerting) and user-attributed gen_ai spans to Agent 365 (inventory, hunting, audit).

How each service uses the telemetry:

Caveats: what the local Claude application logs (and where) depends on the edition and version deployed — confirm log availability on a reference device before building. And the general rule from Part 1 applies: validate each leg at its destination (a Sentinel query for the custom table, the CloudAppEvents query for the spans), not from send-side success.

A trace is a tree of timed operations called spans. The gen_ai convention defines four span operation types: invoke_agent, chat, execute_tool, and output_messages. The first three cover most agent activity, and each maps to a Defender CloudAppEvents ActionType:

Ingestion enforces three rules:

A note on the obvious shortcut: some tools (Claude Code among them) can emit OpenTelemetry natively, and pointing that output directly at Agent 365 appears to work — the request returns HTTP 200. Every span is rejected individually, because the names and attributes follow the vendor’s convention, not gen_ai. The direct OpenTelemetry integration path is for code you instrument yourself to emit the convention; it does not accept other formats.

The full wire specification is in the observability concepts documentation; read it before writing any integration.

Validate in this order — each step depends on the one before it:

Remember the field semantics from Part 1: AgentId is the caller (all-zeros for human-initiated runs); the invoked agent is in TargetAgentId; filter on both.

If the hunting query returns zero rows a day after setup, work backward: was the agent invoked; is the license assigned; is the Security-for-AI “Microsoft 365” connector connected; and is the telemetry actually in the gen_ai format.

Before an SDK-onboarded agent goes into production use, review it the way any new workload identity would be reviewed:

• ▸☐ The agent identity has a named owner and sponsor (Entra ID > Agents).
• ▸☐ The blueprint grants enumerated, least-privilege scopes — permissions granted at the blueprint are inherited by every agent created from it.
• ▸☐ The observability app role consent is reviewed and recorded like any other application permission grant.
• ▸☐ Conditional Access covers agent identities (Part 1, Entra section) — including this one.
• ▸☐ Instance requests route through the admin approval queue, with an assigned approver.
• ▸☐ The agent’s tool access is restricted to what its job requires — execute_tool telemetry only shows the tools the agent has, and tool access is also its attack surface.

Previous: Part 1 — the building blocks, onboarding Microsoft-native agents and SaaS AI platforms, and verifying agents in Defender.

• Agent 365 SDKMicrosoft Learn
• Agent 365 CLIMicrosoft Learn
• Get started with Agent 365 developmentMicrosoft Learn
• Agent 365 observability conceptsMicrosoft Learn
• Microsoft OpenTelemetry DistroMicrosoft Learn
• Direct OpenTelemetry integrationMicrosoft Learn
• Microsoft Agent 365 overviewMicrosoft Learn
• Agent 365 Tooling SDK for Claude (npm)npm
• Logs Ingestion API in Azure MonitorMicrosoft Learn
• Create custom analytics rules in Microsoft SentinelMicrosoft Learn
• Connect Microsoft Defender XDR data to Microsoft SentinelMicrosoft Learn