Entra Agent ID Across Clouds: Part 3, Managed Identity and Entra Objects

About this series. Five articles on running Microsoft Entra Agent ID against third-party clouds. Each one focuses on one layer of the trust story so you can read whichever part you actually need.

1. Entra Agent ID Across Clouds: Part 1, Lower Environment and Secrets
2. Entra Agent ID Across Clouds: Part 2, Federation End to End
3. Entra Agent ID Across Clouds: Part 3, Managed Identity and Entra Objects (this article)
4. Entra Agent ID Across Clouds: Part 4, FIC, Cross-Tenant, and OBO
5. Entra Agent ID Across Clouds: Part 5, Anti-Patterns

What this article covers

Part 2 walked the federated request flow end to end and named the four moving parts as if they were obvious: the UAMI, the Blueprint, the Agent Identity, and the FIC that ties the first two together. Most readers come away thinking the diagram is clear and the pieces are interchangeable. They are not. The UAMI is just a runtime witness, the Blueprint is the application registration, the Agent Identity is the principal downstream APIs see, and FIC is the trust contract that lets the UAMI authenticate as the Blueprint without a secret. Confuse any two of these in a deployment script and the failure looks like “the federation works once but stops on redeploy” or “the cloud audit log shows the wrong principal.”

This article walks each Entra object as a first-class concept: what it is, what it isn’t, where it appears in the JWT, and which directory operations apply to it. Then it answers the question every production deployment eventually has to answer: should the cloud federate the UAMI directly, or the Agent Identity? That choice does not change the secret-based-versus-federated decision from Parts 1 and 2. It is a variant of the federated pattern, and the trade between simpler topology and per-agent attribution is real.

By the end you will know what sub, azp, and oid each mean on the wire, which Azure object populates each, why a SAMI is a footgun in this architecture, and which knobs to turn when the cloud’s audit log shows the “wrong” identity. Part 4 picks up FIC itself: single-tenant, cross-tenant, and the orthogonal world of on-behalf-of.

---

What the managed identity is and is not

A reader who has just walked through the federated request flow often collapses three things into one: the UAMI, the FIC, and the Agent Identity. This section is the sanity check. The UAMI is the smallest of the three, and pinning down its job is the foundation for everything else.

What the UAMI is

A User-Assigned Managed Identity is a security principal in Microsoft Entra ID with its own object id (oid). It is not a token broker, not a federation service, not a sidecar. It is just an identity that Azure can prove the container owns at runtime, without giving the container any credential file.

The proof works like this. ACA injects IDENTITY_ENDPOINT and IDENTITY_HEADER into the container. Any process in the container can hit that local endpoint and ask “give me a JWT that says I am UAMI X, for audience Y.” ACA forwards the request, Entra signs an MI JWT (iss=Entra, sub=UAMI-oid, aud=<whatever you asked for>), and ACA hands it back. That is the entire job of the UAMI in the federated pattern. It produces a signed JWT, on demand, that says “I am UAMI X.”

What the UAMI is NOT

It is easy to read the federated sequence diagram and conclude that the MI is calling the cloud LLM and the Weather API. It is not. The MI never appears in any Authorization: Bearer ... header on a downstream call. It only ever appears as the input to a federation exchange.

Misconception	What actually happens
”The MI calls the cloud LLM”	The agent process calls the cloud LLM. The MI JWT was federated through the cloud’s contract and exchanged into a cloud-issued credential bound to a cloud-side principal. The LLM sees that cloud-side principal, not the MI.
”The MI calls the Weather API”	The agent process calls the Weather API. The MI JWT was federated through FIC and exchanged for an Agent Identity JWT. The Weather API sees the Agent Identity, not the MI.
”The MI is the identity the cloud LLM sees”	The cloud LLM sees the cloud-side principal the federation contract bound to.
”The MI is the identity the Weather API sees”	The Weather API sees the Agent Identity (oid in the Agent Identity JWT).
”The MI gets the Blueprint”	The Blueprint is the application that requests the Agent Identity JWT. The MI is the credential that proves the Blueprint is the one asking, via the FIC. They are distinct Entra objects with distinct jobs.

The correct mental model

                       UAMI (the MI)
                            │
              signs "I am UAMI X"   (the MI JWT)
                            │
                ┌───────────┴───────────┐
                ▼                       ▼
          Cloud federation        Entra FIC on Blueprint
          "trust Entra JWTs       "trust Entra JWTs
           with sub = UAMI"        with sub = UAMI"
                │                       │
                ▼                       ▼
          Cloud credential        mint Agent Identity JWT
                │                       │
                ▼                       ▼
             Cloud LLM               Weather API
          sees: cloud-side          sees: Agent Identity
          principal

