Whose authority is the agent acting with?
Lesson 1 of 5 in Microsoft Foundry Agents in Practice: Identity, Boundaries, Guardrails, Traces, Bills.
The previous module was the catalogue: prompt agents, hosted agents, Toolboxes, conversations and responses. This one is day two. The agent works, somebody wants it in front of real users, and now five questions decide whether that goes well — and none of them is about the loop:
whose authority does it act with, where does its data sit, what stops it doing the wrong thing when a document tells it to, how do you find out what it did, and what shows up on the bill. Those are this module’s five lessons.
Start with identity, because on Microsoft Foundry it is the load-bearing one. Foundry does not treat an agent as an anonymous process holding a connection string. Every hosted agent automatically receives a dedicated Microsoft Entra identity, and prompt agents support an Entra agent identity too. That single design choice is what makes the rest of the platform — least-privilege role assignments, auditability, approval and revocation — mean anything.
An Entra agent identity is not a user and not quite a classic app registration. Microsoft describes it as a special kind of service principal, created from an agent identity blueprint — a reusable template with parent-child relationships. The identity itself has an object ID, a display name, an optional human sponsor (the accountable user or group), and — this is the part worth memorising — no credentials of its own. The blueprint acquires tokens on its behalf. Some agents also get a 1:1-linked agent’s user account.
The two token shapes follow from how the agent is invoked. An autonomous agent running on a schedule acquires app tokens — it is acting as itself. An interactive agent called with a user token can acquire user tokens via OAuth 2.0 On-Behalf-Of, where the subject is the user and the actor is the agent identity. That distinction is the whole compliance story: the audit log can say this agent, acting for this person, read that document, instead of something called svc-prod-07 read everything.
Key terms: Entra Agent ID, on-behalf-of (OBO), least privilege, managed identity, agent identity, RBAC
| Auth type | Whose identity the downstream service sees | Reach for it when | The trap |
|---|---|---|---|
None | Nobody — the endpoint is unauthenticated. | Genuinely public, read-only data. Almost nothing else. | An unauthenticated tool is still an untrusted input channel. Whatever it returns lands in your context window. |
Custom keys | A shared secret — indistinguishable from any other caller holding it. | A third-party SaaS API with no Entra story. | Per-agent attribution disappears. Keep the key in the platform’s credential store, never in instructions or code. |
OAuth2 (Foundry-managed app or your own registration) | A registered OAuth client, scoped by the consented scopes. | SaaS tools that speak OAuth and you want scope-limited access. | Scopes granted once tend to outlive the reason they were granted. Review them like IAM policy. |
User Entra token | The end user, with the agent recorded as actor — the OBO path. | The agent should see exactly what this user can see, and nothing more. | Requires a user token in the request. There is no OBO for a 3 a.m. cron run. |
Project managed identity | The Foundry project — one identity shared by everything in it. | Project-scoped infrastructure access (storage, search) where per-agent granularity is not the point. | Every agent in the project inherits the same reach. Blast radius is project-wide by construction. |
Agentic identity (the agent’s own Entra identity) | This specific agent, as itself. | Autonomous work with no user in the loop, where you want per-agent RBAC and per-agent audit. | It is a new principal to govern: assign roles narrowly, name a sponsor, and plan how it gets revoked. |
Which credential should this one tool connection use?
Interactive decision tree — outcomes:
- User Entra token — On-Behalf-Of
The agent exchanges the user token for a downstream token: subject = the user, actor = the agent identity. The user’s existing permissions become the ceiling automatically, and the audit trail names both parties. This is the cheapest correct answer in the whole module — you inherit an authorization model somebody already maintains.
- Stop — do not substitute a broad app identity for the user
The tempting move is to give the autonomous agent standing access to everyone’s data and let its instructions decide who it is "acting for". That is a prompt enforcing an access-control rule, which is not enforcement at all. Either capture consent while a user is present, or narrow the autonomous run to data that needs no per-user rule.
- Agentic identity — the agent’s own Entra identity
A hosted agent already has one, so use it: assign narrow RBAC roles to that principal, name a human sponsor, and you get per-agent least privilege plus logs that identify the actor. Budget for governing a new principal — including how it is revoked when the agent is retired.
- Project managed identity
Fine for shared infrastructure access, with eyes open: every agent in the project inherits the same reach, so the blast radius of a single compromised agent is the project’s whole role assignment set. Revisit this the day the project holds two agents with different risk profiles.
- Keys or OAuth2 — held by the Toolbox, not the agent
Put the connection behind a Toolbox and let the platform do centralized credential injection, token refresh and policy enforcement, so consuming agents never handle per-tool credentials. A secret in a system prompt or a container image is a secret in your traces and your registry.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.