Publishing and identity: Entra, Teams, and A2A
Lesson 5 of 5 in Microsoft Foundry Agent Service, Three Ways to Run an Agent.
Microsoft’s real differentiator is not the loop. Everyone has a loop. It is that the agent lands in the same directory, on the same admin consent flows, and in front of the same Microsoft 365 Copilot and Teams surfaces as every other principal in the tenant.
Start with identity, because everything else is a consequence of it. Microsoft Entra Agent ID extends Entra to AI agents: agent identities are a special kind of service principal, created from agent identity blueprints — reusable templates with parent-child relationships — and the framework supports OAuth 2.0, MCP and A2A.
The anatomy is worth memorising, because it encodes an opinion about accountability. An Entra agent identity has an object ID, a display name, an optional human sponsor — an accountable user or group — and is created from a blueprint. Crucially it has no credentials of its own: the blueprint acquires tokens on its behalf. Some agents additionally get a 1:1-linked “agent’s user account”.
“No credentials of its own” is the sentence to underline. There is no agent secret to leak, no API key in a container image, no shared service principal that fifteen agents inherit. And the sponsor field answers the question every auditor eventually asks: which human is accountable for this thing?
| Situation | Token acquired | Who the downstream system sees | Consequence |
|---|---|---|---|
Autonomous agent — no user in the loop | App token, acquired via the blueprint. | The agent identity itself. | Permissions must be granted to the agent as a principal — so least privilege scoping is an explicit, reviewable act rather than an accident of whoever ran it. |
Interactive agent — called with a user token | User token via OAuth 2.0 On-Behalf-Of (OBO). | Subject = the user; actor = the agent identity. | The agent inherits the user’s reach, which is convenient and dangerous: it cannot exceed that user, and it also cannot be less than them unless you scope the request. |
Hosted agent in Foundry | Automatic: every hosted agent receives a dedicated Entra identity; with a user token present it can use OBO, without one it authenticates as itself. | Per agent, not per project. | Two agents in the same project are distinct principals — you can grant one CRM read access without granting the other anything. |
Prompt agent in Foundry | Entra agent identity is supported per Microsoft’s compare-agent-types table. | The agent identity. | Declarative agents are not second-class citizens for authorization purposes — the no-infrastructure path still gets a real principal. |
Publish to Teams and M365 Copilot
Publishing a Foundry agent to Microsoft 365 Copilot and Microsoft Teams does four things: compiles a Teams app manifest, submits it to the M365/Teams agent catalogs, enables the Activity protocol, and sets an authorization scheme. Foundry supports the OpenResponses and Activity protocols for M365 publishing.
Behind it, publishing creates or uses an Azure Bot Service resource that proxies messages between Microsoft’s channel adapters and your agent. That is why a Foundry agent can appear in Teams without you writing a bot.
The governance detail that decides your rollout plan: scope “Just you” requires no admin approval, while “People in your organization” requires Microsoft 365 admin approval. Self-service prototyping is easy; org-wide distribution is deliberately a gate.
When the project has no public network access
Portal publishing is unsupported for projects that disable public network access. Those agents publish via REST with enable_m365_public_endpoint, which opens a scoped, source-IP-filtered public route for only the Activity Protocol endpoint — because Microsoft 365 cannot reach private endpoints.
Requests arriving from allowed Microsoft service IP ranges still have to pass Bot Service or Entra authentication, and management APIs stay private.
Say the trade-off out loud before you sign off on it: to be reachable from Teams, a deliberately private project accepts one narrow, authenticated, IP-filtered ingress. That is a defensible design — and it is also a change to your network posture that belongs in a review, not in a deployment script nobody read.
Expose it to other agents (A2A, preview)
Foundry Agent Service supports the A2A protocol (preview) for agent-to-agent communication: an agent can be exposed as an incoming A2A endpoint so other agents call it directly. Microsoft positions this for lightweight hand-offs without a formal multi-step workflow — and, notably, as one of the migration targets for retiring visual workflows.
This is the same interop story you meet in the protocols domain: A2A makes an agent addressable as an agent rather than as an HTTP API you happen to have wrapped. The trade is that choreography stops being visible in any one place.
Preview, in September 2026. Fine for internal hand-offs; think hard before a partner integration depends on it.
Versions and traffic
Foundry versions agents automatically as you iterate, with snapshots, rollback and comparison. A published agent has a stable endpoint that serves an administrator-selected active version.
The REST API supports version_selector rules — for example FixedRatio with traffic_percentage — so you can pin traffic to a known-good version or split it across two.
That is a canary deployment for a non-deterministic system, and it is the right primitive: since you cannot prove an agent change is safe by inspection, you ship it to a slice of traffic and watch the evals and traces. Note what this requires — an agent resource. The ephemeral pattern has none, which is the sharpest practical cost of that choice.
Key terms: A2A, MCP, least privilege, guardrails, egress control, trace
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.
Interactive flashcard deck.