The MI JWT is the witness. The downstream identity is different on each side. Same witness, two different downstream identities, two different downstream tokens.

Why a single combined identity is worse than the indirection

You could in principle want the cloud LLM to trust the MI directly. The cloud’s federation contract typically does not let you. Federation does not put the federated principal on downstream API calls. You always end up at a cloud-side principal (a GCP service account, an AWS IAM role). Even if a cloud did allow it, you would lose the audit story. The cloud’s logs would say “MI called me” and the Weather API logs would say “MI called me,” with no way to distinguish “this agent reasoning step” from “the sidecar minting a token for a different request.” With the indirection, the cloud LLM logs the cloud-side principal and the Weather API logs the Agent Identity, and the MI is just the shared root that proves the container has the right to do both.

What is the UAMI’s sub exactly?

Both halves of the federated pattern pin to the same value: the UAMI’s object id, a tenant-scoped GUID. The cloud federation contract pins it (--attribute-condition on GCP, Condition block on AWS). The FIC on the Blueprint pins it (subject="<UAMI-oid>"). That GUID is the universal anchor between the two federations. Get it wrong in either place and the corresponding leg stops working with a generic “subject does not satisfy condition” or “no FIC matched” error.

What goes into the MI JWT looks like this (claims trimmed):

{
  "iss": "https://sts.windows.net/<tenant-id>/",
  "sub": "<UAMI-oid>",
  "oid": "<UAMI-oid>",
  "appid": "<UAMI-client-id>",
  "aud": "<whatever you asked for>",
  "tid": "<tenant-id>",
  "xms_mirid": "/subscriptions/.../userAssignedIdentities/<name>"
}

For a managed identity, Entra writes the same GUID into sub and oid on purpose. That GUID is the UAMI’s object id.

Properties of that GUID worth pinning into memory:

• Stable for the lifetime of the UAMI resource. It does not rotate, it does not change on container restart, it does not change when you reassign the UAMI to a different ACA app.
• Per-resource, not per-name. Two UAMIs with the same name in different resource groups have different oids. The name is a label. The oid is the identity.
• Tenant-scoped, not global. The oid only has meaning inside one Entra tenant. It is not a portable cloud-wide identifier.
• Lost on delete + recreate. az identity delete followed by az identity create with the same name produces a new oid. Every trust contract pinned to the old oid (cloud federation conditions, FIC subject, Entra group memberships, Azure RBAC role assignments) breaks silently and must be re-pointed.

Three GUIDs travel with a UAMI. Keep them straight:

Identifier	Where it lives	Used by
oid (and sub in MI JWT)	Entra object catalog	Cloud federation conditions, FIC subject
appid (client id)	Entra application/SP catalog	Pre-authorization, MSAL client_id when reading the MI’s own perspective
Azure resource id (/subscriptions/...)	ARM	RBAC role assignments on Azure resources

Tip. Treat the UAMI oid like a primary key in your deployment scripts. Read it once after az identity create, export it as UAMI_OID, and use that variable everywhere downstream (cloud federation condition, FIC entry, deployment outputs). Never let two scripts independently look it up by name. If you ever see “assertion does not satisfy attribute condition” after a redeploy, the first thing to check is whether the UAMI was recreated and the federation condition still references the old oid.

Could the Agent Identity itself be the cloud federation subject?

Natural follow-up: the Agent Identity is also an Entra-issued token, so could it be the cloud’s subject_token, removing the UAMI from the cloud leg entirely?

Mechanically yes. The cloud’s federation contract does not care how the Entra token was minted. Only that the issuer is trusted, the audience matches, and the attribute condition passes. You point the cloud federation at assertion.oid = <Agent-Identity-oid> instead of assertion.sub = <UAMI-oid>, and your cloud audit logs now show the Agent Identity as the federated principal.

Both shapes are supported. The “Should the cloud federate the UAMI or the Agent Identity?” section below walks the trade-offs.

---

Choose the right managed identity: SAMI versus UAMI

Federation trust documents pin to a specific managed-identity object id. That sounds harmless until you remember what a system-assigned managed identity (SAMI) actually is: a brand-new identity created automatically when you enable MI on a resource, with a brand-new oid per resource. Delete the resource, recreate it, redeploy under blue/green, the oid changes, and every trust document that pinned to the old oid is now pointing at nothing.

