The first four parts covered the design, the Entra mechanics, the directory match and the surprises from the real tenant. This

final part is honest about what is still open, shows how to run the stack, and ends with the takeaways that would have saved us

the most time.

What is verified

Before the open items, here is what the real tenant has confirmed. The status is recorded in docs/design/real-entra.md , and the

claims below are the ones the end-to-end checks assert.

O2 and O3, in the home tenant. A signed-in user's refresh token led to a T1 token with fmi_path , then an OBO exchange gave a Graph token with the right audience and scope. azp was the agent identity and oid was the user, and Graph accepted the token.

O1, the B2B guest case. A home-tenant user signed in as a guest in a second tenant. That tenant's own blueprint and agent identity produced the token. The consent step needed the 65001 handling described in Part 4.

The directory match.…