Autopilots in Microsoft Foundry: The Identity Model Behind Agents That Act as Themselves

Autopilots in Microsoft Foundry: The Identity Model Behind Agents That Act as Themselves Every agent framework eventually runs into the same wall: what happens when there's no user to act on behalf of? A ticket queue fires an event at 2 a.m. A group chat needs a status update and there are six people in the thread, none of whom asked for it. A "digital coworker" is supposed to triage incidents across a whole team, not impersonate whoever happens to be logged in when the alert lands. Microsoft Foundry's answer to this is a new agent category called an autopilot, and it's not a prompting pattern or a orchestration framework - it's an identity primitive. If you've been building Foundry hosted agents and assumed "autopilot" was just marketing language for "very autonomous agent," this article is going to change how you scope, provision, and reason about a meaningful slice of enterprise agent architecture. This is Day 3 of the Foundry 100 Days / 100 Blogs series. Day 1 covered crash-resilient long-running agents (leases, checkpoints, side-effect fencing). Day 2 covered the Responses vs. Invocations hosting protocols. Today we go one layer deeper into the identity plane: what actually makes an autopilot different from every other Foundry agent, how its lifecycle works across four distinct roles, and what you need to build, provision, and govern one in production. A note on maturity: Autopilots require Frontier preview program enrollment and Microsoft Agent 365 licensing at the time of writing. Treat the identity model as stable conceptually, but expect API and licensing details to shift before general availability. (verify current program status before building on this in production.) Table of Contents - The Problem: Agents Without a "Self" - What Actually Defines an Autopilot - The Identity Model: Agent Identity vs. Agent User Account - Three Agent Types Foundry Supports - Why You Build a Blueprint, Not an Autopilot - The Autopilot Lifecycle: Four Roles, Three Layers - Implementation Walkthrough: Provisioning Your First Autopilot - Runtime Behavior: What Happens When a Message Arrives - Production Considerations - Security Considerations - Cost and Licensing Considerations - Common Mistakes and Pitfalls - When Not to Use an Autopilot - Practical Recommendations - Conclusion - References The Problem: Agents Without a "Self" Standard Foundry hosted agents - the kind we've covered in this series so far - authenticate as a service principal (the agent identity) and, in most assistive scenarios, act on behalf of a signed-in user. That model is fine for a request/response assistant: a user asks, the agent does something scoped to that user's permissions, done. It breaks in two specific, common enterprise situations: - No user in the loop. An event-triggered agent - a webhook from a CI pipeline, a monitoring alert, a scheduled sweep of stale tickets - has no signed-in user to impersonate. Under the assistive model, it simply can't take Microsoft 365 actions like sending an email, updating a document, or posting to a channel, because there's no one whose permissions it can borrow. - Group settings. In a Teams group chat, "on whose behalf" has no correct answer. Attribute the action to whoever sent the last message and now a compliance officer's permissions apply to a thread they weren't paying attention to, or worse, other members get exposed to content scoped to that one person's access. Both problems have the same root cause: the agent has no identity of its own in Microsoft 365. It's infrastructure, not a participant. An agent user account - a genuine Entra user object with a mailbox, a Teams presence, a manager, and a place in the org chart - resolves this by giving the agent something to be rather than something to borrow. That's the entire idea behind an autopilot. Everything else in this article is really an elaboration of that one design decision. What Actually Defines an Autopilot It's tempting to define autopilots by their capabilities - memory, planning, proactivity, learning. Resist that framing; Microsoft's own docs explicitly call it out as the wrong model, and I think they're right. Capabilities are a feature list. They change every release. If a capability set defined the category, an assistive agent that gains long-term memory in the next SDK bump would silently become an autopilot without anyone deciding that it should hold a standing role or answer to a manager. That's an accident, not an architecture. Autonomy doesn't define it either. A background-service agent (see the table below) can run unattended all day, restarting VMs or reconciling data pipelines, and it's still not an autopilot - it has no presence in Microsoft 365 at all. Autonomy and identity are orthogonal. Identity is the only reliable definition. An autopilot is any Foundry agent that has, in addition to the agent identity every agent gets, an Entra agent user account. That's a binary test: either the account exists or it doesn't. Nothing else needs to be true. The Identity Model: Agent Identity vs. Agent User Account Every Foundry agent, from the moment it's created, gets an agent identity - a service principal produced by an agent identity blueprint. It has an ID, a name, a sponsor, and the permission set the agent authenticates with at runtime. For a regular agent, that's the whole identity story: one blueprint, one agent, one identity, full stop. An autopilot adds a second object on top: the agent user account. This is a genuine Entra user object - not a service principal wearing a costume - with a display name, a user principal name, a manager, a mailbox, a Teams presence, and a slot in the org chart. It's what lets the autopilot send an email as itself, get @mentioned in a channel, and be treated as a teammate rather than a webhook target. | Object | Type | Holds | Used for | |---|---|---|---| | Agent identity | Service principal | Agent ID, name, sponsor, runtime permissions | Authenticating infrastructure calls; securing the running container/process | | Agent user account | Entra user object | Display name, manager, UPN, mailbox, Teams presence | Acting as itself in Microsoft 365 - sending mail, posting in Teams, editing docs | These two objects are never interchangeable and they do different jobs at different layers. For an autopilot, the agent identity secures the infrastructure that runs the agent (think: the container's managed identity calling Azure resources), while the agent user account represents the autopilot the moment it reaches into Microsoft 365. This distinction matters architecturally because it changes the shape of the object graph. A regular agent is one-to-one: one blueprint produces exactly one agent, with exactly one agent identity, and no user account. An autopilot is one-to-many: one blueprint is hired repeatedly, and every hire produces a new instance with its own agent identity and its own agent user account. Ten teams hiring the same blueprint means ten agent identities, ten mailboxes, ten distinct sets of group memberships - sharing one codebase and one declared capability set, but not sharing a single runtime identity or a single grant of access. Three Agent Types Foundry Supports Foundry doesn't force every agent into the autopilot model - most agents shouldn't be autopilots. There are three categories, distinguished entirely by identity: | Type | Identity | Behavior | Best fit | |---|---|---|---| | Assistive | Agent identity + signed-in user context | Acts on behalf of a user, constrained to that user's permissions | Personal productivity - a meeting-prep agent that drafts a deck when asked | | Background service | Agent identity only | Acts as itself via app-only permissions; autonomous but no Microsoft 365 presence | Backend automation - an ops agent that restarts a VM in response to an alert | | Autopilot | Agent identity + agent user account | Acts as itself in Microsoft 365, including group settings; autonomous within a defined scope | Digital coworkers - a release manager that coordinates work across a Teams channel | If your agent's job is "do this thing when I ask," it's assistive. If it's "run backend jobs no human watches," it's a background service - and functionally this is closest to what we discussed for long-running hosted agents in Day 1 of this series. Only reach for an autopilot when the agent genuinely needs a standing, addressable identity that a whole team interacts with - because that identity comes with real overhead: licensing, a manager, onboarding, and ongoing governance. Why You Build a Blueprint, Not an Autopilot Here's the part that trips up developers coming from a "just deploy the agent" mental model: you don't create an autopilot directly. You build and publish a blueprint - a declared role, a set of tools, a permission scope, and behavioral logic - and then teams hire instances from that blueprint. Each hire is a separate autopilot with its own identity and its own team-scoped grants. The reason is structural, not bureaucratic. Suppose you build the agent directly and grant it access to your team's SharePoint site and security group. That access is exactly what makes it useful to your team - and exactly why no other team can reuse it. They'd inherit your team's access, which they shouldn't have, so they build their own near-identical agent. Multiply by ten teams and you get ten independently-governed copies of the same logic, whose behavior drifts apart over time and whose compromised-tool blast radius has to be chased down one agent at a time. A blueprint separates what the agent can do (declared once, by a developer, and approved once, by a tenant administrator) from what a specific instance can reach (granted per-team, by a manager, at hire time). One codebase, many independently-scoped identities. This is the same logic that governs container image reuse across microservice deployments, applied to agent identity instead of compute. The Autopilot Lifecycle: Four R