User-assigned managed identities (UAMI) are first-class Entra objects you create with az identity create. They have a stable oid that survives resource deletion. You attach a UAMI to as many resources as you want.

	System-assigned (SAMI)	User-assigned (UAMI)
Lifecycle	Tied to the resource. Gone when the resource is deleted.	Standalone Entra object. Survives resource deletion.
oid	New for every resource	Stable forever
Attach to	One resource (1:1)	Many resources (1:N)
Created by	Azure (automatically when MI is enabled on the resource)	An administrator, via az identity create
Trust documents needed	One per resource. A fleet of 100 replicas needs 100 bindings.	One per UAMI. A fleet of 100 replicas needs one binding.
Blue/green or redeploy	New oid. Trust breaks.	UAMI persists. Zero churn.

Note. The scaling rule

Pin trust to the class of workload, not the instance. SAMI pins to the instance. UAMI pins to the class. For agents federated through a cloud’s trust contract or FIC, always use UAMI. One UAMI per agent class (mi-weather-agent, mi-finance-agent). Add a replica → attach the existing UAMI → zero changes on the cloud or Entra side. Add an agent class → create one new UAMI plus one new binding on each side. One-time cost, scales forever.

Two alternative gates exist but should be used carefully:

• Group-scoped. Condition on the groups claim (cloud-specific syntax). This requires the groups claim to be present in the token, which means configuring optional claims on the application. Cleaner for fleet management but adds a moving part.
• Tenant-scoped. Condition on tid alone. This is far too broad. Every workload in your tenant would be accepted. Do not use this in production.

Naming pitfall around “user-assigned”

“User-assigned managed identity” means created by a user (an administrator). It does not mean represents a user. UAMI is still a workload identity. It authenticates code, not a person. The JWT it produces carries idtyp=app. It can never be alice@contoso.com.

Entra object type	Represents	Backed by	Can sign in interactively?
User	A human	User object	Yes
Application registration / service principal	A workload (your code)	Service principal	No
Managed identity (system- or user-assigned)	A workload running on Azure	A special service principal with Azure-managed credentials	No

If you actually want a human as the federated cloud principal (interactive sign-in producing a user JWT that the cloud federates), that is the user-rooted bootstrap variant, not UAMI.

---

Three separate Entra objects do three different jobs

This is the most common question once the dust settles: “Can the UAMI just be the Agent Identity service principal?” The answer is no. They are distinct Entra object types and they cannot be merged. But a UAMI can authenticate as a Blueprint application via FIC, which is exactly how the federated pattern works in practice.

Object	What it is	Created via	Has credentials?
Application registration / Blueprint app	The workload definition (app id, FICs, scopes)	Entra portal or scripts	Secrets, certs, FICs
Agent Identity	A first-class agent identity defined inside a Blueprint	Agent ID administrative tooling	Inherits the Blueprint’s auth setup
User-assigned managed identity (UAMI)	An Azure-managed workload identity	az identity create	None, IMDS-attested

Three objects, three roles in the issued token:

Role	Object	Where it appears
Compute identity (“who is the runtime?”)	UAMI	The sub of the IMDS assertion, and only there
App identity (“who requested the token?”)	Blueprint app	The azp claim in the issued JWT
Agent identity (“who does this token represent?”)	Agent Identity	The oid claim in the issued JWT, this is what downstream APIs see

Note. Why these are not one object

If Agent Identities required a UAMI to exist, you would be locked to Azure compute forever. The whole point of an Agent Identity is that it is a portable, governed identity for an AI agent, no matter where the agent runs. Keeping the three layers separate buys you three things you will eventually want:

1. Separation of concerns. Blueprint is governance, UAMI is compute attestation, Agent Identity is the principal.
2. Cross-cloud portability. The same Agent Identity works whether the runtime is ACA (UAMI), EKS (IRSA), GKE (metadata server), or even on-prem with a certificate.
3. Lifecycle independence. Rotate compute without re-issuing agent consent grants.

The mantra:

UAMI = how the workload proves it is allowed to be the Blueprint. Blueprint = how the workload is defined as an application to Entra. Agent Identity = who the workload’s tokens represent.

---

One UAMI with two federations in parallel

