Solving the digital-employee identity

Microsoft's Agent 365 lets an organisation give an AI a real identity in its tenant: a digital employee that can be called, join meetings and act under its own name. Making one actually do those things involves three different Microsoft principals, some combinations the platform rejects, and behaviour the documentation did not yet cover. I probed the real tenant, captured what the wire said, and composed the paths that work. The employee answers calls, joins meetings and shares its screen.

The challenge

An identity that can answer an inbound call is not necessarily one that can place an outbound call, own a media session, or act in a meeting. Microsoft exposes the application identity, the agent identity and the calling bot as distinct principals, and the behaviour was preview-grade. I needed the employee to do all of it under its own name, without a shared super-account, with Microsoft remaining the authority on what it was allowed to do.

Answer an inbound call

agent identity, under its own name

Own the call's media

transport client, the one media platform

Place an outbound call

calling bot, as Microsoft presents it

Act in a meeting

agent identity, employee-scoped tokens

Constraints

Preview behaviour that could only be learned by trying it. Tokens that never reach a model: the AI that reasons about a call must never hold the credential that makes the call. No shared super-account. And Microsoft as the permission authority, so my layer could not grant anything the tenant had not.

My approach

Evidence over documentation. Every capability was probed against the real tenant with the wire traffic captured, and the design composed the paths that were proven to work instead of forcing one principal to do a job the platform rejected for it.

What I built

A dual-client calling composition. The employee identity answers inbound calls under its own name; a transport-only client owns the single native media platform that the call audio flows through.

An MCP server for employee actions where every call names the employee it acts for, and the server mints employee-scoped Graph tokens through certificate assertions, checked in-process before use. The model asks for an action; the server holds the credential.

Model

act as this employee

names the employee and the action, carries no credential

Server

assertionemployee token

minted for that one employee, checked in-process, never returned

model sideserver side

Difficult decisions

Taking the platform's constraint on outbound calls. An outbound call from the employee presents to the recipient as a separate calling bot, because that is how Microsoft's model works. I could have made it appear to come from the employee.

An identity layer that spoofs is not an identity layer.

Results

a Teams meeting

MEthe employee: chats, presents, shares a screen

Phand raised: called on

Pa person

Pa person

It also answers inbound calls and joins and leaves meetings, all under its own name.

Technologies used

Microsoft Graph · Entra Agent ID · Agent 365 · C# · Rust MCP server · Certificate-based credentials · Identity and access management for AI agents

What this demonstrates

I can work at the Microsoft 365 identity layer where the documentation runs out, from captured evidence, and build an identity design that keeps credentials away from the model and keeps the platform honest about who is acting.

I ran the probes, read the wire and designed the composition; AI coding agents, a mix of frontier and open-source models, implemented the server and installer under my direction. The identity platform is Microsoft's.