Now the picture is complete enough to answer the question that started this whole investigation: yes, the same UAMI obtains an Agent Identity token from Entra via FIC and obtains a cloud credential to call the cloud LLM via the cloud’s federation contract. One IMDS call shape, one audience (api://AzureADTokenExchange), feeds both federations independently.

                    UAMI mi-agent  (oid = U)
                            │
         IMDS token  (aud = api://AzureADTokenExchange, sub = U)
                            │
                ┌───────────┴───────────┐
                ▼                       ▼
            Entra FIC               Cloud federation
          on Blueprint           (cloud trust contract)
          trusts sub = U          trusts sub = U
                │                       │
                ▼                       ▼
          Agent Identity JWT      Cloud credential
          (aud = api://weather,   bound to a
           oid = Agent Identity)  cloud-side principal
                │                       │
                ▼                       ▼
          Call Weather API        Call cloud LLM

Element	Entra side	Cloud side
UAMI	Same oid_U	Same oid_U
IMDS assertion	Same JWT	Same JWT
Trust contract	FIC on the Blueprint application	The cloud’s federation contract
Final token audience	api://weather	Cloud-specific resource (Vertex on GCP, Bedrock on AWS)
Identity the downstream sees	Agent Identity oid	Cloud-side service principal

Inside the sidecar, the order of operations per agent turn is:

1. Sidecar → IMDS: obtain assertion with aud=api://AzureADTokenExchange. Cache briefly.
2. Sidecar → Entra /oauth2/v2.0/token: send the IMDS JWT as client_assertion, with client_id=<Blueprint> and scope=api://weather/.default. Receive the Agent Identity JWT.
3. Agent → Cloud STS: send the IMDS JWT as the cloud’s subject_token/WebIdentityToken. Receive a cloud-issued credential (with a cloud-specific follow-up if the cloud requires an extra impersonation hop).
4. Agent uses (2) to call the Weather API. Agent uses (3) to call the cloud LLM.

Steps 2 and 3 are independent. They can run in parallel.

Tip. Both clouds’ audit logs join on the UAMI’s oid_U even though the downstream tokens carry different identities. That correlation is gold for incident response. Build it into your dashboards on day one.

---

Should the cloud federate the UAMI or the Agent Identity?

This is a federated-pattern variant, not a new pattern. Same compute (ACA), same UAMI, same FIC on the Blueprint, same cloud federation contract, same Weather-call leg. The asymmetry between the two options is entirely on the cloud-LLM leg, and it has three visible effects:

• The subject_token source changes. Option 1 fetches it from IMDS (an MI JWT). Option 2 fetches it from the sidecar’s FIC path (an Agent Identity JWT minted under a dedicated cloud-federation audience).
• The sidecar’s interface changes. Option 1 needs one scope on the sidecar (api://weather/.default for Weather). Option 2 needs two scopes: the Weather scope plus a new cloud-federation audience scope used only to feed the cloud’s STS. The Blueprint application has to define and permit both.
• The federated principal in the cloud’s audit logs changes. Option 1 shows the UAMI. Option 2 shows the Agent Identity. That single swap is the entire production reason to consider Option 2 in the first place.

The Weather leg is identical in both options. The sidecar still mints an Agent Identity JWT with aud=api://weather, the agent still calls the Weather API with that JWT, the Weather API still sees the Agent Identity. Nothing about that flow moves.

Option 1: UAMI federates directly to the cloud

This is what the standard federated diagram shows. The IMDS-issued assertion (whose sub is the UAMI’s oid) is the subject token. The cloud’s federation contract gates on assertion.sub == <UAMI oid>. The cloud’s audit logs show the UAMI as the federated principal.

   UAMI (oid = U)
     │
     ├── IMDS JWT (sub = U) ──▶  Entra FIC          ──▶  Agent Identity JWT  ──▶  Weather API
     │
     └── IMDS JWT (sub = U) ──▶  Cloud federation   ──▶  Cloud credential    ──▶  Cloud LLM

The two federations are siblings rooted at the same compute identity.

Option 2: Agent Identity federates to the cloud

In this variant, the sidecar first uses FIC to mint an Agent Identity JWT, and then uses that JWT as the cloud’s subject token. The cloud gates on assertion.oid == <Agent Identity oid> instead of the UAMI’s oid. The Agent Identity, not the UAMI, becomes the federated principal in the cloud’s audit logs.

   UAMI (oid = U)
     │
     └── IMDS JWT (sub = U) ──▶  Entra FIC  ──▶  Agent Identity JWT (oid = Agent Identity)
                                                       │
                                                       ├──▶  Weather API
                                                       │
                                                       └──▶  Cloud federation  ──▶  Cloud LLM

Mechanically this works because the cloud’s federation contract does not care how the Entra token was minted, only that the issuer is trusted, the audience matches, and the attribute condition passes. The Agent Identity JWT is a valid OIDC token from Entra.

Same color rule as Parts 1 and 2. Color = which issuer is being authenticated to. What is different here is that the blue band’s subject_token is now an Agent Identity JWT, not an MI JWT. The purple band has to fire first (twice, with two audiences), and the cloud’s audit logs land on the Agent Identity instead of the UAMI.

Legend: 🟦 Cloud LLM path (Agent Identity JWT → Cloud STS → cloud credential)    🟪 Entra / Weather API path (FIC, MI JWT presented as client_assertion → Agent Identity JWT, minted twice with two audiences)

Figure 1. Option 2 request flow. The purple band fires before the blue band on cold paths. The sidecar mints the Agent Identity JWT twice with two audiences (one for the cloud STS, one for Weather). The MI JWT never leaves the Entra leg.

What changes versus the standard federated flow

Four things, and only four. The Weather call is unchanged.

1. The purple band fires before the blue band. In the standard federated flow the agent goes straight from the MI JWT to the cloud STS. In Option 2 the sidecar must mint an Agent Identity JWT first, so an Entra round-trip sits in front of every cold-path cloud-LLM call.
2. Two FIC mints per turn, under two different audiences. The sidecar mints the Agent Identity JWT twice: once with the cloud-LLM audience for the cloud subject_token, once with aud=api://weather for the Weather call. Same Blueprint, same FIC, two scopes.
3. The sidecar exposes a new scope. The agent now asks the sidecar for a token whose audience is the cloud-LLM audience, not the Weather audience. The Blueprint must surface a scope or permission that maps to it. Option 1 needs neither change.
4. The cloud-side federated principal is the Agent Identity, not the UAMI. Cloud audit logs on the LLM call now show the Agent Identity oid. The MI JWT is no longer on the cloud path at all. Only Entra sees it.

Pros and cons

The two columns below name the options by what federates to the cloud, not by ordinal number, so the trade-offs read at a glance.

Pros (what Agent-Identity federation gives you that UAMI federation does not):

Aspect	UAMI federates to cloud	Agent Identity federates to cloud
Cloud IAM granularity	One cloud-side principal shared by every agent on the UAMI	Each Agent Identity can map to its own cloud-side principal (Google service account, AWS IAM role) with its own LLM quota, model allow-list, and IAM bindings
Revocation	Deleting the Agent Identity stops Entra-side calls only. The cloud-side federation still trusts the UAMI, so a separate cloud cleanup step is required	Deleting the Agent Identity in Entra kills the FIC-issued tokens, including the one feeding the cloud STS, so cloud LLM access dies in the same step
Multi-tenant attribution	One UAMI, N Agent Identities, all visible as the same federated principal in the cloud	One ACA app, one UAMI, N Agent Identities, N distinct federated principals visible in the cloud’s audit logs
End-to-end correlation key	UAMI oid correlates across clouds, Agent Identity oid does not appear in cloud audit	Agent Identity oid appears in cloud audit logs, Weather API logs, and your own telemetry. Incident response joins on a single key
Capability boundary alignment	The layer that authorizes (Agent Identity) is decoupled from the layer attributed in cloud audit (UAMI)	The layer that authorizes is the same layer that gets attributed

Cons (what Agent-Identity federation costs you that UAMI federation does not):

Aspect	UAMI federates to cloud	Agent Identity federates to cloud
Critical-path latency on cloud-LLM calls	One exchange: cloud STS (plus impersonation on clouds that require it)	Two exchanges: Entra FIC round-trip in front of cloud STS. Caching mitigates but never to zero on cold paths
Token rotation amplification	Cloud subject_token is the MI JWT, which lives roughly 24 hours	Cloud subject_token is the Agent Identity JWT, which lives roughly 1 hour. Rotation runs about 24x as often, multiplying Entra load and the chance of a cold path on expiry
Failure-mode coupling	Entra and cloud are independent on the request path. The cloud LLM still works when Entra FIC is degraded	An Entra FIC outage breaks the cloud LLM too. The two issuers are serial, not parallel
Configuration footprint	One trust contract per cloud, keyed on sub == <UAMI oid>	Cloud federation needs an oid-based mapping, an attribute condition on the Agent Identity oid, and an audience the Agent Identity JWT actually carries. The sidecar also mints two Agent Identity JWTs per turn (one per scope)
UAMI audit story	UAMI oid is the federated principal on the cloud side, giving a “one identity, two clouds” correlation	UAMI is no longer the cloud-side federated principal. Per-agent attribution replaces the cross-cloud UAMI correlation

When to pick each

Pick Option 1 when you have one workload class per UAMI and you do not need cloud audit logs to distinguish individual agents. The setup is simpler (one trust contract per cloud), and operationally there is one fewer hop in the critical path.

Pick Option 2 when any of the following are true:

• One UAMI hosts multiple Agent Identities (an orchestrator running several sub-agents on shared compute) and you want the cloud to distinguish them in audit logs and IAM policy.
• You want end-to-end agent attribution: the same oid appearing in cloud audit logs, the Weather API logs, and your own telemetry.
• You want atomic revocation: deleting an Agent Identity in Entra should immediately cut off both Weather access and cloud-LLM access, with no separate cloud-side step.

Note. When Option 2 really shines

Imagine a multi-tenant agent platform: one ACA application, one UAMI, but dozens of Agent Identities, one per tenant or per agent role. With Option 2, every cloud-LLM call is attributable to a specific Agent Identity in the cloud’s audit logs. You can give each Agent Identity its own cloud-side principal, with its own quotas, model allow-list, and IAM bindings. The UAMI becomes purely the runtime attestation. All the interesting governance lives at the Agent Identity layer.

The audience trap inside Option 2

Option 2 has a small but important wrinkle. The Agent Identity JWT’s aud claim is normally the audience of the downstream API you requested it for, for example api://weather. The cloud will reject that token by default. You have two ways to make the cloud accept an Agent Identity JWT, and one of them is a bad idea.

• (a) Tell the cloud to accept api://weather. Configure the cloud’s audience allow-list to include api://weather, and reuse the Weather-scoped Agent Identity JWT as the cloud subject_token. This works mechanically. Do not do this in production.
• (b) Mint a separate Agent Identity JWT with a dedicated cloud-federation audience. Define a new scope on the Blueprint, for example api://agent-cloud-federation. Have the sidecar mint a second Agent Identity JWT under that scope, and use that token as the cloud subject_token. Configure the cloud’s audience allow-list with api://agent-cloud-federation. This is the production path.

Why option (a) is a bad idea. The aud claim is a recipient identifier. aud=api://weather literally means “this token was minted to be presented to the Weather API.” When the cloud accepts a token with that audience, you have configured the cloud to trust tokens minted for a different service. That is the textbook confused-deputy setup.

Three concrete failure modes follow from option (a):

1. Token replay across services. A token minted for the Weather API is now also valid for the cloud. If the Weather API logs the raw bearer token (some do), if the token leaks through a proxy, if it appears in a trace span, anyone who sees it can replay it against the cloud STS and get a federated cloud credential. With option (b), the cloud-bound token has no other valid recipient, and the Weather-bound token has no cloud value.
2. Audit-trail confusion. Both audit surfaces see aud=api://weather. You cannot tell from the token itself whether a given request was “the agent calling Weather” or “the agent calling the cloud LLM.” The recipient identifier no longer identifies the recipient.
3. Blast radius on rotation. If you ever need to revoke the Weather audience (decommission the API, rename it, rotate its resource URI), you also break the cloud federation. The two trust contracts are now coupled through a string that has nothing to do with the cloud.

The cloud’s STS is not the Weather API. The cloud should accept a token whose aud identifies the cloud-federation audience, not a token whose aud identifies an unrelated downstream service. Option (b) makes that explicit. The cost is one extra scope on the Blueprint and one extra FIC mint per turn. The benefit is that every Entra-signed JWT in your system carries a truthful aud, and no token is ever valid against more than one recipient.

Tip. If you are choosing between Option 1 and Option 2 today and you are not sure, start with Option 1. It is the simpler topology and the one the sample tutorials use by default. Move to Option 2 when your audit and governance requirements actually demand per-agent attribution in the cloud. Migration is one cloud federation configuration change plus one extra Entra token call in the sidecar.

---

Up next

Entra Agent ID Across Clouds: Part 4, FIC, Cross-Tenant, and OBO picks up the Federated Identity Credential itself. Part 3 used FIC as a black box. Part 4 opens it up: the single-tenant shape, the cross-tenant shape (a UAMI in tenant A authenticating as a Blueprint in tenant B), and the orthogonal world of on-behalf-of (OBO) where the agent acts for a signed-in user rather than as itself. Three patterns, one underlying primitive.

---

For new posts in this series, subscribe via the RSS feed or follow along on LinkedIn.